Quote:

---

also as far as i understood if i use client2 = ent_create(...) at the client, only! the pointer client2 is valid at the client. if i use the pointer client2 at the server its empty, isnt it?

---

Yep, it will be empty on the server. If your doing something like this, just go client2 = my; on for every instance of this entity. However, you can only set this pointer once on each computer, otherwise it wouldn't be unique.

Code:

---

      you = ent_create("wdynamad.mdl", temp, bombw);

     my.weapon = 1;

     if(you)
     {
      you.p_find = handle(my); //Tells the weapon what kart created it
      sleep(0.1);
      send_skill(you.p_find, 0);
     }
 

---

This code creates an entity, then stores a handle of the kart that created the enity in a skill, then sends that handle to the server.

Code:

---

  while(!my.p_find){wait(1);}
 send_skill(my.p_find, send_all); 

---

You'd then run this code on the server version of the newly created entity. After this, every instance of this entity will have the handle pointing to the kart that created it. I needed this so that the entity follows the kart that created it on every computer.

Anyways, I thought i'd add a bit more food for thought. I still think using ent_create with no local entities is the best way to go. Though, I dont know if i'm fully following what your trying to do, so i'd reccomend going about it your way, and see if it works. Be sure to report back when you've tried it out.

15.05.06 wow, thanks again william. i didnt know handle() does work in multiplayer as you have ent_createlocal. so i guess the handle works only for entities created with ent_create? anyways good to know it seems to work altough its a little bit unlogic for me.

now i see why having all entities created by ent_createlocal is not a good idea unless you have a fixed number of entities.
its a mess when trying to display whos already joined and who not. not to mention npcs and so on. you have to send a lot of status variables back and forth indicating what happend to wich entity.

i think ill rewrite my entity handling code from scratch keeping the working chat and cleaning all the unneeded parts. ill then go the way with ent_create.

another interesting thing i noticed: we tested the movementcode with 4 updates a second via the internet. it was very smooth in the first test, like it is in lan. the second test a weaker connection was host. the movement sometimes stopped for all entities on the clients machine at the same time.
i guess this is due to a missing/delayed packet of the positionvector. so i have to take care of that in the movementcode too. i think ill just move on slower heading in the direction of the last received position. this will make the movement a bit choppy when it lags but when no data is incoming the game has to stop anyway.

i feel that if i manage to handle the entites right. i have done the hardest part.

my target is to get the 10 players into the game able to walk around like in wc3 with their own avatar. this already worked in my previous system pretty good but with more players joining it becomes a mess handling the entities.

ill keep you updated, thanks for rating this thread and your nice comments. this keeps me motivated on top of my own motivation to realise this game i have in mind!

Quote:

---

so i guess the handle works only for entities created with ent_create?

---

Naw, I'm pretty sure there is no problem using handles and ent_createlocal, but it would only be valid on your computer, as the other comps have no knowledge of the entity.

Your online finds are intresting, thanks for posting them. While I haven't actually done any testing online yet(plan to use the -sim in the future). I'd think your right that this is probably due to the positional updates not reaching their destination in time from the server. There is multiple solutions to this, and it really depends on what your trying to do:

- You can have it so your interpolation of entities on the client are 2 updates behind your servers real position. That way if one update is delayed or lost, there will always be an extra one. This sucks on it's own, cause your entities wont be very near to their real positions.

- If this fails(both updates lost), then extrapolation based on previous updates would be your only choice.

- How weak was your connection for your second test? If your game is planned for dsl and lan only you may be able to get away with these things. Most people with 56k(like me) don't even bother playing UT online ect. Cause it isn't too fun. Also, usually the people who run servers should have the best connection. Player amounts factor in as well.

