Scout Archive

Guys,

Being a politician, and not a programmer, I can barely understand your semi-geek speak .

However, you're both on the same team here- you're both Scouts, and you are both working to get the same issue resolved.

Whether its a bug, or latency, it's something that the Devs need to address - to either confirm or deny and to let us know what they can do to fix it.

So put your cyber rulers away and quit the measuring!

B

My guess on this matter is that the client sends minimal data to the server and both calculate the current position seperately. The client calculates the position repeatedly, giving nice smooth movement. The server is only sent movement type (walk, run, prone, burst run, maybe include other states such as kneel to get up to a full byte and parse using a case statement), a direction (possibly in 1.5 degree increments or so, giving around one byte of information) and some sort of time value (we could assume constant time intervals, which could easily be the problem--see below). The server is only given this information every so often. What me might get is the following:

I am assuming constant time intervals between movement packets (to save bandwidth and computation) and that the client calculates its own position and updates when the server tells it to. Player is running along. Goes prone halfway through a movement segment. Movement packet sent saying the player is prone. Because we have constant time intervals, the running and prone movement times are notseperate. Server checks the position and tells the client that the player should really be some number of meters back in the direction they were running from. One might say there is an easy solution to this but the main problem is computation time. If a non-constant time interval is used, there would be extra computationand bandwidth(and determining when to send the packets would be an annoyance). If you shrink the time intervals, you again get higher computational costs and much higher bandwidth. When you factor in that every player needs to send this information quite often, you can see how quickly any small increase in cost will scale. Admittedly, this all ignores terrain negotiation (which would require a check for terrain steepness [probably a matrix lookup on position] and a skill check). I know this isn't entirely clear but I hope what I am trying to say comes across. My main point is that it is easy to think up a possible cause for this problem (that could be extended to other warping issues with a little thought) that does not allow for an easy solution. It is very likely that something as minor as this could be the problem but finding a solution that doesn't introduce more severe problems (like server overload) is difficult. Not knowing if what I am saying is at all true, I won't put extra wear into my keyboard proposing a full solution. I just want to point out that the problem may lie in how to fix things rather than what the cause is. It would be nice to know what the devs think about this (i.e. do they know the cause and just can't find a good solution or are they still looking for a cause) but it is unlikely that we will be told. Assuming they do not know the cause, then giving examples can only help them. Otherwise, we are only wasting our breath. My guess is that they do know what the problem is but don't want to post it (imagine the outcry of "I'm paying $15 a month and they can't even use powerful enough computers!"). I'm sure a solution will be found soon enough but just remember how much data is actually processed by this game. A small problem with occasionally warping when lying down is much better than always having to deal with large amounts of "lag" (used in the sense of delay from when you tell the server what you want to do and when it tells you if it worked).

Lythender Nirou
Eclipse Server

This is for sure for all players, it effected me as using rifle, but I have had it with going prone with pistal, and dropped all my rifle. My belief is that it is a form of Lag. I say this because if you notice, it warps you back the direction you were runing from. It is not always away from a creature. It's always straight back in the line of travel you had.

The fact that if you stop and wait for a few seconds, then go prone, leads me to beleieve its a lag issue. If I stop and wait, I can tell when its safe for me to go prone. My screen kind of "jumps/flashes" then I know I can go prone. It's almost like the server caught up with me and where I ran to. Now this might be the reason why scouts and ranger experience it more. Because we travel faster on hills and thus there is more of a delay in the server cathing up.

The Devs have already said there is a 5m range of accuracy of a characters possision. Well if that's so then think about that 5m, the time it takes to travel that, and if we are running fast. In my belief they are all related.

On a similar note that I saw someone post on this thread. The bug of using /takecover and not being able to run is fixed. I was using a lot a few weeks ago and had no problem with it.

From last Thursday's hotfix notes:

Rubberbanding: Fixed a bug that could trigger movement validation errors on movement when a player was slowing down in some circumstances.

I stress-tested this all day on Sunday. I would run full tilt and hit my Prone and Conceal Shot (or Headshot 3) hotkeys in quick succession.

Didn't warp a single time. This marks a profound improvement over the previous 2-3 weeks.