Aq'sa
L.O.T.I.S.
Legacy Rising
44
   |
Posted - 2012.10.08 18:23:00 -
[1] - Quote
Isn't Dust using more server side calculations for this stuff- i.e. hit detection- that make lag switches and client side lag (Downloads, bad wifi, crappy modem, etc) only relevant for the client affected, not others? |
Aq'sa
L.O.T.I.S.
Legacy Rising
44
|
Posted - 2012.10.09 20:40:00 -
[2] - Quote
Nova Knife wrote:Xiree wrote:
I am not sure what you meant by, "HURRDURR I SHOT PLAYER X" . Could you explain what that means? Please, much appreciated...
In your example in above posts, you said it was possible to manipulate or 'ignore' packets and thus never take damage. I'm telling you it doesn't work like that. Hit detection and damage values are all server side. Even if you were able to isolate packets associated to damage, conflict would remain with the server and you'd just die without realizing you took damage because you dropped packets. It'd pretty much be as if you died to lag without actually lagging. Something like you're suggesting might be possible in games where hit detection/damage is calculated client side and not server side (Like battlefield 3 and such) but when the server itself handles this, it's not possible.
^^^
This is what I was saying, ignoring packets, not sending packets, manipulating packets, at your client side shouldn't affect Dust due to CCP handling those calculations server side. The vector locations, damage packets, etc- you could ignore, or spoof, but the server would have the 'reality' of location and damage still playing out.
You are at (x-range; y-angle) on server- you get shot by player sending and receiving packets as normal. If you ignore packets- you die, your ignoring of packets means you possibly can't tell, but still die. You spoof packets- server checks against its existing info- corrects you.
This is why I made a post asking for Eve-Style handling of lag in Dust. In Eve, lag and 'lost' commands (clicks or keystrokes) was evident for ages in large fleet fights due to a exponentially expanding queue of requests hitting the server when overloaded. This means you click fire, nothing happens because your fire command was in line behind 4000 other boost, fire, turn, follow, etc commands. You would seemingly die, frozen, before your ship would respond to any directions. The server overload caused queue backup and the backlog accrued amplifies overload, spiraling down till a server node would crash- kaput.
CCP intuitively addressed this by universally slowing down 'time' in game during periods of node overload, essentially allowing the server to catch up with the lag by slowing the time physics for the whole star system, for all players in it, based on load and command queue size. This means you would run at 75% or 50% typical game speed, but no one would experience the lag spikes or 3 FPS gameplay.
See Thread:
https://forums.dust514.com/default.aspx?g=posts&m=341222#post341222 |