https://cdn.discordapp.com/attachments/725458744711839873/ 976919100125229156/MovementAnimationBug_src.zip
If your client performance is bad, your movement state will continue playing after you already stopped moving.
ID:2791418
 May 19 2022, 11:49 am
|
|||||||||||||
Resolved
| |||||||||||||
|
May 19 2022, 2:52 pm
|
|
Lummox JR
   |
Gonna need more information on this. At present it doesn't sound like a bug at all, just a problem that you'd expect to occur when performance takes a hit.
|
It's not that the client is frozen the whole time, which I'd expect to cause the movement state to be stuck (or like, not even animating). The client can still be rendering at >30fps the whole time, and player motion responsively stops as soon as input stops, but the movement icon_state remains playing for several seconds (many client frames) afterwards.
| |
https://imgur.com/6CKpEBC
To show how responsive the client is actually being, I added some maptext that updates according to buttons pressed. The red circle is the M-state in the icon, and white is non-M. It just seems odd to me how long it stays red after it shows that there's no buttons pressed. | |
Okay, I see the problem and will work on a fix.
The movement state countdown is a single byte and is still based on actual client ticks, whereas the gliding system has otherwise moved to using actual elapsed time. | |
Lummox JR resolved issue with message:
The decision to turn off a movement state when done gliding/stepping was based on the old tick-based method of calculating glides, and could result in a movement state staying on long after the movement ended if the client ticks bogged down. | |