<!--quoteo(post=1970407:date=Sep 3 2012, 03:17 PM:name=Wilson)--><div class='quotetop'>QUOTE (Wilson @ Sep 3 2012, 03:17 PM) <a href="index.php?act=findpost&pid=1970407"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Is there any purpose to updating more frequently than the server tickrate though? Isn't that like trying to display a 120fps animation on a 60hz monitor. All of the source games I've played the servers always limited your updates to and from the server. They were generally always 33/66/100. I always just assumed that the admin set those limits to the tickrate of the server.<!--QuoteEnd--></div><!--QuoteEEnd--> After thinking about it again I believe I got it right this time.
Client samples input TICK_RATE (33/66/100) times per second. It puts it into cyclic buffer. It packs relevant part of the buffer and sends it to server.
When client is executing a frame it gets to last period of time that makes a full tick. It marks that time as destination tick. If server said that it differs wrt execution we reset last_confirmed_tick to it and predict from it to destination_tick. There is usually a leftover. We interpolate (position, angles) of entities between 2 appropriate ticks.
If client is lagging (low FPS) then ticks are still generated they just have newer timestamp than they should.
Server gets TICK_RATE cmds per second per client unless client lags. During each server Frame() it grabs UserCmds, executes them and tells client what is last usercmd it accepted (by also sending data for fields that client predicts).
Now, weird cases:
a) client lagging - usercmds are still generated. If usercmd generation is slow it'll be loop of death. If that loop is limited then usercmds will be dropped. b) server is lagging - processing tick takes more than TICK_INTERVAL. Result - loop of death or dropping ticks.
Source cl_cmdrate/cl_updaterate cvars are cvars with limits set by the server.
I believe the whole thing I found weird was related to different thing - code being executed during client frame, not just client tick in prediction.
matsoMaster of PatchesJoin Date: 2002-11-05Member: 7000Members, Forum Moderators, NS2 Developer, Constellation, NS2 Playtester, Squad Five Blue, Squad Five Silver, Squad Five Gold, Reinforced - Shadow, NS2 Community Developer
edited September 2012
<!--quoteo(post=1970535:date=Sep 3 2012, 08:28 PM:name=MOOtant)--><div class='quotetop'>QUOTE (MOOtant @ Sep 3 2012, 08:28 PM) <a href="index.php?act=findpost&pid=1970535"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->That only works if "user move" (usercmd in Sourcespeak) is split into 2 parts: query world and resolve conflicts.<!--QuoteEnd--></div><!--QuoteEEnd-->
Clients already ignore conflict resolution (its not like they CAN do it), and in order to keep everyones client as conflict-free as possible, the clients idea of what happens is normally allowed on the server as well. The server resolves conflicts in the attacker-wins mode (ie, if your client saw the fire as a hit, it is a hit even though on the server, your target had already dodged in another direction). And yes, this does means that you have a good chance of moving through other players if you are moving towards each other fast enough and are lagged enough. Not normally a big problem.
<!--quoteo(post=1970535:date=Sep 3 2012, 08:28 PM:name=MOOtant)--><div class='quotetop'>QUOTE (MOOtant @ Sep 3 2012, 08:28 PM) <a href="index.php?act=findpost&pid=1970535"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You're comparing different things. Server has to keep state correct with respect to execution of other players' moves. Data structures manipulated during move execution have to be either duplicated or access to them has to be synchronized. That is what prediction does - it keeps local data separate from ones confirmed to be correct by the server. Anything that has data races is by definition NOT embarrassingly parallel anymore.<!--QuoteEnd--></div><!--QuoteEEnd-->
There is no data race on the client, and it is the remote clients experience that you want to replicate locally on the server. Therefore, there is no data race on the server either (and yea, all non-read-only data must be copied. Memory is cheap though. Anyone could have bought a couple of gigs of memory if they had worked instead of spending their time reading this thread... :-) ).
You DO have to merge the different clients input before sending out the next network update, and that part is not parallel.
<!--quoteo(post=1970535:date=Sep 3 2012, 08:28 PM:name=MOOtant)--><div class='quotetop'>QUOTE (MOOtant @ Sep 3 2012, 08:28 PM) <a href="index.php?act=findpost&pid=1970535"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Why are we talking about this whole thing if server is running fast enough?<!--QuoteEnd--></div><!--QuoteEEnd-->
Someone asked if it was possible to use multitasking and I answered. Regarding running fast enough ... well, I'd like the opportunity to make a more complex mod than NS2, say with each player controlling half a dozen entities, and have hundreds of sentries/hydra equivalents; oh, and 64 players as well.
THAT would be hard to do on a single core. 8 cores? Easy...
Comments
After thinking about it again I believe I got it right this time.
Client samples input TICK_RATE (33/66/100) times per second. It puts it into cyclic buffer. It packs relevant part of the buffer and sends it to server.
When client is executing a frame it gets to last period of time that makes a full tick. It marks that time as destination tick. If server said that it differs wrt execution we reset last_confirmed_tick to it and predict from it to destination_tick. There is usually a leftover. We interpolate (position, angles) of entities between 2 appropriate ticks.
If client is lagging (low FPS) then ticks are still generated they just have newer timestamp than they should.
Server gets TICK_RATE cmds per second per client unless client lags. During each server Frame() it grabs UserCmds, executes them and tells client what is last usercmd it accepted (by also sending data for fields that client predicts).
Now, weird cases:
a) client lagging - usercmds are still generated. If usercmd generation is slow it'll be loop of death. If that loop is limited then usercmds will be dropped.
b) server is lagging - processing tick takes more than TICK_INTERVAL. Result - loop of death or dropping ticks.
Source cl_cmdrate/cl_updaterate cvars are cvars with limits set by the server.
I believe the whole thing I found weird was related to different thing - code being executed during client frame, not just client tick in prediction.
Clients already ignore conflict resolution (its not like they CAN do it), and in order to keep everyones client as conflict-free as possible, the clients idea of what happens is normally allowed on the server as well. The server resolves conflicts in the attacker-wins mode (ie, if your client saw the fire as a hit, it is a hit even though on the server, your target had already dodged in another direction). And yes, this does means that you have a good chance of moving through other players if you are moving towards each other fast enough and are lagged enough. Not normally a big problem.
<!--quoteo(post=1970535:date=Sep 3 2012, 08:28 PM:name=MOOtant)--><div class='quotetop'>QUOTE (MOOtant @ Sep 3 2012, 08:28 PM) <a href="index.php?act=findpost&pid=1970535"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You're comparing different things. Server has to keep state correct with respect to execution of other players' moves. Data structures manipulated during move execution have to be either duplicated or access to them has to be synchronized. That is what prediction does - it keeps local data separate from ones confirmed to be correct by the server. Anything that has data races is by definition NOT embarrassingly parallel anymore.<!--QuoteEnd--></div><!--QuoteEEnd-->
There is no data race on the client, and it is the remote clients experience that you want to replicate locally on the server. Therefore, there is no data race on the server either (and yea, all non-read-only data must be copied. Memory is cheap though. Anyone could have bought a couple of gigs of memory if they had worked instead of spending their time reading this thread... :-) ).
You DO have to merge the different clients input before sending out the next network update, and that part is not parallel.
<!--quoteo(post=1970535:date=Sep 3 2012, 08:28 PM:name=MOOtant)--><div class='quotetop'>QUOTE (MOOtant @ Sep 3 2012, 08:28 PM) <a href="index.php?act=findpost&pid=1970535"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Why are we talking about this whole thing if server is running fast enough?<!--QuoteEnd--></div><!--QuoteEEnd-->
Someone asked if it was possible to use multitasking and I answered. Regarding running fast enough ... well, I'd like the opportunity to make a more complex mod than NS2, say with each player controlling half a dozen entities, and have hundreds of sentries/hydra equivalents; oh, and 64 players as well.
THAT would be hard to do on a single core. 8 cores? Easy...
/Mats