Closed DenL closed 2 years ago
Bluefissure
commented
2 years ago I have taken 50ms, which is a constant server processing time, from the elapsed time.
For detailed discussion and explanation, you can read https://github.com/Bluefissure/DoubleWeaver/issues/4#issuecomment-949052228 .
DenL
commented
2 years ago Copying the relevant parts here for discussion
Moreover, the detection of in-game actions didn't consider the server processing time, which means it assumes
there's no server latency the server can process the action request instantly. And the second one may be the reason why it overcompensates when the PingPlugin is not accurate.
I'm thinking of adding a constant server processing time to the elapsed time detection (~100ms, which is ~50ms converted to the server latency). Hope this will fix the problem.
I would like to raise a point that server processing time should be considered part of the (valid) delay/ping. If the idea is to have the final animation lock not be more than 600ms, by not counting the the 100ms processing time this 600ms threshold just became 700ms.
e.g. in my above logs, the server response took ~100ms to come back, but due to DoubleWeaver "considering" the server processing time, the animation lock is barely decreased(as if I have no ping), resulting in an almost 700ms lock. That's an extra 200ms when you are double weaving and it can be felt.
Bluefissure
commented
2 years ago Copying the relevant parts here for discussion
Moreover, the detection of in-game actions didn't consider the server processing time, which means it assumes there's no server latency the server can process the action request instantly. And the second one may be the reason why it overcompensates when the PingPlugin is not accurate. I'm thinking of adding a constant server processing time to the elapsed time detection (~100ms, which is ~50ms converted to the server latency). Hope this will fix the problem.
I would like to raise a point that server processing time should be considered part of the (valid) delay/ping. If the idea is to have the final animation lock not be more than 600ms, by not counting the the 100ms processing time this 600ms threshold just became 700ms.
e.g. in my above logs, the server response took ~100ms to come back, but due to DoubleWeaver "considering" the server processing time, the animation lock is barely decreased(as if I have no ping), resulting in an almost 700ms lock. That's an extra 200ms when you are double weaving and it can be felt.
Yes, I know what you mean, and thanks for pointing it out.
The key problem is that this plugin is not for making advantages when you double weave in low latency, which means the idea is not to have the final animation lock not be more than 600ms, but to make those with high latency able to double weave as easy as in low latency.
Therefore, the barely decreased animation lock is exactly what to be expected for low latency users, as it won't overcompensate, or even, to be said by some people, cheat in the game.
I'm okay if you want to build the plugin without considering the server processing time, it should be easy as only commenting out this line, but I'm afraid I'll keep it in my repository.
Hope this can explain the purpose of the plugin and my attitude, and thanks for understanding.
Animation lock has felt longer since the 6.0 update with DoubleWeaver. I decided to enable and check logging and looks like animation lock is barely decreased:
Not sure what's going on, it seems the Elapsed time is not accurate?