Alliedassault - View Single Post

madrebel · 01-24-2002, 01:13 AM

<BLOCKQUOTE>quote:<HR>Oh, I get it Madrebel...how dim of me. The amazing Q3 engine...so when a client's packets totally stop departing and arriving the MoH code on the server telepathically computes where the client's model is going, registers hits and transmits those calculations back to the client who sees himself die on his screen<HR></BLOCKQUOTE>no if packets stop being sent/received the 'client' freezes on his local machine and freezes in place(sometimes still running in place if that was his last action). That player CAN still be killed however because the server still registers it as a 'live' entity until that 'live entity' times out or the server receives a disconnect session packet. Do you know anything about TCP/IP? Seriously im asking so i know how far to dumb this down for you. <BLOCKQUOTE>quote:<HR>The server also takes over the client's moving model when no packets are arriving and computes it's course of travel for the lucky player on the server-side so that he can continue to shoot it.
<HR></BLOCKQUOTE>no the server doesnt do this at all. what the q3 server does is track where the players is according to the data it receives from the player. if it stops receiving packets due to
A. timeout
B. packet loss

that client will appear to "freeze" and "warp" all over your screen. why? because the server "loses" track of that player. The client moves lets say in a straight line ok. the client moves 10 game feeet lets say. ok the server receives the ackets for the first 3 feet fine, something happens on the internet and one of the routers between the client and the server craps out a few packets. the server now think s hey the client has only moved 3 feet so it tells the other clients that this guy is moving in this direction and was last seen here. but wait oh look now i got the last packets and now the client is actually 7 feet in front of where he last was.

hence the "warping"

<BLOCKQUOTE>quote:<HR>Alternatively, when packets from the client arrive late, or not at all, the model server-side stutters...no packet, freeze...gets packet, moves...called stutter. Otherwise known as a difficult target. Mmm...yes, I'm completely ignorant about lag<HR></BLOCKQUOTE>yes you are

sim games handle it differently. they dont use a client/server model. they use a peer to peer model. the biggest difference is when you click fire in peer to peer you instantly fire where as in a client server model you fire when the server receives the packet.

client/server = nothing happens without the server knowing

peer/peer = updates are sent between the peers.

both have their strengths and weaknesses.

since youre so versed on internet protocols would you care to enlighten me on the type of protocol all internet games use? and no tcp/ip isnt exactly the correct answer.

	(#54)
madrebel is Offline Senior Member Posts: 534 Join Date: Jan 2002 Location: Newport Beach CA	01-24-2002, 01:13 AM <BLOCKQUOTE><font size="1" face="Tahoma, Verdana, Arial">quote:</font><HR>Oh, I get it Madrebel...how dim of me. The amazing Q3 engine...so when a client's packets totally stop departing and arriving the MoH code on the server telepathically computes where the client's model is going, registers hits and transmits those calculations back to the client who sees himself die on his screen<HR></BLOCKQUOTE>no if packets stop being sent/received the 'client' freezes on his local machine and freezes in place(sometimes still running in place if that was his last action). That player CAN still be killed however because the server still registers it as a 'live' entity until that 'live entity' times out or the server receives a disconnect session packet. Do you know anything about TCP/IP? Seriously im asking so i know how far to dumb this down for you. <BLOCKQUOTE><font size="1" face="Tahoma, Verdana, Arial">quote:</font><HR>The server also takes over the client's moving model when no packets are arriving and computes it's course of travel for the lucky player on the server-side so that he can continue to shoot it. <HR></BLOCKQUOTE>no the server doesnt do this at all. what the q3 server does is track where the players is according to the data it receives from the player. if it stops receiving packets due to A. timeout B. packet loss that client will appear to "freeze" and "warp" all over your screen. why? because the server "loses" track of that player. The client moves lets say in a straight line ok. the client moves 10 game feeet lets say. ok the server receives the ackets for the first 3 feet fine, something happens on the internet and one of the routers between the client and the server craps out a few packets. the server now think s hey the client has only moved 3 feet so it tells the other clients that this guy is moving in this direction and was last seen here. but wait oh look now i got the last packets and now the client is actually 7 feet in front of where he last was. hence the "warping" <BLOCKQUOTE><font size="1" face="Tahoma, Verdana, Arial">quote:</font><HR>Alternatively, when packets from the client arrive late, or not at all, the model server-side stutters...no packet, freeze...gets packet, moves...called stutter. Otherwise known as a difficult target. Mmm...yes, I'm completely ignorant about lag<HR></BLOCKQUOTE>yes you are sim games handle it differently. they dont use a client/server model. they use a peer to peer model. the biggest difference is when you click fire in peer to peer you instantly fire where as in a client server model you fire when the server receives the packet. client/server = nothing happens without the server knowing peer/peer = updates are sent between the peers. both have their strengths and weaknesses. since youre so versed on internet protocols would you care to enlighten me on the type of protocol all internet games use? and no tcp/ip isnt exactly the correct answer.