Since my game uses quite a bit of projectiles. I'm going to have to keep the entities as close to the server position as possible. I think i'll keep it 2 updates back(currently it's only 1 update back), but extrapolate constantly on top of that. Using the angle of the player and the angle to the next update position to help deterine where to extrapolate too. I dont know if this would be possible for all game types, since racing is more constant and predictable than an FPS game.

If your doing an FPS game, I wouldn't reccomend a constant extrapolation, because you'll have great overshooting. Keep things back, but deal with it on the server. No one knows better in an FPS game if the player running is actually behind where he is in reality. You'd still do targeting on the client, but you'd have to back everything up on the server to verify it. Racing games, especially with projectiles, don't have this luxury. If you see someone win a race, when on your screen there behind you, but in reality they crossed the finish line first, you'd be mad... so it's sorta a given to extrapolate. If anyone knows of a good solution for this, it would be great though, cause extrapolating can cause problems.

Heres a couple more Q's to consider - what type of internet connection are you aiming for with your rts/fps hybrid? Was send_unreliable set for your positional skills when you did the online test? Also, mabye try sending more updates to see what happens, only 4 updates a second seems a little low, I think even quake2 have 10 updates a second. Hope to hear the answers sometimes soon, I think this is a good learning experience for both of us.

Quake2 Multiplayer Specs:

http://www.csse.monash.edu.au/~timf/bottim/q2net/q2network-0.03-4.html

hey there, thats what i mean. locally it can not work but for entities created globally this was even new for me.

the game we are making is aimed for dsl primarily but it should run with isdn or even modem as well at the client side. the server will need dsl cause of the high upload value.

the connection the host had was a weak dsl, with some problems. he had 25kb upload though, that should be plenty for the data the game sends(2 vectors 4times a second). download is 75-100kb i think but that should be totally okay. the problem was that sending stucked after some random time every ~10 seconds. for all moving entities - while i was host movement was smooth as expected. i have almost the same connection. this was probably due to some technical issues i dont know if the data was lost or delayed. the outcome was that the entity stopped when it rechead the last known position then after 1/2 second it moved on.

edit: dplay_unreliable was set to off; like standard for this tests. also iam not making an rts/fps. i do a rts/rpg kind of game every player controls an avatar like diablo but there will be lots of npcs walking around and fighting.
thats why i try to keep updates low from the beginning. because in total i think ill have around 50 moving entities at a time average. players will be limited to 10. 5 on each team. each on of those 5 needs data from half of the total entities. so lets say one player needs data of ~30 moving entities average. all that with ent_move on the server (i switched from c_move because its faster) sent to the clients.

Yeah, that does sound weird. It must be something technical, I don't see how the positional updates would be lost or delayed with this good of a connection.

Your game sounds intresting, always nice when someone does something original. And I dont think you'll have to keep the updates very low for the main players if you keep it at 10. NPC's don't need constant updates or c_move(), they should be handled via pathfinding. All you should do is send an skill indicating that the NPC should move, then on each computer move it via pathfinding sperately. For my projectile weapons, I just send a skill to their instances saying "move", then they move on each computer according to their code seperately without any further multiplayer updates. Another thing, if your game is like diablo, then it won't be as fast paced like Unreal Tournament or something, so this should make multiplayer coding a bit easier in the long run. Of course I dont know the exact details of what your planning, but mabye you can get away with constantly updateing only some core entities.

18.05.06 okay, iam almost done rewriting the system so that every player only uses 1 entity of his own. sending positions is done via skills. ill explain the whole movement system in total once its clean and works good.

a very important thing i came across is that whenever you create entities in a network game you should have sleep(1); set as the first statement in the entities action. if you dont, you will get problems that some clients dont get this entity.

this is what happend to me when i was testing with 4 clients total. some just didnt get updates from others. very strange. a sleep(1) at the beginning of the entities action solved my problem.

i then tested the game with a friend again over the net. it worked good like bevore. i just measured that i have an average up and download of ~0.5 kb per second as host. for comparison if i host a wc3 game for 10 players i have like 5kb download and 5-10kb upload per second.
maybe i can stay below that with my game who knows yet.

my problem now still is the movement at the client. i sent the position to go to to the host. and the host then calculates in the entities server function the movement. so far this works like a charm.
then i sent data back with SEND_RATE in a skill only when the entity is moving at the host.
my problem still is to get a smooth movement out of this at the client. this is what iam working on right now. this code also needs to take into account dropped packets.

what i will do is move to the first received point, then keeping this direction but getting slower constantly until the next position comes in. then ill turn slowly to this new position and increase speed to normal.

i also realised that send_skill is a problem. because it sends to all clients or to the creator only. but for updating others players positions you have to send to all! thats where the problem is. its a waste of bandwith. imagine only 1 out of 10 players see a certain player of those 10. now all 9 others get this data too and cant even display him because of fog of war. so its a waste of bandwith.

the next problem is, that when you sent position updates to all players you enable them to cheat. only thing they would have to do is read the data they get and thus they know where the other players are. or even worse simply remove the fog of war.

thats why i suggested a send_skill_to statement in the future forum.

http://www.coniserver.net/ubbthreads/showflat.php/Cat/0/Number/655449/an/0/page/0#Post655449

please support this idea by posting there if you think its a good one. let me know if you have some possible workarounds in mind. thanks.

edit: i forgot. i think i found a problem? in locoweeds code if i can call it so. he sends the player number to all players once a new player joins in the function running at the server. this is fine so far the only problem is that newer players dont get the player numbers of those players already in the game. maybe iam totally wrong here but i solved this with a ent_next loop in the entities function at the server. so it loops through all entities, checks if this entity has a playernumber and then sends it to all clients. maybe iam totally wrong here and the newer players dont even need the playernumber skill from the ones already in the game. in my case they do because if for example you want to attack another player you have to let the server know wich one you want to attack therefore every client needs to know every other players unique playernumber skill.

Just to say it, the server mentioned above was my pc, with 40-50 kb down and 20 kb up... I really think most kidds that play games have DSL and this is standart yet; But maybe Ulf is cheating and makes our game playable for me,too

Quote:

---

what i will do is move to the first received point, then keeping this direction but getting slower constantly until the next position comes in. then ill turn slowly to this new position and increase speed to normal.

---

This wouldn't work. If you speed up and slow down your entities the player will notice it. I spent a few days myself trying to get this working purely via angles, but that does not work either since your simulation will diverge. That past example I showed you is what you should keep using. Though, keep it 2 updates behind. This will keep it very smooth and accuracte, however, it will always be behind. To counter this, try extrapolating the position based on angle, so it is always a certain distance ahead the interpolated position. While I havn't done the extrapolating with the code yet, I will in a couple days, and see if it works like I think...

Your right about the waste of bandwidth, I havn't thought of this previously, but now that you've mentioned it I posted in your future thread. It would be a good feature to selectively send updates.

Quote:

---

maybe iam totally wrong here and the newer players dont even need the playernumber skill from the ones already in the game. in my case they do because if for example you want to attack another player you have to let the server know wich one you want to attack therefore every client needs to know every other players unique playernumber skill.

---

Yes, new players will need the unique id of the past players. I don't remember how locoweeds was doing it, but the way i'm doing it works quite well. Here's how:

New client connected function:


Code:

---

 
function server_called()
{
 //if new player connected
 if((event_type == event_join) && (people_connected < 8))
 {  
  ifdef server;
 // old_pconnected = people_connected;
  people_connected += 1; //another person connected
  sleep(2);
  send_var(people_connected); //send number of people connected
  endif; //ifdef server
 }

 //if player disconnected
 if(event_type == event_leave)
 {
  ifdef server;
  people_connected -= 1; // one less person connected to server
  sleep(2);
  send_var(people_connected); // send number of people connected
  endif;
 }
}

on_server = server_called; // server called
 

---

Now, on the top of the function for your entity which contains the unique id:

Code:

---

   if(people_connected == 1){mkart1 = me; my.kart_point = 1;}
  if(people_connected == 2){mkart2 = me; my.kart_point = 2;}
  if(people_connected == 3){mkart3 = me; my.kart_point = 3;}
  if(people_connected == 4){mkart4 = me; my.kart_point = 4;}
  if(people_connected == 5){mkart5 = me; my.kart_point = 5;}
  if(people_connected == 6){mkart6 = me; my.kart_point = 6;}
  if(people_connected == 7){mkart7 = me; my.kart_point = 7;}
  if(people_connected == 8){mkart8 = me; my.kart_point = 8;}
 

---

In the while loop of your entities on the server.

Code:

---

   if(new_sends != people_connected){client_new += 1*time;}
  if(new_sends != people_connected)&&(client_new > 160){client_new = 0; new_sends += 1; send_skill(my.kart_point, send_all); send_skill(my.tracekart, send_all);send_skill(my.wheelkart, send_all);}
    

---

To sum it up, when an entity first connects, the people_connected variable goes up by one. You then send this variable to all existing clients. Now, on the new client that just connected you set it's unique id by the existing value of people_connected. In other words, if people_connected is 2, then the new client entity will be id#2.

Now that you've set this skill, you must have some commands for it to send the skill when a new player joins, otherwise only existing players will contain this skill. So that's why you put that code in the while loop on the server, that detects when a new client joins, then it resends all the important skill information(pointers, id, ect.) to the newly joint entity.

Theres probably many ways to do this... but no matter what your doing, you have to make sure you have a little bit of code in each entity function that will automatically update all the new clients of important skills ect. when they join.

please let me know when you done the extrapolation and how you did it i have just finished the movement again. iam now doing it the way described, when there i currently no new position incoming, the player just keeps moving into the last known direction a little bit slower (not noticable). this works great, only thing what can happen is that sometimes you make a little extra curve but that doesnt really influence anything.

i always move the client player a little bit slower than the real player to make shure he doesnt always reach the position close.
this way the clients are 1/2 second delayed in the internet i would say. a test yesterday evening showed that with this method no lags occur at all in the movement.
they also showed when 2 players are constantly moving with this system. (the server uses send_skill(my._receive_x, SEND_ALL | SEND_VEC | SEND_RATE | SEND_UNRELIABLE); to send the data with dplay_entrate = 4;
i have almost constantly 0.5kb/s upload at my network card. when only one player is moving theres 0.2-0.3 kb/s and if no on moves its around 0.1-0.3 kb/s wich i guess are the keepalive ping messages.

i made a little video to show the movement. this video is taken at the client its very slow due to the recording software so dont worry about that. just notice how the player moves at the client. this was taken in lan.

http://www.ackbytes.de/upload/movement.wmv

(850kb size of movie)

use videolan to watch it, have fun also notice the panel i made can be dragged around and it can be pinned so you dont accidently move it around. almost all hud elements in the game will be moveable this way.

I took a look at the video. I see your doing something very different than what i'm doing. It looks like you've got things running properly. I assume your using the mouse position and moving the entity directly there? By the looks of things, I dont think you'd ever need to constantly update your players position(if it keeps moving to where mouse clicked). The only position you should send is the mouse position(upon clicking) and send it reliable.

All along I thought you were doing something realtime(user input via keyboard), lol, but I guess multiplayer coding techniques can be very generalized and work across all genres.