When youre fighting someone at melee range, its not so much that you run right through, but you slide under and to the sides. Maybe changing the collision meshes to something not quite that rounded might help.
<!--quoteo(post=1981980:date=Sep 23 2012, 12:48 PM:name=elmo9000)--><div class='quotetop'>QUOTE (elmo9000 @ Sep 23 2012, 12:48 PM) <a href="index.php?act=findpost&pid=1981980"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->When youre fighting someone at melee range, its not so much that you run right through, but you slide under and to the sides. Maybe changing the collision meshes to something not quite that rounded might help.<!--QuoteEnd--></div><!--QuoteEEnd-->
Indeed, in NS1 when you touched a marines from behind and bit them you didn't slide around them because you're going faster.
I asked on the stream Q&A about tickrate and max replied in chat saying it would have no benefit to increase it. I hope someone asks him about it in future if he is on the next stream because I don't really understand.
I thought that having a 60tickrate server would allow you to essentially turn the interpolation off. Isn't interp there because you are getting 20 updates a second from the server but probably playing at 60fps on a 60hz monitor? If it was only updating the enemy positions 20 times a second it would look laggy, so it adds a delay and then smooths between two packets. But if you were getting 60 updates then interpolation would only be needed when packets are dropped. Even then, I was always happy to turn off interp in source because the reduced delay was worth it.
I also thought in general increasing the server tickrate would increase the precision. Max obviously knows much more about it than me though. Perhaps it doesn't even matter anyway because ns2 might not ever be able to run at 60tickrate (even for only 12 players).
Perhaps updates could be increased to 30 times a second though over 20. Then interp could be reduced to 33.3ms
Increased tickrate is good yes, it reduce the error in all integrations (position and velocity mainly). I guess it could be bad if the server can't handle it properly, start the choke, etc.
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
I asked on the stream Q&A about tickrate and max replied in chat saying it would have no benefit to increase it. I hope someone asks him about it in future if he is on the next stream because I don't really understand.<!--QuoteEnd--></div><!--QuoteEEnd-->
In NS2 (and Source) the tickrate on the server will not affect player-player collisions. That's because players are not moved during the server tick, they are moved on the server as their moves are processed. It's kinda nifty; the server checks to see when you executed your move, time-shifts everyone to that time, processes your move (including you shooting your gun) and then time-shifts everyone back.
Only AI units (and ragdolls) are moved during the server tick.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->I thought that having a 60tickrate server would allow you to essentially turn the interpolation off. Isn't interp there because you are getting 20 updates a second from the server but probably playing at 60fps on a 60hz monitor?<!--QuoteEnd--></div><!--QuoteEEnd-->
The tickrate of the server and how often the server sends you updates are two different things. The NS2 server runs at 30ticks internally, and sends updates 20 times per second, to save on bandwidth. Interpolation is then used to hide the bandwidth limitation.
Thanks for the response matso. I am forever fascinated by this stuff.
I didn't think that increased tickrate would directly affect collisions, but it was just because you referenced the delay from interp I figured anything that could reduce that would have a benefit.
I understand that tickrate and updates sent to the client are two different things. I assume sending more updates than the tickrate would be pointless.
My question to Max on the stream was more general, i.e. would increasing the tickrate have any benefits? I guess if you didn't also increase the number of updates clients were receiving then it might not. Maybe that's what he was referring to. I don't know how much bandwidth sending 60 updates a second to all the clients would take. Although if you can run 24 player servers with 20 updates, then 12 players receiving 30 updates should be possible. I would imagine that sending more updates per second to the client would improve the precision and perhaps reduce the need for as much interpolation.
While on this subject, I felt like there has been some hit-reg issues for me, especially when playing at 150 ping. I particularly notice it with parasite. Sometimes I am sure my crosshair is on the marine and yet I miss. I'm not sure if this is an actual hit-reg problem though, it may just be the animations deceiving me. I may try recording some footage and watching it back in slow-mo to figure out what's going on.
<!--quoteo(post=1982276:date=Sep 24 2012, 04:12 PM:name=matso)--><div class='quotetop'>QUOTE (matso @ Sep 24 2012, 04:12 PM) <a href="index.php?act=findpost&pid=1982276"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->The tickrate of the server and how often the server sends you updates are two different things. The NS2 server runs at 30ticks internally, and sends updates 20 times per second, to save on bandwidth. Interpolation is then used to hide the bandwidth limitation.<!--QuoteEnd--></div><!--QuoteEEnd--> Ummm isn't that super bad if your only sending 20 updates per second that means there is a 50ms gap between each update or about 3 frames if your running at 60fps then factor in you 50ms~ or so ping to the server...
Given that your only send position updates every 50ms to the server and the rest is interpolated wouldn't this cause chaos with the physics and hit boxes particularly for fast moving objects?
I can't see how you guys expect this to be an E-sport when the feedback loop is so slow/interpolated...
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
<!--quoteo(post=1982399:date=Sep 24 2012, 04:26 PM:name=kabab)--><div class='quotetop'>QUOTE (kabab @ Sep 24 2012, 04:26 PM) <a href="index.php?act=findpost&pid=1982399"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Ummm isn't that super bad if your only sending 20 updates per second that means there is a 50ms gap between each update or about 3 frames if your running at 60fps then factor in you 50ms~ or so ping to the server...
Given that your only send position updates every 50ms to the server and the rest is interpolated wouldn't this cause chaos with the physics and hit boxes particularly for fast moving objects?
I can't see how you guys expect this to be an E-sport when the feedback loop is so slow/interpolated...<!--QuoteEnd--></div><!--QuoteEEnd-->
Thing is, what you see on your screen _is_ your reality. Each player has its own version of reality, and if you - in your reality - hits something, that something will take damage on the server.
So, in YOUR reality, nothing is slow or wrong. Now, if you compare YOUR reality to your targets reality, they do differ a bit. But assuming a reasonable lag, not by enough to make it impossible to play.
There ARE some things that you need to be aware of when playing though - just like the side mirror says, "Your Enemy May Be Closer Than He Appears" - because you TAKE damage in your ENEMIES reality, you have to dodge IN YOUR ENEMIES reality. Which means dodging BEFORE you see him attacking. If you wait to move until you see the marine starting to take aim, you will die in HIS reality before you start moving in HIS reality.
Likewise, good marines dodge BEFORE the skulk is in range to bite; again, because you need to dodge in your attackers reality.
But this is predictable and known, and can be used by skilled players to their advantage (and its the same thing in all multi-player FPS shooters).
<!--quoteo(post=1982276:date=Sep 24 2012, 06:12 AM:name=matso)--><div class='quotetop'>QUOTE (matso @ Sep 24 2012, 06:12 AM) <a href="index.php?act=findpost&pid=1982276"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->In NS2 (and Source) the tickrate on the server will not affect player-player collisions. That's because players are not moved during the server tick, they are moved on the server as their moves are processed. It's kinda nifty; the server checks to see when you executed your move, time-shifts everyone to that time, processes your move (including you shooting your gun) and then time-shifts everyone back. Only AI units (and ragdolls) are moved during the server tick.<!--QuoteEnd--></div><!--QuoteEEnd-->
I don't get this, when does the moves are processed if it's not during a tick? What's the job of a tick if it doesn't process the movement of the players? By processing the move I mean integrating the position and the velocity.
If I have understood it, you will be moved at the server tick. But not to the place where you are right now, but to the place where you will probably be in 50ms (interp). Explained better here: <a href="https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Entity_interpolation" target="_blank">https://developer.valvesoftware.com/wiki/So...y_interpolation</a>
To the topic of collisions: What if you add a second collision-box double of the size of the first one. And if an entity is in this big collision-box you compute the collision of the smaller boxes, but considering the velocities and directions? This allows you to compute the collisions client side with the velocity and direction of the other entity in mind.
<!--quoteo(post=1981125:date=Sep 21 2012, 04:05 AM:name=Codeine)--><div class='quotetop'>QUOTE (Codeine @ Sep 21 2012, 04:05 AM) <a href="index.php?act=findpost&pid=1981125"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->ive been shot into the air about 50metres straight up a few times as a fade by blinking or sidestepping into marines/exosuits. So there is defiantly collision issues.<!--QuoteEnd--></div><!--QuoteEEnd-->
It's happened to me a couple times that, playing a Silenced skulk I've run after a marine for half the map (not a hyperbole) biting his ass without a single hit registering.
<!--quoteo(post=1982409:date=Sep 25 2012, 12:44 AM:name=Yuuki)--><div class='quotetop'>QUOTE (Yuuki @ Sep 25 2012, 12:44 AM) <a href="index.php?act=findpost&pid=1982409"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I don't get this, when does the moves are processed if it's not during a tick? What's the job of a tick if it doesn't process the movement of the players? By processing the move I mean integrating the position and the velocity.<!--QuoteEnd--></div><!--QuoteEEnd-->
This is the issue we were discussing in the other thread about <a href="http://www.unknownworlds.com/ns2/forums/index.php?showtopic=120514" target="_blank">parallel movement processing</a>.
NS2 handles all player movement integrated at the clients tickrate, based on the movement commands sent by the player (each movement command also records the frametime for the frame it was recorded in). If I understand it correctly, each server tick the server goes through each player in turn, and applies the player movement and shooting commands it has received for that player since the last tick. The important bit is it moves all other game entities to their past positions during this process - projectile traces, and (i think) collisions, are checked against the positions the entities were at the time the player sent those movement commands. (that's the lag compensation)
When it has finished handling all the player commands, then the regular server tick is run and the server simulated entities are moved (ragdolls, AI objects etc).
So player movement is handled once per server tick, but it uses the client tick rate as the time step, so is effectively being done at the client tick rate (just batched in chunks of several client ticks per server tick).
I hope that makes sense.
EDIT: the link Necro posted above describes the source version, which is different, as source games have a fixed input sampling rate. NS2 samples input at the client frame rate.
<!--quoteo(post=1982413:date=Sep 24 2012, 02:49 PM:name=_Necro_)--><div class='quotetop'>QUOTE (_Necro_ @ Sep 24 2012, 02:49 PM) <a href="index.php?act=findpost&pid=1982413"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->If I have understood it, you will be moved at the server tick. But not to the place where you are right now, but to the place where you will probably be in 50ms (interp). Explained better here: <a href="https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Entity_interpolation" target="_blank">https://developer.valvesoftware.com/wiki/So...y_interpolation</a><!--QuoteEnd--></div><!--QuoteEEnd-->
Yeah I get that, doesn't change that movement is processed every tick and that increasing tickrate increase precision of pretty much everything, by the laws of physics. In source at least:
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->The server simulates the game in discrete time steps called ticks. By default, the timestep is 15ms, so 66.666... ticks per second are simulated, but mods can specify their own tickrate. During each tick, the server processes incoming user commands, runs a physical simulation step, checks the game rules, and updates all object states. After simulating a tick, the server decides if any client needs a world update and takes a snapshot of the current world state if necessary. A higher tickrate increases the simulation precision, but also requires more CPU power and available bandwidth on both server and client.<!--QuoteEnd--></div><!--QuoteEEnd-->
Edit, ok thanks shad3r. That's a bit more clear, even though I'm not totally sure I understood everything. I noticed the server was using the client time step and was quite confused by it. Say you have a player with 10fps and another one with 100fps, how will the server deal with that? Will it make 10 times more update for the 100fps client?
<!--quoteo(post=1982418:date=Sep 25 2012, 01:04 AM:name=Yuuki)--><div class='quotetop'>QUOTE (Yuuki @ Sep 25 2012, 01:04 AM) <a href="index.php?act=findpost&pid=1982418"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Edit, ok thanks shad3r. That's a bit more clear, even though I'm not totally sure I understood everything. I noticed the server was using the client time step and was quite confused by it. Say you have a player with 10fps and another one with 100fps, how will the server deal with that? Will it make 10 times more update for the 100fps client?<!--QuoteEnd--></div><!--QuoteEEnd-->
Yes. The timestep used for the 10fps player movement integration will be 10 times longer than the timestep on the 100fps player movement integration.
<!--quoteo(post=1982423:date=Sep 25 2012, 01:15 AM:name=Yuuki)--><div class='quotetop'>QUOTE (Yuuki @ Sep 25 2012, 01:15 AM) <a href="index.php?act=findpost&pid=1982423"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->But if the server moves the 100fps client with a small timestep once every 1/30th of second, won't this player go slower than the 10fps one?<!--QuoteEnd--></div><!--QuoteEEnd-->
No, because the server runs more movement commands for the 100fps client. Each server tick, the server runs all the movement commands that are pending for each client (I haven't checked this in the code, but it squares with the discussion we were having in the thread I linked above).
So in the example you gave of a 30 tickrate server, the server will have new movement commands to run on average once every 3 ticks for the 10fps client, while it will have 3 movement commands to run every single tick for the 100fps client.
So the 10fps client has commands handled infrequently with a 100ms timestep, and the 100fps client has commands handled frequently with a 10ms timestep. It handles 33.33ms worth of movement for each client, each tick, _on average_. The high fps client just gets simulated more smoothly.
(It's possible there is interpolation done for low tickrate clients to avoid glitching, I haven't checked. I have seen players glitch around sometimes, so maybe not)
But it seems the server calls the movement code only once. Never understood how this thing work. It seems very costly (and unfair) to integrate several time the high fps clients.
I think the server calculates the position with the client-time in mind. The server knows, when it has received the last update from the client. When it receives the next update from the client it can calculate the distance from the last position to the new position by this time frame. It uses the time that has past since the last update to calculate how far the entity has moved. The velocity is a "fixed" value for every player in this case.
But it seems the server calls the movement code only once. Never understood how this thing work. It seems very costly (and unfair) to integrate several time the high fps clients.<!--QuoteEnd--></div><!--QuoteEEnd-->
I guess the output you get depends on where the logging code is in the server movement handling - wether it logs once per player or once per move command.
Easiest thing is read the code or better yet the thread I linked above, between matso and MOOtant the NS2 and source versions are explained pretty clearly in that thread. I haven't looked much at the code so I'm just repeating what I learned in that thread.
EDIT: regarding "unfair", it actually avoids some possible issues with the source version. There is a <a href="https://developer.valvesoftware.com/w/images/c/ca/Lag_compensation.jpg" target="_blank">famous image of CS:S hitboxes</a> that people always misinterpret, but what it is meant to show is the the slight difference between the client and server versions of the enemy player's hitbox positions at the time the client fired (red and blue). (ignore the model position, it shows something else). This hitbox difference shouldn't happen in NS2, if I understand it correctly, as both client and server will use the exact same timestep for all the calculations. In Source, different timesteps can be used for client movement prediction, client display, client input sampling, and server movement. In NS2, all 4 are the same.
It does mean there can be collision inconsistencies, especially with lagging players, who move large amounts each time their movement code is run with their large timestep.
Ok, I read the thread, I got it now. The system they use seems a bit weird at first, but I guess it also has its advantages. Is there some good papers on the subject (like comparing ns2 system vs source)?
<!--quoteo(post=1982455:date=Sep 25 2012, 02:53 AM:name=Yuuki)--><div class='quotetop'>QUOTE (Yuuki @ Sep 25 2012, 02:53 AM) <a href="index.php?act=findpost&pid=1982455"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Ok, I read the thread, I got it now. The system they use seems a bit weird at first, but I guess it also has its advantages. Is there some good papers on the subject (like comparing ns2 system vs source)?<!--QuoteEnd--></div><!--QuoteEEnd-->
I don't know of any other games that use NS2 style system, but I haven't really been looking, either. NS2 sourcecode, that thread, plus the valve developer article linked in it is probably the best there is.
I don't know how Unreal engine games work. I do know BF3 just gave up and now trusts the client for all hit detection (and maybe movement too?).
I got the idea of only checking the client data at random times (in an own thread) and trusting the client the rest of the time, for an own game. If the client data was wrong, it would observe this client more closely and kick it if the inconsistency are increasing. I don't know if that is such a good idea but I think it could prevent cheaters and save cpu time at the server.
<!--quoteo(post=1982465:date=Sep 24 2012, 07:18 PM:name=shad3r)--><div class='quotetop'>QUOTE (shad3r @ Sep 24 2012, 07:18 PM) <a href="index.php?act=findpost&pid=1982465"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I don't know how Unreal engine games work. I do know BF3 just gave up and now trusts the client for all hit detection (and maybe movement too?).<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo(post=1982405:date=Sep 24 2012, 09:36 AM:name=matso)--><div class='quotetop'>QUOTE (matso @ Sep 24 2012, 09:36 AM) <a href="index.php?act=findpost&pid=1982405"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Thing is, what you see on your screen _is_ your reality. Each player has its own version of reality, and if you - in your reality - hits something, that something will take damage on the server.
So, in YOUR reality, nothing is slow or wrong. Now, if you compare YOUR reality to your targets reality, they do differ a bit. But assuming a reasonable lag, not by enough to make it impossible to play.
There ARE some things that you need to be aware of when playing though - just like the side mirror says, "Your Enemy May Be Closer Than He Appears" - because you TAKE damage in your ENEMIES reality, you have to dodge IN YOUR ENEMIES reality. Which means dodging BEFORE you see him attacking. If you wait to move until you see the marine starting to take aim, you will die in HIS reality before you start moving in HIS reality.
Likewise, good marines dodge BEFORE the skulk is in range to bite; again, because you need to dodge in your attackers reality.
But this is predictable and known, and can be used by skilled players to their advantage (and its the same thing in all multi-player FPS shooters).<!--QuoteEnd--></div><!--QuoteEEnd-->
and this is why i hate sources netcode, youre playing more against the netcode than the player. which is another reason why source sucks for multiplayer / mods. its just not a very good engine imo.
<!--quoteo(post=1982832:date=Sep 25 2012, 08:30 AM:name=VeNeM)--><div class='quotetop'>QUOTE (VeNeM @ Sep 25 2012, 08:30 AM) <a href="index.php?act=findpost&pid=1982832"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->and this is why i hate sources netcode, youre playing more against the netcode than the player. which is another reason why source sucks for multiplayer / mods. its just not a very good engine imo.<!--QuoteEnd--></div><!--QuoteEEnd-->
Pretty much every multiplayer shooter I know of uses lag compensation just like Goldsrc/Source, which can cause the issues matso described above. Even Quake Live changed from the Q3 netcode to be lag compensated. The inconsistency is only a problem when your enemy has high pings.
Are there any shooters that don't use lag compensation? What game were you thinking of that had better netcode?
<!--quoteo(post=1983521:date=Sep 26 2012, 09:59 PM:name=Soul_Rider)--><div class='quotetop'>QUOTE (Soul_Rider @ Sep 26 2012, 09:59 PM) <a href="index.php?act=findpost&pid=1983521"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Bringing this back on-topic of collision models.....
Here is a video of clipping with the Gorge while belly-sliding. it is not so evident when walking, but when sliding on a slope it looks pretty bad....
Do we need more complex clipping meshes? Or multiple clipping 'pills' to cover the body and then extremities (arms, legs)?<!--QuoteEnd--></div><!--QuoteEEnd-->
I think that video is fine. Gorge won't be sliding on curved, sloped floors often.
It's only the marines using capsules that is an issue, IMO. The curved bottom seems to make it easy for a skulk to accidentally get under them, and extremely easy for a skulk to brush past them instead of connecting.
Soul_RiderMod BeanJoin Date: 2004-06-19Member: 29388Members, Constellation, Squad Five Blue
LOL, All Alien and Marine characters can clip into walls/props etc because of their collision boxes. How is that not a problem for what wants to be a professional high-quality game. I understand the Lerk wings need to be non-collision, as teh lerk doesn't fit down smaller corridors in NS2 with his wingspan, but even then it looks terrible.
Jump anywhere on a map where you can reach the ceiling with a jump, marine or alien, and your head will go through the ceiling, enabling you to see the world outside the room you are in. Most new players would consider that a bug. Hell, I consider that a bug. You should not be able to put any part of your body out of the world you are playing in, that is not professional. You may be keen to accept it, but I want NS2, and it's mods of course, to be taken seriously. Believe me there will be a lot of ridicule if these issues are not resolved at release. I know it happens in other games, you can often see enemy hands/guns through walls, but heads and legs, that's not good.
If anything the collision pills should encapsulate the whole body, making blocks outside the body space, not within it.
<!--quoteo(post=1983652:date=Sep 27 2012, 10:03 PM:name=Runteh)--><div class='quotetop'>QUOTE (Runteh @ Sep 27 2012, 10:03 PM) <a href="index.php?act=findpost&pid=1983652"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I haven't properly read this thread, but didn't Max say in the QA that the tick rate was only related to NPCs not player movement etc.
In that case, why is there not a way to monitor the tick rate for everything else?<!--QuoteEnd--></div><!--QuoteEEnd--> yea that got me wondering. If the server tickrate was capped at say 15, does that mean there wouldn't be any difference if you upped the tickrate to 30?
Comments
Indeed, in NS1 when you touched a marines from behind and bit them you didn't slide around them because you're going faster.
Probably because NS1 had square collisions boxes.
I asked on the stream Q&A about tickrate and max replied in chat saying it would have no benefit to increase it. I hope someone asks him about it in future if he is on the next stream because I don't really understand.
I thought that having a 60tickrate server would allow you to essentially turn the interpolation off. Isn't interp there because you are getting 20 updates a second from the server but probably playing at 60fps on a 60hz monitor? If it was only updating the enemy positions 20 times a second it would look laggy, so it adds a delay and then smooths between two packets. But if you were getting 60 updates then interpolation would only be needed when packets are dropped. Even then, I was always happy to turn off interp in source because the reduced delay was worth it.
I also thought in general increasing the server tickrate would increase the precision. Max obviously knows much more about it than me though. Perhaps it doesn't even matter anyway because ns2 might not ever be able to run at 60tickrate (even for only 12 players).
Perhaps updates could be increased to 30 times a second though over 20. Then interp could be reduced to 33.3ms
I asked on the stream Q&A about tickrate and max replied in chat saying it would have no benefit to increase it. I hope someone asks him about it in future if he is on the next stream because I don't really understand.<!--QuoteEnd--></div><!--QuoteEEnd-->
In NS2 (and Source) the tickrate on the server will not affect player-player collisions. That's because players are not moved during the server tick, they are moved on the server as their moves are processed. It's kinda nifty; the server checks to see when you executed your move, time-shifts everyone to that time, processes your move (including you shooting your gun) and then time-shifts everyone back.
Only AI units (and ragdolls) are moved during the server tick.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->I thought that having a 60tickrate server would allow you to essentially turn the interpolation off. Isn't interp there because you are getting 20 updates a second from the server but probably playing at 60fps on a 60hz monitor?<!--QuoteEnd--></div><!--QuoteEEnd-->
The tickrate of the server and how often the server sends you updates are two different things. The NS2 server runs at 30ticks internally, and sends updates 20 times per second, to save on bandwidth. Interpolation is then used to hide the bandwidth limitation.
I didn't think that increased tickrate would directly affect collisions, but it was just because you referenced the delay from interp I figured anything that could reduce that would have a benefit.
I understand that tickrate and updates sent to the client are two different things. I assume sending more updates than the tickrate would be pointless.
My question to Max on the stream was more general, i.e. would increasing the tickrate have any benefits? I guess if you didn't also increase the number of updates clients were receiving then it might not. Maybe that's what he was referring to. I don't know how much bandwidth sending 60 updates a second to all the clients would take. Although if you can run 24 player servers with 20 updates, then 12 players receiving 30 updates should be possible. I would imagine that sending more updates per second to the client would improve the precision and perhaps reduce the need for as much interpolation.
While on this subject, I felt like there has been some hit-reg issues for me, especially when playing at 150 ping. I particularly notice it with parasite. Sometimes I am sure my crosshair is on the marine and yet I miss. I'm not sure if this is an actual hit-reg problem though, it may just be the animations deceiving me. I may try recording some footage and watching it back in slow-mo to figure out what's going on.
Ummm isn't that super bad if your only sending 20 updates per second that means there is a 50ms gap between each update or about 3 frames if your running at 60fps then factor in you 50ms~ or so ping to the server...
Given that your only send position updates every 50ms to the server and the rest is interpolated wouldn't this cause chaos with the physics and hit boxes particularly for fast moving objects?
I can't see how you guys expect this to be an E-sport when the feedback loop is so slow/interpolated...
Given that your only send position updates every 50ms to the server and the rest is interpolated wouldn't this cause chaos with the physics and hit boxes particularly for fast moving objects?
I can't see how you guys expect this to be an E-sport when the feedback loop is so slow/interpolated...<!--QuoteEnd--></div><!--QuoteEEnd-->
Thing is, what you see on your screen _is_ your reality. Each player has its own version of reality, and if you - in your reality - hits something, that something will take damage on the server.
So, in YOUR reality, nothing is slow or wrong. Now, if you compare YOUR reality to your targets reality, they do differ a bit. But assuming a reasonable lag, not by enough to make it impossible to play.
There ARE some things that you need to be aware of when playing though - just like the side mirror says, "Your Enemy May Be Closer Than He Appears" - because you TAKE damage in your ENEMIES reality, you have to dodge IN YOUR ENEMIES reality. Which means dodging BEFORE you see him attacking. If you wait to move until you see the marine starting to take aim, you will die in HIS reality before you start moving in HIS reality.
Likewise, good marines dodge BEFORE the skulk is in range to bite; again, because you need to dodge in your attackers reality.
But this is predictable and known, and can be used by skilled players to their advantage (and its the same thing in all multi-player FPS shooters).
Only AI units (and ragdolls) are moved during the server tick.<!--QuoteEnd--></div><!--QuoteEEnd-->
I don't get this, when does the moves are processed if it's not during a tick? What's the job of a tick if it doesn't process the movement of the players? By processing the move I mean integrating the position and the velocity.
To the topic of collisions: What if you add a second collision-box double of the size of the first one. And if an entity is in this big collision-box you compute the collision of the smaller boxes, but considering the velocities and directions? This allows you to compute the collisions client side with the velocity and direction of the other entity in mind.
It's happened to me a couple times that, playing a Silenced skulk I've run after a marine for half the map (not a hyperbole) biting his ass without a single hit registering.
I kept wondering is marines have armored diapers.
This is the issue we were discussing in the other thread about <a href="http://www.unknownworlds.com/ns2/forums/index.php?showtopic=120514" target="_blank">parallel movement processing</a>.
NS2 handles all player movement integrated at the clients tickrate, based on the movement commands sent by the player (each movement command also records the frametime for the frame it was recorded in). If I understand it correctly, each server tick the server goes through each player in turn, and applies the player movement and shooting commands it has received for that player since the last tick. The important bit is it moves all other game entities to their past positions during this process - projectile traces, and (i think) collisions, are checked against the positions the entities were at the time the player sent those movement commands. (that's the lag compensation)
When it has finished handling all the player commands, then the regular server tick is run and the server simulated entities are moved (ragdolls, AI objects etc).
So player movement is handled once per server tick, but it uses the client tick rate as the time step, so is effectively being done at the client tick rate (just batched in chunks of several client ticks per server tick).
I hope that makes sense.
EDIT: the link Necro posted above describes the source version, which is different, as source games have a fixed input sampling rate. NS2 samples input at the client frame rate.
Yeah I get that, doesn't change that movement is processed every tick and that increasing tickrate increase precision of pretty much everything, by the laws of physics. In source at least:
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->The server simulates the game in discrete time steps called ticks. By default, the timestep is 15ms, so 66.666... ticks per second are simulated, but mods can specify their own tickrate. During each tick, the server processes incoming user commands, runs a physical simulation step, checks the game rules, and updates all object states. After simulating a tick, the server decides if any client needs a world update and takes a snapshot of the current world state if necessary. A higher tickrate increases the simulation precision, but also requires more CPU power and available bandwidth on both server and client.<!--QuoteEnd--></div><!--QuoteEEnd-->
Edit, ok thanks shad3r. That's a bit more clear, even though I'm not totally sure I understood everything. I noticed the server was using the client time step and was quite confused by it. Say you have a player with 10fps and another one with 100fps, how will the server deal with that? Will it make 10 times more update for the 100fps client?
Yes. The timestep used for the 10fps player movement integration will be 10 times longer than the timestep on the 100fps player movement integration.
No, because the server runs more movement commands for the 100fps client. Each server tick, the server runs all the movement commands that are pending for each client (I haven't checked this in the code, but it squares with the discussion we were having in the thread I linked above).
So in the example you gave of a 30 tickrate server, the server will have new movement commands to run on average once every 3 ticks for the 10fps client, while it will have 3 movement commands to run every single tick for the 100fps client.
So the 10fps client has commands handled infrequently with a 100ms timestep, and the 100fps client has commands handled frequently with a 10ms timestep. It handles 33.33ms worth of movement for each client, each tick, _on average_. The high fps client just gets simulated more smoothly.
(It's possible there is interpolation done for low tickrate clients to avoid glitching, I haven't checked. I have seen players glitch around sometimes, so maybe not)
<a href="http://unknownworlds.com/ns2/forums/index.php?showtopic=119947" target="_blank">http://unknownworlds.com/ns2/forums/index....howtopic=119947</a>
But it seems the server calls the movement code only once. Never understood how this thing work. It seems very costly (and unfair) to integrate several time the high fps clients.
The server knows, when it has received the last update from the client. When it receives the next update from the client it can calculate the distance from the last position to the new position by this time frame. It uses the time that has past since the last update to calculate how far the entity has moved. The velocity is a "fixed" value for every player in this case.
<a href="http://unknownworlds.com/ns2/forums/index.php?showtopic=119947" target="_blank">http://unknownworlds.com/ns2/forums/index....howtopic=119947</a>
But it seems the server calls the movement code only once. Never understood how this thing work. It seems very costly (and unfair) to integrate several time the high fps clients.<!--QuoteEnd--></div><!--QuoteEEnd-->
I guess the output you get depends on where the logging code is in the server movement handling - wether it logs once per player or once per move command.
Easiest thing is read the code or better yet the thread I linked above, between matso and MOOtant the NS2 and source versions are explained pretty clearly in that thread. I haven't looked much at the code so I'm just repeating what I learned in that thread.
EDIT: regarding "unfair", it actually avoids some possible issues with the source version. There is a <a href="https://developer.valvesoftware.com/w/images/c/ca/Lag_compensation.jpg" target="_blank">famous image of CS:S hitboxes</a> that people always misinterpret, but what it is meant to show is the the slight difference between the client and server versions of the enemy player's hitbox positions at the time the client fired (red and blue). (ignore the model position, it shows something else). This hitbox difference shouldn't happen in NS2, if I understand it correctly, as both client and server will use the exact same timestep for all the calculations. In Source, different timesteps can be used for client movement prediction, client display, client input sampling, and server movement. In NS2, all 4 are the same.
It does mean there can be collision inconsistencies, especially with lagging players, who move large amounts each time their movement code is run with their large timestep.
I don't know of any other games that use NS2 style system, but I haven't really been looking, either. NS2 sourcecode, that thread, plus the valve developer article linked in it is probably the best there is.
I don't know how Unreal engine games work. I do know BF3 just gave up and now trusts the client for all hit detection (and maybe movement too?).
With hilarious results.
So, in YOUR reality, nothing is slow or wrong. Now, if you compare YOUR reality to your targets reality, they do differ a bit. But assuming a reasonable lag, not by enough to make it impossible to play.
There ARE some things that you need to be aware of when playing though - just like the side mirror says, "Your Enemy May Be Closer Than He Appears" - because you TAKE damage in your ENEMIES reality, you have to dodge IN YOUR ENEMIES reality. Which means dodging BEFORE you see him attacking. If you wait to move until you see the marine starting to take aim, you will die in HIS reality before you start moving in HIS reality.
Likewise, good marines dodge BEFORE the skulk is in range to bite; again, because you need to dodge in your attackers reality.
But this is predictable and known, and can be used by skilled players to their advantage (and its the same thing in all multi-player FPS shooters).<!--QuoteEnd--></div><!--QuoteEEnd-->
and this is why i hate sources netcode, youre playing more against the netcode than the player. which is another reason why source sucks for multiplayer / mods. its just not a very good engine imo.
Here is a video of clipping with the Gorge while belly-sliding. it is not so evident when walking, but when sliding on a slope it looks pretty bad....
<center><object width="450" height="356"><param name="movie" value="http://www.youtube.com/v/NUJlHLnahXE"></param><embed src="http://www.youtube.com/v/NUJlHLnahXE" type="application/x-shockwave-flash" width="450" height="356"></embed></object></center>
Do we need more complex clipping meshes? Or multiple clipping 'pills' to cover the body and then extremities (arms, legs)?
Pretty much every multiplayer shooter I know of uses lag compensation just like Goldsrc/Source, which can cause the issues matso described above. Even Quake Live changed from the Q3 netcode to be lag compensated. The inconsistency is only a problem when your enemy has high pings.
Are there any shooters that don't use lag compensation? What game were you thinking of that had better netcode?
<!--quoteo(post=1983521:date=Sep 26 2012, 09:59 PM:name=Soul_Rider)--><div class='quotetop'>QUOTE (Soul_Rider @ Sep 26 2012, 09:59 PM) <a href="index.php?act=findpost&pid=1983521"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Bringing this back on-topic of collision models.....
Here is a video of clipping with the Gorge while belly-sliding. it is not so evident when walking, but when sliding on a slope it looks pretty bad....
<center><object width="450" height="356"><param name="movie" value="http://www.youtube.com/v/NUJlHLnahXE"></param><embed src="http://www.youtube.com/v/NUJlHLnahXE" type="application/x-shockwave-flash" width="450" height="356"></embed></object></center>
Do we need more complex clipping meshes? Or multiple clipping 'pills' to cover the body and then extremities (arms, legs)?<!--QuoteEnd--></div><!--QuoteEEnd-->
I think that video is fine. Gorge won't be sliding on curved, sloped floors often.
It's only the marines using capsules that is an issue, IMO. The curved bottom seems to make it easy for a skulk to accidentally get under them, and extremely easy for a skulk to brush past them instead of connecting.
Jump anywhere on a map where you can reach the ceiling with a jump, marine or alien, and your head will go through the ceiling, enabling you to see the world outside the room you are in. Most new players would consider that a bug. Hell, I consider that a bug. You should not be able to put any part of your body out of the world you are playing in, that is not professional. You may be keen to accept it, but I want NS2, and it's mods of course, to be taken seriously. Believe me there will be a lot of ridicule if these issues are not resolved at release. I know it happens in other games, you can often see enemy hands/guns through walls, but heads and legs, that's not good.
If anything the collision pills should encapsulate the whole body, making blocks outside the body space, not within it.
In that case, why is there not a way to monitor the tick rate for everything else?
In that case, why is there not a way to monitor the tick rate for everything else?<!--QuoteEnd--></div><!--QuoteEEnd-->
yea that got me wondering. If the server tickrate was capped at say 15, does that mean there wouldn't be any difference if you upped the tickrate to 30?