At the risk of talking out of my ass, because I don't have the benefit of looking at the NS2 netcode, this is what I would consider to be prime suspects:
Perhaps the server tries firing before it updates your view direction, so that you are firing slightly in the wrong direction. This would feel like you need to lead your shots slightly.
Perhaps the client does not send the time stamp for when the action was actually performed, but there is instead just one time stamp for the entire packet. If the client is sending a packet every 33 ms(30 times a second to match the tickrate of 30 on the server) then there will be a random delay of 0 to 33 ms between when you actually fired and when the server thinks you fired. On average you would have to lead your shots slightly.
Perhaps there is some off-by-one bug in the lag correction mechanism such that the server interpolates between the wrong pair of enemy player positions. This would have the effect of you having to lead your targets or follow behind your targets by about 33 ms.
Perhaps the server is not correctly handling ACKs for packets recieved by the client. The server needs to correctly keep track of which packets you have recieved, otherwise it cannot correctly figure out how to extrapolate or between what to interpolate when it does lag correction; it occassionally makes an incorrect guess at what you saw. It's not just packet loss that would cause this, packets aren't guaranteed to arrive at any particular time frame or in any particular order.
Something could be subtly wrong with the way timestamps are implemented. It's not obvious how to design this in an optimal or even correct way. The player needs to be able to accurately tell the server when it fired. The first thought that springs to mind is that you would want to refer to some events with definite times on the server; e.g. I was interpolating between packet A and packet B(where both contain definite times, e.g. 73 and 106 ms after the last packet which the client ACKed) and x ms had passed since A. That should allow the server to _exactly_ compensate for lag in regards to reg. But that's not the way most games do it(compensate by <b>average</b> latency + interp) and there's probably some clever reason why you can't do it the naïve way I proposed.
There could be some bug in the rewinding of time. E.g. an animation bug where player positions are rewound accurately but the animation pose of players are not.
I think the best thing to do is to take the time to extend the system they have in place for debugging already with player hitbox snapshot data. The client has information on how the hitboxes looked on the enemy player when it fired and it has its own position and view direction. The server can, if put in debug mode, send reliable data to the client(resend until ACKed) containing the hitboxes of players as they looked on the server when the player fired. Also contained in the packet would be player view direction, location and bullets trajectories. Now you can visually draw both hitbox data and compare. There are also lots of interesting variables you might want to log(timestamps and so forth).
I also believe this problem at least in parts originates from client/server performance. I can't remeber an instance where I shot an alien without doing damage except when I play on UK servers where I have pings >80. It seems legit that any combination of some clients being "faster" then the server while other clients struggle to reach even 30 fps(where 60 is barely enough) and therefor adequate game speed leads to problems with the hit-reg.
Not always but often people blame the game for problems that are really created by their computer not being good enough for the game. E.g. I don't have any performance problems whatsoever, while people claim that the game is badly written. While it may be true that the game is hardware hungry, these issues people experiance no real performance bugs. Same is true for Hitreg, wehre some people claim to miss every shot while others hardly notice problems with hitreg.
I really think the guy some pages ago suggesting to investigate the influence of server/client tickrates on these hitreg issues had some good points.
In that amazing video gliss posted, if you watch the frames befor the fade blinks, after the client blood, the model snaps back about 1 game meter. Does the model animate that way or was that a teleporting object?
<!--quoteo(post=2041138:date=Dec 6 2012, 12:01 PM:name=OnosFactory)--><div class='quotetop'>QUOTE (OnosFactory @ Dec 6 2012, 12:01 PM) <a href="index.php?act=findpost&pid=2041138"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->In that amazing video gliss posted, if you watch the frames befor the fade blinks, after the client blood, the model snaps back about 1 game meter. Does the model animate that way or was that a teleporting object?<!--QuoteEnd--></div><!--QuoteEEnd--> that's just rubberbanding, it happens constantly. anytime I rubberband, the prediction frames move from the average of 3-4 to 10+, at which point every model's position just snaps backward. I don't really know how to prevent this from happening but it's at least a few times every minute and it can be quite aggravating. I think it's an issue with my connection, I have no idea how to test this though.
edit: just made this clip to isolate the rubberbanding
<a href="http://www.youtube.com/watch?v=VScPsFNpfD4" target="_blank">http://www.youtube.com/watch?v=VScPsFNpfD4</a> the first shot is a bonus hilarious representation of the random shotgun spread, and the final shot - my crosshair is never on the Lerk, but it looks like in the process of rubberbanding the hitbox is somewhere in between the two teleporting points. not sure what to make of this.
<!--quoteo(post=2040747:date=Dec 5 2012, 09:55 PM:name=sedek)--><div class='quotetop'>QUOTE (sedek @ Dec 5 2012, 09:55 PM) <a href="index.php?act=findpost&pid=2040747"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I just can't shake the weird sensation of something being off when watching your shotgun snap 40+ pixels perfectly onto the Fade as he's dancing. Not once, but twice. Is this what a good player looks like? Blurring the line between perfect aimbot and human twitching?<!--QuoteEnd--></div><!--QuoteEEnd-->
Players warping around is also a huge problem certainly. Doesnt really matter how good your own/the opponents ping is (or server performance overall), there is always a lot of warping regardless. Then when you add hits simply not registering, game stopping for half a sec when making full shotgun hit due to particle effects, and the warping you realize the reason why marines seem to be losing more. Also makes parasiting a pain if marine just changes strafing distance - instant 1 meter warp throwing your aim completely off.
<!--quoteo(post=2041099:date=Dec 6 2012, 01:21 PM:name=Soylent_green)--><div class='quotetop'>QUOTE (Soylent_green @ Dec 6 2012, 01:21 PM) <a href="index.php?act=findpost&pid=2041099"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->At the risk of talking out of my ass, because I don't have the benefit of looking at the NS2 netcode, this is what I would consider to be prime suspects:
Perhaps the server tries firing before it updates your view direction, so that you are firing slightly in the wrong direction. This would feel like you need to lead your shots slightly.
Perhaps the client does not send the time stamp for when the action was actually performed, but there is instead just one time stamp for the entire packet. If the client is sending a packet every 33 ms(30 times a second to match the tickrate of 30 on the server) then there will be a random delay of 0 to 33 ms between when you actually fired and when the server thinks you fired. On average you would have to lead your shots slightly.<!--QuoteEnd--></div><!--QuoteEEnd--> Unless max just totally threw out all the papers on net code interpolation and didn't even read Wikipedia when he implemented it, both of these are unlikely. I think either of those would result a signifigantly worse sense of hitreg than we currently have.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Perhaps there is some off-by-one bug in the lag correction mechanism such that the server interpolates between the wrong pair of enemy player positions. This would have the effect of you having to lead your targets or follow behind your targets by about 33 ms.<!--QuoteEnd--></div><!--QuoteEEnd-->It doesn't feel like this. I don't feel more accurate leading or trailing opponents. And different servers (with the same tic rate) seem to have different hitreg situations.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Perhaps the server is not correctly handling ACKs for packets recieved by the client. The server needs to correctly keep track of which packets you have recieved, otherwise it cannot correctly figure out how to extrapolate or between what to interpolate when it does lag correction; it occassionally makes an incorrect guess at what you saw. It's not just packet loss that would cause this, packets aren't guaranteed to arrive at any particular time frame or in any particular order.<!--QuoteEnd--></div><!--QuoteEEnd--> I would hope max would have paid better attention to his networking classes than this... but it's actually possible, as MOST packets will arrive on the right time and in the right order, but there will be occasional dropped packets and out of order packets, and if your system's solution doesn't handle them properly it will cause a lot of problems depending how it's handled. I've heard game state is transferred via UDP... Some things you can probably get away with in UDP (where skulks on the opposite side of the map are) I really feel hitreg should be transferred via TCP. However, I haven't read specific papers on the industry standards, I'm just expressing my feelings based on my network training.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Something could be subtly wrong with the way timestamps are implemented. It's not obvious how to design this in an optimal or even correct way. The player needs to be able to accurately tell the server when it fired. The first thought that springs to mind is that you would want to refer to some events with definite times on the server; e.g. I was interpolating between packet A and packet B(where both contain definite times, e.g. 73 and 106 ms after the last packet which the client ACKed) and x ms had passed since A. That should allow the server to _exactly_ compensate for lag in regards to reg. But that's not the way most games do it(compensate by <b>average</b> latency + interp) and there's probably some clever reason why you can't do it the naïve way I proposed.<!--QuoteEnd--></div><!--QuoteEEnd-->Because your latency determines how far behind you are from the server's game state, and how far the server is behind from your motion state. It's weird to think of it this way, but in game time is actually slightly compressing and expanding as your latency shifts. Interpolation masks this effect.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->There could be some bug in the rewinding of time. E.g. an animation bug where player positions are rewound accurately but the animation pose of players are not.<!--QuoteEnd--></div><!--QuoteEEnd-->interpolation doesn't ever actually rewind time visually, it's purely systemic calculations. Server side it doesn't render animations or models at all, it just holds data of where player models are, client side, your animations are never "current" they are always representations of a past game state, there's no rewinding necessary. You just simply see events that actually happened 200 or so ms ago as if they were in real time to you, and likewise, the things you do don't happen for another 200ms average for every other player (however, the server sees them somewhat sooner than that)
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->I think the best thing to do is to take the time to extend the system they have in place for debugging already with player hitbox snapshot data. The client has information on how the hitboxes looked on the enemy player when it fired and it has its own position and view direction. The server can, if put in debug mode, send reliable data to the client(resend until ACKed) containing the hitboxes of players as they looked on the server when the player fired. Also contained in the packet would be player view direction, location and bullets trajectories. Now you can visually draw both hitbox data and compare. There are also lots of interesting variables you might want to log(timestamps and so forth).<!--QuoteEnd--></div><!--QuoteEEnd-->I agree, but it's a fair bit of work, I think they're hoping it's a minor error and they can just hotfix it. Rather than having to comprehensively troubleshoot something that was basically copied from other game engines.
<!--quoteo(post=2041152:date=Dec 6 2012, 03:30 PM:name=elmo9000)--><div class='quotetop'>QUOTE (elmo9000 @ Dec 6 2012, 03:30 PM) <a href="index.php?act=findpost&pid=2041152"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Players warping around is also a huge problem certainly. Doesnt really matter how good your own/the opponents ping is (or server performance overall), there is always a lot of warping regardless. Then when you add hits simply not registering, game stopping for half a sec when making full shotgun hit due to particle effects, and the warping you realize the reason why marines seem to be losing more. Also makes parasiting a pain if marine just changes strafing distance - instant 1 meter warp throwing your aim completely off.<!--QuoteEnd--></div><!--QuoteEEnd--> Most games have this effect when the network settings are tweaked to be as accurate as possible and work with maximum performance. The warping is a side effect network data transmission just being outright unreliable. There are systems in place to mask it, but fundamentally it's not a "problem" that the game isn't smooth, it's a side effect of problems in the internet system we all use, and game developers have absolutely zero access to fixing.
[edit]not to say there can't be errors in the way a game has implemented the smoothing systems.
ScardyBobScardyBobJoin Date: 2009-11-25Member: 69528Forum Admins, Forum Moderators, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Shadow
<!--quoteo(post=2040766:date=Dec 5 2012, 08:48 PM:name=xDragon)--><div class='quotetop'>QUOTE (xDragon @ Dec 5 2012, 08:48 PM) <a href="index.php?act=findpost&pid=2040766"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->No point having r_stats on, net_stats shows your FPS anyways (Client rate)<!--QuoteEnd--></div><!--QuoteEEnd--> True, but I'd like to rule out other possibilities, such as having a high number of predicted frames, waiting on GPU/render thread issues, etc, which only r_stats provide. The more info, the easier it will be to fix the problem.
Also, if you're feeling adventerous, you could even turn on the rest of the stats (g_stats, e_stats, p_stats, s_stats, fx_stats, fx_stats, nav_stats), though it might become too much of a mess.
<!--quoteo(post=2041182:date=Dec 6 2012, 04:35 PM:name=Swiftspear)--><div class='quotetop'>QUOTE (Swiftspear @ Dec 6 2012, 04:35 PM) <a href="index.php?act=findpost&pid=2041182"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Unless max just totally threw out all the papers on net code interpolation and didn't even read Wikipedia when he implemented it, both of these are unlikely. I think either of those would result a signifigantly worse sense of hitreg than we currently have.<!--QuoteEnd--></div><!--QuoteEEnd-->
Bugs are usually not implemented intentionally. There was a similar bug just a few patches ago that affected reg.
<!--quoteo(post=2041182:date=Dec 6 2012, 04:35 PM:name=Swiftspear)--><div class='quotetop'>QUOTE (Swiftspear @ Dec 6 2012, 04:35 PM) <a href="index.php?act=findpost&pid=2041182"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Because your latency determines how far behind you are from the server's game state, and how far the server is behind from your motion state.<!--QuoteEnd--></div><!--QuoteEEnd-->
You can get the time in the past your client is supposed to live in by keeping a moving average of latency, yet still refer perfectly accurately to the time you fired at a player as "interpolating between packet A and C and 17.7 ms having past since the gametime in packet A"(these packets would have to contain when they were generated on the server and there needs to be sanity checks so that players are traveling only forward in time and at a reasonable rate).
There is something more subtle preventing this. The source engine and several other engines guess at the time the player fired by subtracting average latency + interp from the time when the command packet arrived and use this time to rewind and check for hits. This is very susceptible to jitter in frame render times and network latency, so why do it this way?
That makes no difference. You cannot "just interpolate" past hitbox positions; you have to calculate properly a frame of skeletal animation, including animation blending(looking, flinching etc.), for those hitboxes. There may be infered properties that are not even stored explicitly that have to be recalculated. E.g. a skulk model's actual rotation might not be stored if it can be inferred from view angles and position.
<!--quoteo(post=2041182:date=Dec 6 2012, 04:35 PM:name=Swiftspear)--><div class='quotetop'>QUOTE (Swiftspear @ Dec 6 2012, 04:35 PM) <a href="index.php?act=findpost&pid=2041182"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I agree, but it's a fair bit of work, I think they're hoping it's a minor error and they can just hotfix it. Rather than having to comprehensively troubleshoot something that was basically copied from other game engines.<!--QuoteEnd--></div><!--QuoteEEnd-->
I can't think of a game that implemented lag compensations without subtle and not so subtle bugs that took years to fix or ugly trade offs that were improved.
<!--quoteo(post=2041099:date=Dec 6 2012, 01:21 PM:name=Soylent_green)--><div class='quotetop'>QUOTE (Soylent_green @ Dec 6 2012, 01:21 PM) <a href="index.php?act=findpost&pid=2041099"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Perhaps the server tries firing before it updates your view direction, so that you are firing slightly in the wrong direction. This would feel like you need to lead your shots slightly.<!--QuoteEnd--></div><!--QuoteEEnd--> They actually had a problem like this, around 225 (just before release), that was already fixed.
To any UWE staff that view that, I have a larger version I can upload to FTP / send to the staff. I understand you want to go frame by frame, I also have all demos available including Javahulk's first person demo. Just need a place to send them / upload then. PM me if necessary.
I know it's a poor edited film, I didn't really have time or energy to put much into it, but it should do the trick.
Edit: The points I reference are much clearer frame by frame.
<!--quoteo(post=2041424:date=Dec 7 2012, 11:09 AM:name=Omar - The Wire)--><div class='quotetop'>QUOTE (Omar - The Wire @ Dec 7 2012, 11:09 AM) <a href="index.php?act=findpost&pid=2041424"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I know it's a poor edited film, I didn't really have time or energy to put much into it, but it should do the trick.<!--QuoteEnd--></div><!--QuoteEEnd--> Are you practicing in modesty? You definitely put some effort into this movie. Tanks. :)
<!--quoteo(post=2041424:date=Dec 7 2012, 04:09 AM:name=Omar - The Wire)--><div class='quotetop'>QUOTE (Omar - The Wire @ Dec 7 2012, 04:09 AM) <a href="index.php?act=findpost&pid=2041424"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec--><a href="http://youtu.be/r32PiW8k8uo" target="_blank">http://youtu.be/r32PiW8k8uo</a>
There is a 720p HD version uploaded there.
To any UWE staff that view that, I have a larger version I can upload to FTP / send to the staff. I understand you want to go frame by frame, I also have all demos available including Javahulk's first person demo. Just need a place to send them / upload then. PM me if necessary.
I know it's a poor edited film, I didn't really have time or energy to put much into it, but it should do the trick.
Edit: The points I reference are much clearer frame by frame.<!--QuoteEnd--></div><!--QuoteEEnd-->
Some of your initial claims are based on the assumption that there is bullet travel. For example, that the skulk dropped in front of your rifle in between bullets. I was under the impression that the guns are hitscan weapons (as in no bullet time)?
<!--quoteo(post=2041536:date=Dec 7 2012, 08:00 AM:name=include)--><div class='quotetop'>QUOTE (include @ Dec 7 2012, 08:00 AM) <a href="index.php?act=findpost&pid=2041536"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Some of your initial claims are based on the assumption that there is bullet travel. For example, that the skulk dropped in front of your rifle in between bullets. I was under the impression that the guns are hitscan weapons (as in no bullet time)?<!--QuoteEnd--></div><!--QuoteEEnd--> there is a difference between bullet travel time and time between shots.
ScardyBobScardyBobJoin Date: 2009-11-25Member: 69528Forum Admins, Forum Moderators, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Shadow
<!--quoteo(post=2041424:date=Dec 7 2012, 02:09 AM:name=Omar - The Wire)--><div class='quotetop'>QUOTE (Omar - The Wire @ Dec 7 2012, 02:09 AM) <a href="index.php?act=findpost&pid=2041424"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec--><a href="http://youtu.be/r32PiW8k8uo" target="_blank">http://youtu.be/r32PiW8k8uo</a>
There is a 720p HD version uploaded there.
To any UWE staff that view that, I have a larger version I can upload to FTP / send to the staff. I understand you want to go frame by frame, I also have all demos available including Javahulk's first person demo. Just need a place to send them / upload then. PM me if necessary.
I know it's a poor edited film, I didn't really have time or energy to put much into it, but it should do the trick.
Edit: The points I reference are much clearer frame by frame.<!--QuoteEnd--></div><!--QuoteEEnd--> Nice work. Though, its refreshing to see that we aren't the only ones having trouble reproducing this issue. We know it exists and happens on a semi-regular basis, but getting it to occur in a controlled environment where we can track down the problem has proven difficult.
The other thoughts I've had to try and see if they are related are - Test hitreg when you have low fps (but on a good server with low ping) - Test hitreg when you have high ping (but on a good server with good fps) - Test hitreg when your on a poor server (but with low ping and good fps)
<!--quoteo(post=2041505:date=Dec 7 2012, 06:11 AM:name=Husar)--><div class='quotetop'>QUOTE (Husar @ Dec 7 2012, 06:11 AM) <a href="index.php?act=findpost&pid=2041505"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Are you practicing in modesty? You definitely put some effort into this movie. Tanks. :)<!--QuoteEnd--></div><!--QuoteEEnd--> Not really, but thanks anyways!
<!--quoteo(post=2041536:date=Dec 7 2012, 08:00 AM:name=include)--><div class='quotetop'>QUOTE (include @ Dec 7 2012, 08:00 AM) <a href="index.php?act=findpost&pid=2041536"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Some of your initial claims are based on the assumption that there is bullet travel. For example, that the skulk dropped in front of your rifle in between bullets. I was under the impression that the guns are hitscan weapons (as in no bullet time)?<!--QuoteEnd--></div><!--QuoteEEnd--> See Glissy's quote below.
<!--quoteo(post=2041611:date=Dec 7 2012, 10:51 AM:name=Gliss)--><div class='quotetop'>QUOTE (Gliss @ Dec 7 2012, 10:51 AM) <a href="index.php?act=findpost&pid=2041611"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->there is a difference between bullet travel time and time between shots.<!--QuoteEnd--></div><!--QuoteEEnd-->Exactly. I don't do a single thing that is based on a bullet "traveling" but simply time between shots. In fact, I make it clear I assume "if a shot is fired, as far as I can tell, if the crosshair is on target it should be a hit". That's pretty much the lazy man's definition of hit scan.
<!--quoteo(post=2041636:date=Dec 7 2012, 01:36 PM:name=Omar - The Wire)--><div class='quotetop'>QUOTE (Omar - The Wire @ Dec 7 2012, 01:36 PM) <a href="index.php?act=findpost&pid=2041636"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Not really, but thanks anyways!
See Glissy's quote below.
Exactly. I don't do a single thing that is based on a bullet "traveling" but simply time between shots. In fact, I make it clear I assume "if a shot is fired, as far as I can tell, if the crosshair is on target it should be a hit". That's pretty much the lazy man's definition of hit scan.<!--QuoteEnd--></div><!--QuoteEEnd-->
Okay good. I just wanted to make sure. :) A few people think the game is projectile based. As you are attempting to do in your videos, I'm just trying to help ensure that something isn't based off of inaccurate information and to reduce false positives.
This would be much easier if the drawdamage wasn't so terrible. Seriously whose stupid idea was it to make numbers pop up that are not only hard to see but also instead of showing the actual number they add up from 0? That's completely retarded. Might as well disable them since you have no idea how much damage you are actually doing at any given time. NS2 should have extended its beta.
<!--quoteo(post=2041223:date=Dec 6 2012, 05:37 PM:name=Soylent_green)--><div class='quotetop'>QUOTE (Soylent_green @ Dec 6 2012, 05:37 PM) <a href="index.php?act=findpost&pid=2041223"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I can't think of a game that implemented lag compensations without subtle and not so subtle bugs that took years to fix or ugly trade offs that were improved.<!--QuoteEnd--></div><!--QuoteEEnd--> For the record, I do agree with you on this. It's wisest to have hitreg issues as something covered under the blanket of debugging. Especially when you're not just giving the players and servers the variable points to play with.
<!--quoteo(post=2041652:date=Dec 7 2012, 04:28 PM:name=NeoRussia)--><div class='quotetop'>QUOTE (NeoRussia @ Dec 7 2012, 04:28 PM) <a href="index.php?act=findpost&pid=2041652"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->This would be much easier if the drawdamage wasn't so terrible. Seriously whose stupid idea was it to make numbers pop up that are not only hard to see but also instead of showing the actual number they add up from 0? That's completely retarded. Might as well disable them since you have no idea how much damage you are actually doing at any given time. NS2 should have extended its beta.<!--QuoteEnd--></div><!--QuoteEEnd-->
the only really dumb thing is that they tried to make it 'scroll' the damage up over time instead of making it instant-update. kind of how they used to do the health bars when you got hit.
it was a bad idea then, and it's still a bad idea. i'm not shocked at all that they didn't learn from their mistakes.
<!--quoteo(post=2041706:date=Dec 7 2012, 05:04 PM:name=Wheeee)--><div class='quotetop'>QUOTE (Wheeee @ Dec 7 2012, 05:04 PM) <a href="index.php?act=findpost&pid=2041706"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->the only really dumb thing is that they tried to make it 'scroll' the damage up over time instead of making it instant-update. kind of how they used to do the health bars when you got hit.
it was a bad idea then, and it's still a bad idea. i'm not shocked at all that they didn't learn from their mistakes.<!--QuoteEnd--></div><!--QuoteEEnd--> I really disagree with this. The scroll allows the numbers to be accurate server side. If they did instant pop up numbers it would have to be client side.
Thanks Gliss, yeah that rubberbanding is horrible on servers that hit 26% performance lol ... still, you aimed at where that lerk should be and still hit it so I guess thats the trade off.
I made a demo this morning (hangover saturday). Its kind of long, but I'm shooting at things for most of the game. In the demo1 file I'm pinging ~20ms to a local NZ server so connectivity should not be an issue. This demo contains both LMG and shotgun versus skulks.
<u>Specs:</u> Core i7 3770k 3.5 GHz (no OC) Radeon HD 7870 OC 16 GB RAM SSD Win8 x64
<!--quoteo(post=2041719:date=Dec 7 2012, 06:21 PM:name=Swiftspear)--><div class='quotetop'>QUOTE (Swiftspear @ Dec 7 2012, 06:21 PM) <a href="index.php?act=findpost&pid=2041719"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I really disagree with this. The scroll allows the numbers to be accurate server side. If they did instant pop up numbers it would have to be client side.<!--QuoteEnd--></div><!--QuoteEEnd-->
That's not true. There's a delay anyway. There is almost a whole second delay with how NS2 interpolation works.
<!--quoteo(post=2041736:date=Dec 7 2012, 05:46 PM:name=NeoRussia)--><div class='quotetop'>QUOTE (NeoRussia @ Dec 7 2012, 05:46 PM) <a href="index.php?act=findpost&pid=2041736"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->That's not true. There's a delay anyway. There is almost a whole second delay with how NS2 interpolation works.<!--QuoteEnd--></div><!--QuoteEEnd--> The delay is because it's server side. It would be VERY disorienting to have damage numbers pop up a half second later if they didn't scroll. You'd have no idea what was hitting and when. The current system isn't amazing for hit feedback, but it gives you a really good sense of how much damage you're registering, and therefore how efficient your attacks are.
Or they could have instant animations with feedback sent from the server.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->I really feel hitreg should be transferred via TCP.<!--QuoteEnd--></div><!--QuoteEEnd--> This is a terrible idea, it'll essentially double your response time because you have to wait for acks.
Comments
Perhaps the server tries firing before it updates your view direction, so that you are firing slightly in the wrong direction. This would feel like you need to lead your shots slightly.
Perhaps the client does not send the time stamp for when the action was actually performed, but there is instead just one time stamp for the entire packet. If the client is sending a packet every 33 ms(30 times a second to match the tickrate of 30 on the server) then there will be a random delay of 0 to 33 ms between when you actually fired and when the server thinks you fired. On average you would have to lead your shots slightly.
Perhaps there is some off-by-one bug in the lag correction mechanism such that the server interpolates between the wrong pair of enemy player positions. This would have the effect of you having to lead your targets or follow behind your targets by about 33 ms.
Perhaps the server is not correctly handling ACKs for packets recieved by the client. The server needs to correctly keep track of which packets you have recieved, otherwise it cannot correctly figure out how to extrapolate or between what to interpolate when it does lag correction; it occassionally makes an incorrect guess at what you saw. It's not just packet loss that would cause this, packets aren't guaranteed to arrive at any particular time frame or in any particular order.
Something could be subtly wrong with the way timestamps are implemented. It's not obvious how to design this in an optimal or even correct way. The player needs to be able to accurately tell the server when it fired. The first thought that springs to mind is that you would want to refer to some events with definite times on the server; e.g. I was interpolating between packet A and packet B(where both contain definite times, e.g. 73 and 106 ms after the last packet which the client ACKed) and x ms had passed since A. That should allow the server to _exactly_ compensate for lag in regards to reg. But that's not the way most games do it(compensate by <b>average</b> latency + interp) and there's probably some clever reason why you can't do it the naïve way I proposed.
There could be some bug in the rewinding of time. E.g. an animation bug where player positions are rewound accurately but the animation pose of players are not.
I think the best thing to do is to take the time to extend the system they have in place for debugging already with player hitbox snapshot data. The client has information on how the hitboxes looked on the enemy player when it fired and it has its own position and view direction. The server can, if put in debug mode, send reliable data to the client(resend until ACKed) containing the hitboxes of players as they looked on the server when the player fired. Also contained in the packet would be player view direction, location and bullets trajectories. Now you can visually draw both hitbox data and compare. There are also lots of interesting variables you might want to log(timestamps and so forth).
I can't remeber an instance where I shot an alien without doing damage except when I play on UK servers where I have pings >80.
It seems legit that any combination of some clients being "faster" then the server while other clients struggle to reach even 30 fps(where 60 is barely enough) and therefor adequate game speed leads to problems with the hit-reg.
Not always but often people blame the game for problems that are really created by their computer not being good enough for the game. E.g. I don't have any performance problems whatsoever, while people claim that the game is badly written. While it may be true that the game is hardware hungry, these issues people experiance no real performance bugs.
Same is true for Hitreg, wehre some people claim to miss every shot while others hardly notice problems with hitreg.
I really think the guy some pages ago suggesting to investigate the influence of server/client tickrates on these hitreg issues had some good points.
that's just rubberbanding, it happens constantly. anytime I rubberband, the prediction frames move from the average of 3-4 to 10+, at which point every model's position just snaps backward. I don't really know how to prevent this from happening but it's at least a few times every minute and it can be quite aggravating. I think it's an issue with my connection, I have no idea how to test this though.
edit: just made this clip to isolate the rubberbanding
<a href="http://www.youtube.com/watch?v=VScPsFNpfD4" target="_blank">http://www.youtube.com/watch?v=VScPsFNpfD4</a>
the first shot is a bonus hilarious representation of the random shotgun spread, and the final shot - my crosshair is never on the Lerk, but it looks like in the process of rubberbanding the hitbox is somewhere in between the two teleporting points. not sure what to make of this.
Yes.
Perhaps the server tries firing before it updates your view direction, so that you are firing slightly in the wrong direction. This would feel like you need to lead your shots slightly.
Perhaps the client does not send the time stamp for when the action was actually performed, but there is instead just one time stamp for the entire packet. If the client is sending a packet every 33 ms(30 times a second to match the tickrate of 30 on the server) then there will be a random delay of 0 to 33 ms between when you actually fired and when the server thinks you fired. On average you would have to lead your shots slightly.<!--QuoteEnd--></div><!--QuoteEEnd-->
Unless max just totally threw out all the papers on net code interpolation and didn't even read Wikipedia when he implemented it, both of these are unlikely. I think either of those would result a signifigantly worse sense of hitreg than we currently have.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Perhaps there is some off-by-one bug in the lag correction mechanism such that the server interpolates between the wrong pair of enemy player positions. This would have the effect of you having to lead your targets or follow behind your targets by about 33 ms.<!--QuoteEnd--></div><!--QuoteEEnd-->It doesn't feel like this. I don't feel more accurate leading or trailing opponents. And different servers (with the same tic rate) seem to have different hitreg situations.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Perhaps the server is not correctly handling ACKs for packets recieved by the client. The server needs to correctly keep track of which packets you have recieved, otherwise it cannot correctly figure out how to extrapolate or between what to interpolate when it does lag correction; it occassionally makes an incorrect guess at what you saw. It's not just packet loss that would cause this, packets aren't guaranteed to arrive at any particular time frame or in any particular order.<!--QuoteEnd--></div><!--QuoteEEnd--> I would hope max would have paid better attention to his networking classes than this... but it's actually possible, as MOST packets will arrive on the right time and in the right order, but there will be occasional dropped packets and out of order packets, and if your system's solution doesn't handle them properly it will cause a lot of problems depending how it's handled. I've heard game state is transferred via UDP... Some things you can probably get away with in UDP (where skulks on the opposite side of the map are) I really feel hitreg should be transferred via TCP. However, I haven't read specific papers on the industry standards, I'm just expressing my feelings based on my network training.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Something could be subtly wrong with the way timestamps are implemented. It's not obvious how to design this in an optimal or even correct way. The player needs to be able to accurately tell the server when it fired. The first thought that springs to mind is that you would want to refer to some events with definite times on the server; e.g. I was interpolating between packet A and packet B(where both contain definite times, e.g. 73 and 106 ms after the last packet which the client ACKed) and x ms had passed since A. That should allow the server to _exactly_ compensate for lag in regards to reg. But that's not the way most games do it(compensate by <b>average</b> latency + interp) and there's probably some clever reason why you can't do it the naïve way I proposed.<!--QuoteEnd--></div><!--QuoteEEnd-->Because your latency determines how far behind you are from the server's game state, and how far the server is behind from your motion state. It's weird to think of it this way, but in game time is actually slightly compressing and expanding as your latency shifts. Interpolation masks this effect.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->There could be some bug in the rewinding of time. E.g. an animation bug where player positions are rewound accurately but the animation pose of players are not.<!--QuoteEnd--></div><!--QuoteEEnd-->interpolation doesn't ever actually rewind time visually, it's purely systemic calculations. Server side it doesn't render animations or models at all, it just holds data of where player models are, client side, your animations are never "current" they are always representations of a past game state, there's no rewinding necessary. You just simply see events that actually happened 200 or so ms ago as if they were in real time to you, and likewise, the things you do don't happen for another 200ms average for every other player (however, the server sees them somewhat sooner than that)
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->I think the best thing to do is to take the time to extend the system they have in place for debugging already with player hitbox snapshot data. The client has information on how the hitboxes looked on the enemy player when it fired and it has its own position and view direction. The server can, if put in debug mode, send reliable data to the client(resend until ACKed) containing the hitboxes of players as they looked on the server when the player fired. Also contained in the packet would be player view direction, location and bullets trajectories. Now you can visually draw both hitbox data and compare. There are also lots of interesting variables you might want to log(timestamps and so forth).<!--QuoteEnd--></div><!--QuoteEEnd-->I agree, but it's a fair bit of work, I think they're hoping it's a minor error and they can just hotfix it. Rather than having to comprehensively troubleshoot something that was basically copied from other game engines.
Most games have this effect when the network settings are tweaked to be as accurate as possible and work with maximum performance. The warping is a side effect network data transmission just being outright unreliable. There are systems in place to mask it, but fundamentally it's not a "problem" that the game isn't smooth, it's a side effect of problems in the internet system we all use, and game developers have absolutely zero access to fixing.
[edit]not to say there can't be errors in the way a game has implemented the smoothing systems.
True, but I'd like to rule out other possibilities, such as having a high number of predicted frames, waiting on GPU/render thread issues, etc, which only r_stats provide. The more info, the easier it will be to fix the problem.
Also, if you're feeling adventerous, you could even turn on the rest of the stats (g_stats, e_stats, p_stats, s_stats, fx_stats, fx_stats, nav_stats), though it might become too much of a mess.
Bugs are usually not implemented intentionally. There was a similar bug just a few patches ago that affected reg.
<!--quoteo(post=2041182:date=Dec 6 2012, 04:35 PM:name=Swiftspear)--><div class='quotetop'>QUOTE (Swiftspear @ Dec 6 2012, 04:35 PM) <a href="index.php?act=findpost&pid=2041182"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Because your latency determines how far behind you are from the server's game state, and how far the server is behind from your motion state.<!--QuoteEnd--></div><!--QuoteEEnd-->
You can get the time in the past your client is supposed to live in by keeping a moving average of latency, yet still refer perfectly accurately to the time you fired at a player as "interpolating between packet A and C and 17.7 ms having past since the gametime in packet A"(these packets would have to contain when they were generated on the server and there needs to be sanity checks so that players are traveling only forward in time and at a reasonable rate).
There is something more subtle preventing this. The source engine and several other engines guess at the time the player fired by subtracting average latency + interp from the time when the command packet arrived and use this time to rewind and check for hits. This is very susceptible to jitter in frame render times and network latency, so why do it this way?
<!--quoteo(post=2041182:date=Dec 6 2012, 04:35 PM:name=Swiftspear)--><div class='quotetop'>QUOTE (Swiftspear @ Dec 6 2012, 04:35 PM) <a href="index.php?act=findpost&pid=2041182"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Interpolation doesn't ever actually rewind time visually, it's purely systemic calculations.<!--QuoteEnd--></div><!--QuoteEEnd-->
That makes no difference. You cannot "just interpolate" past hitbox positions; you have to calculate properly a frame of skeletal animation, including animation blending(looking, flinching etc.), for those hitboxes. There may be infered properties that are not even stored explicitly that have to be recalculated. E.g. a skulk model's actual rotation might not be stored if it can be inferred from view angles and position.
I can't think of a game that implemented lag compensations without subtle and not so subtle bugs that took years to fix or ugly trade offs that were improved.
They actually had a problem like this, around 225 (just before release), that was already fixed.
There is a 720p HD version uploaded there.
To any UWE staff that view that, I have a larger version I can upload to FTP / send to the staff. I understand you want to go frame by frame, I also have all demos available including Javahulk's first person demo. Just need a place to send them / upload then. PM me if necessary.
I know it's a poor edited film, I didn't really have time or energy to put much into it, but it should do the trick.
Edit: The points I reference are much clearer frame by frame.
Are you practicing in modesty? You definitely put some effort into this movie. Tanks. :)
There is a 720p HD version uploaded there.
To any UWE staff that view that, I have a larger version I can upload to FTP / send to the staff. I understand you want to go frame by frame, I also have all demos available including Javahulk's first person demo. Just need a place to send them / upload then. PM me if necessary.
I know it's a poor edited film, I didn't really have time or energy to put much into it, but it should do the trick.
Edit: The points I reference are much clearer frame by frame.<!--QuoteEnd--></div><!--QuoteEEnd-->
Some of your initial claims are based on the assumption that there is bullet travel. For example, that the skulk dropped in front of your rifle in between bullets. I was under the impression that the guns are hitscan weapons (as in no bullet time)?
there is a difference between bullet travel time and time between shots.
There is a 720p HD version uploaded there.
To any UWE staff that view that, I have a larger version I can upload to FTP / send to the staff. I understand you want to go frame by frame, I also have all demos available including Javahulk's first person demo. Just need a place to send them / upload then. PM me if necessary.
I know it's a poor edited film, I didn't really have time or energy to put much into it, but it should do the trick.
Edit: The points I reference are much clearer frame by frame.<!--QuoteEnd--></div><!--QuoteEEnd-->
Nice work. Though, its refreshing to see that we aren't the only ones having trouble reproducing this issue. We know it exists and happens on a semi-regular basis, but getting it to occur in a controlled environment where we can track down the problem has proven difficult.
The other thoughts I've had to try and see if they are related are
- Test hitreg when you have low fps (but on a good server with low ping)
- Test hitreg when you have high ping (but on a good server with good fps)
- Test hitreg when your on a poor server (but with low ping and good fps)
<!--quoteo(post=2041536:date=Dec 7 2012, 08:00 AM:name=include)--><div class='quotetop'>QUOTE (include @ Dec 7 2012, 08:00 AM) <a href="index.php?act=findpost&pid=2041536"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Some of your initial claims are based on the assumption that there is bullet travel. For example, that the skulk dropped in front of your rifle in between bullets. I was under the impression that the guns are hitscan weapons (as in no bullet time)?<!--QuoteEnd--></div><!--QuoteEEnd--> See Glissy's quote below.
<!--quoteo(post=2041611:date=Dec 7 2012, 10:51 AM:name=Gliss)--><div class='quotetop'>QUOTE (Gliss @ Dec 7 2012, 10:51 AM) <a href="index.php?act=findpost&pid=2041611"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->there is a difference between bullet travel time and time between shots.<!--QuoteEnd--></div><!--QuoteEEnd-->Exactly. I don't do a single thing that is based on a bullet "traveling" but simply time between shots. In fact, I make it clear I assume "if a shot is fired, as far as I can tell, if the crosshair is on target it should be a hit". That's pretty much the lazy man's definition of hit scan.
See Glissy's quote below.
Exactly. I don't do a single thing that is based on a bullet "traveling" but simply time between shots. In fact, I make it clear I assume "if a shot is fired, as far as I can tell, if the crosshair is on target it should be a hit". That's pretty much the lazy man's definition of hit scan.<!--QuoteEnd--></div><!--QuoteEEnd-->
Okay good. I just wanted to make sure. :) A few people think the game is projectile based. As you are attempting to do in your videos, I'm just trying to help ensure that something isn't based off of inaccurate information and to reduce false positives.
For the record, I do agree with you on this. It's wisest to have hitreg issues as something covered under the blanket of debugging. Especially when you're not just giving the players and servers the variable points to play with.
the only really dumb thing is that they tried to make it 'scroll' the damage up over time instead of making it instant-update. kind of how they used to do the health bars when you got hit.
it was a bad idea then, and it's still a bad idea. i'm not shocked at all that they didn't learn from their mistakes.
it was a bad idea then, and it's still a bad idea. i'm not shocked at all that they didn't learn from their mistakes.<!--QuoteEnd--></div><!--QuoteEEnd-->
I really disagree with this. The scroll allows the numbers to be accurate server side. If they did instant pop up numbers it would have to be client side.
In the demo1 file I'm pinging ~20ms to a local NZ server so connectivity should not be an issue.
This demo contains both LMG and shotgun versus skulks.
<u>Specs:</u>
Core i7 3770k 3.5 GHz (no OC)
Radeon HD 7870 OC
16 GB RAM
SSD
Win8 x64
<u>SUT:</u>
Build 232
<u>File:</u>
demo1 76.32MB
<u>Download:</u>
<a href="http://www.mediafire.com/?mg8am7akiwa3a2y" target="_blank">http://www.mediafire.com/?mg8am7akiwa3a2y</a>
That's not true. There's a delay anyway. There is almost a whole second delay with how NS2 interpolation works.
The delay is because it's server side. It would be VERY disorienting to have damage numbers pop up a half second later if they didn't scroll. You'd have no idea what was hitting and when. The current system isn't amazing for hit feedback, but it gives you a really good sense of how much damage you're registering, and therefore how efficient your attacks are.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->I really feel hitreg should be transferred via TCP.<!--QuoteEnd--></div><!--QuoteEEnd-->
This is a terrible idea, it'll essentially double your response time because you have to wait for acks.