Remove RNG from movement speed

[jordancoles]

the difference in speed isn't so large that it would matter; it amounts to a few percent of difference, which perhaps in some scenarios might matter more than I thought. Indeed on short movement you would get greater variance, but that seems like a bit of a pathological case to me, and I wonder if that actually matters.

A few percent difference when swimming is literally an additional credo buff :thonk:

[loftar]

A few percent difference when swimming is literally an additional credo buff :thonk:

Well, the credo buffs are at least more than 2-3%. But, well, to be fair I hadn't really calculated it until this thread came up, I just assumed it to be negligible.

[boshaw]

I believe what you're looking at is the fact that time steps on the server are quantized, and movement must complete in a discrete number of timesteps. Given that constraint, there are basically two reasonable options to choose from:

• Divide the whole movement evenly among the timesteps it will take; or
• Use an exact movement delta for each step except the last one, which gets whatever remains of the requested movement.

I've chosen the first option, simply because that allows the client-side interpolation to more precisely model what actually happens server-side. I assumed that, for reasonably long movement requests, the difference in speed isn't so large that it would matter; it amounts to a few percent of difference, which perhaps in some scenarios might matter more than I thought. Indeed on short movement you would get greater variance, but that seems like a bit of a pathological case to me, and I wonder if that actually matters.

The behavior is not so firmly entrenched that I couldn't change to the second mode, but I do wonder if that couldn't yield undesirable unevenness in the interpolation or other unforeseen behavior. That might be less of a problem in these days of the new interpolation protocol format, but I'd have to try to find out.

Thanks for the explanation as that really spells it out now and makes sense as to what is being seen. Knowing the server timestep and the units/s for each speed I can definitely see in testing now how to maximize speeds based off how many timesteps they will end up, and like you said it is much more apparent the closer it is like you mentioned. The variance is also much more noticeable as you get to higher speeds which makes sense.

My one thought right now is with shift+click example where the server runs you in a direction forever, which is nice but usually a slower speed or more so matching the real speed intended, could be overridden by a custom client to instead do it themselves with somewhat perfectly placed clicks in the direction desired but at shorter distances that maximize speed to give them basically a superior shift+click speed-wise to be better than or at least as good s the default. In chases this would be quite an advantage if consistently done over long periods of time, could even save yourself from a KO or catch up and KO the guy you're chasing.

If you do decide to try the alternative method perhaps it can be done on the test server for people to run around in and see if it works better and without mistakes?

[rye130]

I was able to easily catch someone in a gank and easily escape from a 3v1 with just those few percent differences!

[Oddity]

I believe what you're looking at is the fact that time steps on the server are quantized, and movement must complete in a discrete number of timesteps. Given that constraint, there are basically two reasonable options to choose from:

• Divide the whole movement evenly among the timesteps it will take; or
• Use an exact movement delta for each step except the last one, which gets whatever remains of the requested movement.

did legacy use the 2nd option?

[Fille]

Lowkey, we all knew about this way before, in old haven, didn't we?
I remember he who clicked longest, ran fastest.

[shubla]

Use an exact movement delta for each step except the last one, which gets whatever remains of the requested movement.

Just send the data to client that it needs for the last step too.

[MagicManICT]

Lowkey, we all knew about this way before, in old haven, didn't we?
I remember he who clicked longest, ran fastest.

That was the opposite. The more frequently you clicked, the more likely you were to rubberband to an old position, and you couldn't shift-click to just run in one direction nearly infinitely. Those able to navigate with the fewest clicks were usually the ones most likely to win.

[Ysh]

I believe what you're looking at is the fact that time steps on the server are quantized, and movement must complete in a discrete number of timesteps. Given that constraint, there are basically two reasonable options to choose from:

• Divide the whole movement evenly among the timesteps it will take; or
• Use an exact movement delta for each step except the last one, which gets whatever remains of the requested movement.

I've chosen the first option, simply because that allows the client-side interpolation to more precisely model what actually happens server-side. I assumed that, for reasonably long movement requests, the difference in speed isn't so large that it would matter; it amounts to a few percent of difference, which perhaps in some scenarios might matter more than I thought. Indeed on short movement you would get greater variance, but that seems like a bit of a pathological case to me, and I wonder if that actually matters.

The behavior is not so firmly entrenched that I couldn't change to the second mode, but I do wonder if that couldn't yield undesirable unevenness in the interpolation or other unforeseen behavior. That might be less of a problem in these days of the new interpolation protocol format, but I'd have to try to find out.

As for OP's question, I'd argue the common strategy is to pace oneself properly before only having two steps left. As for looking silly for taking unnatural steps, that only happens if you've paced yourself wrong to begin with, in case it is only natural to look a bit silly. So there's that.

So you will split difference between all steps? Then you are maybe never taking 100% steps. What if this destination goal is many miles away? How to know length of step to arrive if I can not see this end?

It seem loftar's strategy of steps is consistent between game and real live. And here is very good example of possible issue arise from never take 100% steps!

[cobbleminer]

Please consider removing the RNG from movement speed. It's especially apparent with Rowboats and higher speed actions from speed 3 and up. It's kind of silly that someone will outrun or gain on you simply because they got lucky from the server.

+1