To improve the responsiveness of weapons...
Skie
Skulk Progenitor Join Date: 2003-10-18 Member: 21766Members, NS2 Playtester, Reinforced - Shadow
Skulk Progenitor Join Date: 2003-10-18 Member: 21766Members, NS2 Playtester, Reinforced - Shadow
I did a small study on the responsiveness of weapons as to when the target actually takes damage. Or appears to take damage.
In this situation, I shot a cheats-spawned lerk close up with the rifle on a listen server (low ping).
The picture speaks for itself, it takes quite a long time for there to be any response, and even for the client-side hit calculation it takes 150ms. I've modded the hit tick to be instant.
<img src="http://i.imgur.com/SHOYB.jpg" border="0" class="linked-image" />
In another similar situation (which I don't have a picture of), I shot a CC with a shotgun with cheats on, and it took 175ms for its health to drop from 85% to 83%, the starting point being the first frame of the shotgun's muzzle flash.
I feel like this is a really 'big deal' and should be looked into when the devs have time. Or is it just because of the server's low tickrate which causes it so long to update?
In this situation, I shot a cheats-spawned lerk close up with the rifle on a listen server (low ping).
The picture speaks for itself, it takes quite a long time for there to be any response, and even for the client-side hit calculation it takes 150ms. I've modded the hit tick to be instant.
<img src="http://i.imgur.com/SHOYB.jpg" border="0" class="linked-image" />
In another similar situation (which I don't have a picture of), I shot a CC with a shotgun with cheats on, and it took 175ms for its health to drop from 85% to 83%, the starting point being the first frame of the shotgun's muzzle flash.
I feel like this is a really 'big deal' and should be looked into when the devs have time. Or is it just because of the server's low tickrate which causes it so long to update?
Comments
Seriously, you've been reporting a lot of issues most people seem to notice to some degree ("it feels strange sometimes") and tested all of them <b>very</b> thoroughly with all steps to reproduce and everything you could find about both the issue and the cause.
On topic: The game might have some built-in lag to make games more fair, but I don't know. A tickrate of 30 should induce a maximum of 33ms of additional lag, although I don't know about client updaterate, which might also come into play.
Where's the line for acceptable delay for you? What if it took 600ms for it to update to clients? Or 3 seconds? "Sure, it's acceptable if it takes 3 seconds for both players!" It shouldn't take 150ms.
I was going to launch Quake3 to do the same thing for comparison with a bot, to see how NS2 measures up, but then I realized I had deleted it. :(
Dghelneshi, I just want NS2 to be a great game. But sometimes I come on a bit strong with my opinions. :)
When in doubt, empty the magazine.
Against a lerk, 162 ms for the hit tick to appear, 230 ms for it to flinch.
So very similar results.
You can charge in kill 1 player and run out and be halfway down the next hallway and die to a random shot from .4 seconds before
Ty Yuuki it was matso then.
<center><object width="450" height="356"><param name="movie" value="http://www.youtube.com/v/mjbCil1lF1w"></param><embed src="http://www.youtube.com/v/mjbCil1lF1w" type="application/x-shockwave-flash" width="450" height="356"></embed></object></center>
Also matso tried to explain this in another thread, I'm still a bit confused, but it seems that the server add 100ms of lag or something...
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->A fully functioning server sends you a new snapshot 20 times per second. The server adds a 100ms buffer to your input, and then lag is added on top of that. Assuming 100ms ping, the snapshots from the server will be about 200ms out of date, and you will get them at 50ms intervals, so that means that you will have rougly 200-250ms worth of input queue to predict each frame.<!--QuoteEnd--></div><!--QuoteEEnd-->
So if you cause something to happen on the server, there will be a lag before you see it on the client.
Try typing net_lag 500 in the console, then try the following:
- riflebut a wall while strafing - look at where and when the hit effect occurs
- pistol shot a wall (second ricochet)
- hurt something (late flinching)
- fire a grenade while strafing
- gorge spit
Increase the lag basically moves you further into the future compared to the server, meaning that anything you cause to happen on the server will show up late on your client.
For an extra bonus, have someone else do it while you look at it and compare notes.
Some things are avoidable - your client should not show server-generated hit effects from your weapon, as they are already client-side predicted (will probably get fixed when the effects system is overhauled).
However, the flinching effect (and the effect on health/armor) that your damage causes reflects a state change in an entity you don't "own". It would be a nightmare to predict on the client, and for normal lag-ranges and most effects, the lateness is acceptable (200 ms lateness in seeing a skulk die is 3-4 extra rifle bullets).
Projectiles are tricky - if they are to appear ok to everyone else BUT the shooter, then the projectile will be created late to the shooter, and it will be a bloody pain to use projectiles for a lagged attacker (the current situation). It is possible to let the shooter have priority when it comes to projectiles, but then the projectiles will appear "out of thin air" a certain distance away from the shooter to everyone else.
The fix to all this is of course to increase the speed of light.
30 ms until hit tick registration, another 10 ms and the target is dead.
<img src="http://i.imgur.com/jiIPY.jpg" border="0" class="linked-image" />
I'm not doing this to give NS2 bad rep, but have to face the fact that if we want NS2 to cater for the competetive players, it needs to be sub 100ms. Currently it's 250ms. :)
40ms feels really "instant" and that's why I find Quake Live very, very fun to play. It's so responsive.
Finaly a explanation why it feels so weird to shoot aliens/marines.
but the alien bleed at the first frame?
If you need a tester, i would help you.
We could use fraps, it has 30 seconds free recording and this would be enough i guess.
For example on Quake you can play with a 300ms+ ping and still get hit registration, in fact you can run at over 500ms and still compete, Why? because all the prediction and bullet code is done on each machine, there is no server control over firing. Quake doesn't have a true Server/client relationship it has more a of peer-peer relationship.
This relationship creates 2 situation, very fast and quick hit reg/detection, regardless of ping, and the most important one, makes it very easy to cheat :) Yes, quake is a great game on hit prediction, but it is so easy to cheat and impossible to get caught, because there is no server correcting firing rates etc. Sure, you get great registration, but you only get such a high speed game by foregoing any chance of preventing cheaters in the game.
Seeing as there are already people cheating in NS2, even with the server/client principle, I would much rather have poorer hit reg, and less cheaters, than great hit-reg and a game where all the top players cheat as it is the only way to get to the top.
--Edit---
For a fair comparison, why don't you test CS:S, this is more likely to yield a comparable result/target to aim for. Getting Quake like performance is totally unrealistic.
Never really liked CS myself, I was more of a Quake guy.
But yeah, it's probably very hard (or impossible) to get to Quake-like performance with .lua. All the hitreg code probably would have to be moved to to the C++ side. If I understand anything, that is. :)
Price: Thanks for the offer, but the alien bleeding on the first frame is intentional to make it <i>seem</i> responsive. I've been using registered version of Fraps myself.
The Lua/C++ debate isn't even part of this issue. Quake works out all the code on the clients, and passes it around to each other, with a little bit of co-ordination on the server. In CS:S/NS2 the clients update some information to the server, then the server calculates everything. This causes multiple issues, and basically means that in a battle, the feeling of responsiveness in the game is often affected by the slowest updating player in that battle.
Client prediction was invented to try and 2nd guess what was happening, and that is why you see blood on contact etc, even though no hit is actually registered on the server. This method, while creating a seemingly constant instant world, iis actually behind the real world.
The quake system is much closer to real world reactions, but there is next to no security and protection against cheaters.
It is purely a trade off decision that has to be made in the development process - Fairness and slower responses with client/server or anything goes hacks and very accurate responses in a peer-peer system.
Most of the time, it works, but sometimes ... it doesn't. It seems to stop working mostly when you have high-speed, variable movement (like, high speed skulks corkscrewing through the air).
There is a "hitreg" command that's available. You don't need cheats to turn it on - it will show the shot and the position and animation details of the probable target. For every shot. Not a very good idea to turn on in actual combat - your screen will quickly fill with lines and frozen models - but for testing, it works pretty well.
Unfortunately, I don't know if the discrepancies shown is due to bugs in the tool or in the code ... but at least there are discrepancies to explain.
I also played Action Quake2 on the Finnish national team, I think that game still handled regging a bit differently. There was more delay before the bullets left the weapons, depending on your ping. ie. no prediction at all. Everything done on server.
In my mind the whole failure of Client/Server systems is the fact the client has to predict what every human player involved in the battle is going to do. As it is impossible to do that, 'prediction' is just really saying, this player is going to keep on doing this. Of course, players don't carry on doing whatever they did, and this is when the issues start coming in.
This includes shooting someone, you may shoot them before they shoot you because prediction says they are going to carry on doing what they are doing, not firing, then you die, because they actually fired before you did. Or you get around the corner, and you die, because you were actually shot while still turning, not after you were around the corner.
Prediction is a mis-nomer :)
The problem is the only way to go for a high speed, accurate fighting system is peer-peer. Unfortunately, there is no way of making a peer-peer system cheat free. Games using server/client rely on high bandwitdh and good connections for all the players to have an accurate game, currently not possible with the worlds internet connections. Games using peer-peer can run very accurately with massive pings, because communication is done direct with the person you are shooting, rather than a 3rd party intermediary (server).
When every gamer has access to 1gb internet, current client/server games should run as well as peer-peer to games. Unfortunately that far in the future network traffic will be much higher in those modern games, thus negating the benefit, but NS2 and CS:S will play really well. Servers should be able to handle NS2 by then as well :)