EPICTHEFAIL, on 29 November 2012 - 10:59 AM, said:
It`s not that bad, especially considering how horrific lag can be in some other games *cough TF2 cough*. A lagshielded Jenner is nothing compared to being decapitated by a sniper through 2 meters of solid concrete because his computer
tldr: Read up on the source engine netcode details, thats actually the proper way and its very legit, despite what you think you saw.
So, somewhere around 1998-1999, valve implemented lag compensation in their goldsrc engine, and it was subsequently used in their source engine. This has been the standard for FPS netcode ever since IMO (hence the netcode from the 90s comments throughout the forum), as it gives a competitive playing field between players for different pings. Ping still provides an slight advantage, but there really is no way around that unless you start inducing lag for low ping players.
The server keeps a small record of player positions, and when a client makes a shot, it uses that to validate the shot, effectively going back in time to make sure its legit for the player that shot. This isn't true client-side hit detection, but rather a mix of CSHD for prediction and server verification for the actual hit/damage. Note that this process works well for pings up to 300 or so, since a significant portion of gamers were still using dial-up at the time.
This is what you are seeing. Sure, on your machine, you had moved back behind a wall, but for the guy who shot you, you were still standing out on the deck. His shot should not be invalidated because he didn't get that information for .2 seconds (assuming a 100ms ping for both) -- he saw you on his screen, he aimed
at you instead of where you were going to be, and he got a hit. The client sent the shot to the server, the server said 'hey, yeah this is exactly where this player was 0.123 seconds ago, right when the client said he hit, looks legit,' then sends the message to your client. Your client says 'hey, this guy shot me a while ago, I just found out about it, better show the player hes dead'. To you, at this point, you were not hittable, but its just because of the latency between you actually dying and finding out you died. Both your latency and his latency can affect the extent of this discrepancy, but there is a server-configurable amount of how much it will simulate, so you can't abuse it with an exceptionally high ping.
This provides a game experience where you actually aim at and hit your opponents, simulating a LAN or real-time environment. The simulation exposes itself when you do something on your client that contradicts what happened on the server a fraction of a second ago. But you know that the server actually verified the hit, as opposed to pure CSHD where the enemy client could easily send a message saying he hit you despite you actually being behind a wall.
Honestly, all the people I've seen that complain about lag compensation are the people that don't understand it. Valve's implementation isn't perfect (interpolation and hitbox issues, detailed with CS), but it is the best and most fair that I've ever seen.
Comparatively, the current MWO netcode baffles me. It's not even as consistent as no prediction/lag compensation, because at least then you aimed a set distance where you thought the player would be when your weapon fire got to the server. It seems to change every time how far I have to aim ahead of a player due to factors I cannot divine, along with other issues preventing hits from registering even with stationary mechs. Sometimes it seems like the server doesn't even tell you the correct position of the enemies, so theres no way to even predict where they will be.
I do wish I knew the technical details of MWO's setup, both in network code and server implementation so I could get a better idea of whats really going on, but kinda a moot point with the rewrite..
0
.
