Character is pulled back to starting cell after trying to walk right after using a skill

[Moskaum Y]

Character is pulled back to starting cell (henceforth, "rebound") after trying to walk right after using a skill. This happens more often when the aspd is higher. Here is a video:

In this video the walk delay is 150.

Spoiler

 

I'm using 2018-06-20cRagexe.

Caution: do not try to replicate this with magic rod.

 

My intent is to NOT HAVE any circumstance of rebound, like in this two following videos, that were filming in a eAthena server.

Spoiler

 

I'm aware that offical server have this rebound. But in an official server, the more aspd you have, the less rebound you get.
 

Spoiler

 

On my rAthena server, is the opposite: the more aspd you have, the more rebound you get.

Nevertheless, you would like to have zero rebound.

How can I do this? Anyone has any ideia?

[Fatal Hatred]

Adding Further Information:

Editing walkdelay (via source code modifications or choosing walkdelay options on WARP for the hexed client) DOES NOT fix this issue in the right way. What low levels of walkdelay seem to do is allow walking despite ASPD values. This gives the illusion that the problem is "fixed" because your character is allowed to move right away to the next cell, way faster than it normally should for that ASPD value.

However, this is not a proper solution.

The official behavior seems to be related to your character's sprite (so maybe client side?) being allowed to occupy a position in between two cells instead of being pulled back to the center of the starting cell whenever it tries to cast a skill and then move immediately afterward.

To put it in another way: rAthena appears to update your position to the center of the cell whenever you try to cast a skill -> walk -> cast a skill again. This behavior results in the "rebound" effect where the character is pulled back to the center of the starting cell after attempting to move right after using a skill, especially at higher ASPD values.

Once, I was told that in the official client, characters can inhabit any part of a cell (as if the cell is divided into 1000 parts), allowing for smoother transitions and the ability to cut animation delays more naturally. It seems like in rAthena, the character's sprite is more restricted and seems to snap back to the center of the cell, causing the observed rebound effect. This does not seem to occur on eAthena servers.

By the way, this is very detrimental to the gameplay as a whole, so it's a little weird that I cannot find any information about this issue anywhere.

Is there a way to modify the client or the emulator to allow the sprite to remain between cells and avoid this rebounding behavior? Any suggestions or insights would be greatly appreciated!

Edited July 8, 2024 by Fatal Hatred

[Tokei]

On 7/8/2024 at 3:34 AM, Fatal Hatred said:

Adding Further Information:

Editing walkdelay (via source code modifications or choosing walkdelay options on WARP for the hexed client) DOES NOT fix this issue in the right way. What low levels of walkdelay seem to do is allow walking despite ASPD values. This gives the illusion that the problem is "fixed" because your character is allowed to move right away to the next cell, way faster than it normally should for that ASPD value.

However, this is not a proper solution.

The official behavior seems to be related to your character's sprite (so maybe client side?) being allowed to occupy a position in between two cells instead of being pulled back to the center of the starting cell whenever it tries to cast a skill and then move immediately afterward.

To put it in another way: rAthena appears to update your position to the center of the cell whenever you try to cast a skill -> walk -> cast a skill again. This behavior results in the "rebound" effect where the character is pulled back to the center of the starting cell after attempting to move right after using a skill, especially at higher ASPD values.

Once, I was told that in the official client, characters can inhabit any part of a cell (as if the cell is divided into 1000 parts), allowing for smoother transitions and the ability to cut animation delays more naturally. It seems like in rAthena, the character's sprite is more restricted and seems to snap back to the center of the cell, causing the observed rebound effect. This does not seem to occur on eAthena servers.

By the way, this is very detrimental to the gameplay as a whole, so it's a little weird that I cannot find any information about this issue anywhere.

Is there a way to modify the client or the emulator to allow the sprite to remain between cells and avoid this rebounding behavior? Any suggestions or insights would be greatly appreciated!

This is related to an attempted fix for position lag, and therefore it is intended. It comes from the "clif_fixpos" packet which is triggered after the player uses a skill, as you've noticed. It synchronizes the client position with the server position. You will only see the character moving back if the client and server positions are different (so... it's a good thing?).

The above won't help you too much though, sorry! There's a bigger issue at play here, which is to fix the difference between the client and server position instead of relying on the clif_fixpos packet. Even if you stop sending the clif_posfix packet so that the character doesn't change position, the position between the server and client still won't be a match. So fixing the "walking back" issue will just end up moving the problem elsewhere.

If you still want to have a feel for it, you can change the line below with a 0, that way your character will no longer walk back.

unit_stop_walking(src, 1); // Even though this is not how official works but this will do the trick. bugreport:6829

to

unit_stop_walking(src, 0); // Even though this is not how official works but this will do the trick. bugreport:6829

But I don't recommend it.

[Moskaum Y]

20 hours ago, Tokei said:

This is related to an attempted fix for position lag, and therefore it is intended. It comes from the "clif_fixpos" packet which is triggered after the player uses a skill, as you've noticed. It synchronizes the client position with the server position. You will only see the character moving back if the client and server positions are different (so... it's a good thing?).

The above won't help you too much though, sorry! There's a bigger issue at play here, which is to fix the difference between the client and server position instead of relying on the clif_fixpos packet. Even if you stop sending the clif_posfix packet so that the character doesn't change position, the position between the server and client still won't be a match. So fixing the "walking back" issue will just end up moving the problem elsewhere.

If you still want to have a feel for it, you can change the line below with a 0, that way your character will no longer walk back.

unit_stop_walking(src, 1); // Even though this is not how official works but this will do the trick. bugreport:6829

to

unit_stop_walking(src, 0); // Even though this is not how official works but this will do the trick. bugreport:6829

But I don't recommend it.

Thank you.

[Fatal Hatred]

On 7/9/2024 at 1:19 PM, Tokei said:

This is related to an attempted fix for position lag, and therefore it is intended. It comes from the "clif_fixpos" packet which is triggered after the player uses a skill, as you've noticed. It synchronizes the client position with the server position. You will only see the character moving back if the client and server positions are different (so... it's a good thing?).

The above won't help you too much though, sorry! There's a bigger issue at play here, which is to fix the difference between the client and server position instead of relying on the clif_fixpos packet. Even if you stop sending the clif_posfix packet so that the character doesn't change position, the position between the server and client still won't be a match. So fixing the "walking back" issue will just end up moving the problem elsewhere.

If you still want to have a feel for it, you can change the line below with a 0, that way your character will no longer walk back.

unit_stop_walking(src, 1); // Even though this is not how official works but this will do the trick. bugreport:6829

to

unit_stop_walking(src, 0); // Even though this is not how official works but this will do the trick. bugreport:6829

But I don't recommend it.

Thank you very much!
Can you talk more about this "attempt to fix position lag"?
So, now players can break animations by walking and chain skills more fluidly (as it is on official servers and always was). This is what should happen, instead of punishing high APM players when they are trying to chain skills properly. This feature is really influential in competitive PvP scenarios, and that "fix attempt" was highly detrimental for high-skilled players.
But, indeed, you're right that there is clearly a bigger issue here - since editing that line DID FIX the problem, but introduced types of "forced bug position" that never existed on official servers (e.g., casting Arrow Shower with no arrows equipped while walking).
The interesting thing for me is that while kRO, at some point, did fix this position desync (so it's no longer possible to "force bug position" in the majority of cases on official servers), they did it possibly in another way, without messing up the possibility to break skill animations by walking (which is still possible today).

And again, thank you for your help!