Delay on walking after using self skill

[kyeme]

Describe the bug
After Casting (self skill with casting time), you will not be able to walk immediately

To Reproduce
This happens when you cast a skill (self skill with casting time only) is not done yet and you FORCE yourself to walk and the bug will appear: the result after casting you will not be able to walk immediately (need spam left click mouse or where to walk)

• Use 70 dex (pre-renewal mode) to reproduce the bug easily

Expected behavior
In official you can walk immediately

Video
https://youtu.be/Yv4xXiS0N8I

• Mode: pre-renewal
• Packet version: 2016-02-03aRagexeRE
• Client type: RE

[MrKeiKun]

Can anybody replicate this issue? I noticed within the video, the client is injected already with Gepard Shield and most likely Hercules Emu there already has the codes as well. Those factors can affect somehow, maybe a clean client and Herc is better to test.

[kyeme]

With Gepard or without Gepard the issue still exists.

[skyleo]

I think this is in relation to a decision to combat position lag, while it's possibly true that on official servers the server software doesn't ensure this delay and thus doesn't apply any. It's also true that this delay does exist on the client-side. Resulting in "position lag" / desync. If the intent was to introduce a delay, and it's only enforced on client-side giving players the illusion that you "should" be able to move, then probably for the best to have one on the server-side.

I'm purely talking from memory here though.

[Playtester]

Officially, there is no walk delay at all. Such a concept doesn't even exist. There is only a status change called EFST_NOACTION which prevents actions and moving, but is only granted by a few skills (Sonic Blow in pre-renewal for example).

The reason why there still seems to be hitlock is:

1. For client-controlled creatures, first of all the client has an build-in delay of 850ms between move commands. So if you click to move, it will take 850ms until the client will send another move command.
   On the server there is a 350ms delay for how often it will accept move command from the client.
   Neither has anything to do with attacking, using skills or getting hit, it's just a delay between move commands.

2. For server-controlled creatures, there is also no walk delay. However setting the "attacker ID" is actually delayed by dMotion of the target. So for example say you have 160 ASPD (400 aMotion) and your target has a dMotion value of 288. Then it from the beginning of the attack to when the target will start chasing, there is actually a 688ms delay. However, hitting the monster again, will not reset the delay, it will just queue another "attacker ID" to be set after 688ms again. That means while you do delay the start of the chase, you cannot slow down any target already chasing.
   The only way to create hitlock here is to make the monster drop its target, which you can either do by hitting it beyond chase range or by blinding it (flash arows are more useful than you think).

---

By the way, you don't need a developer to fix this, if you just want to get rid of walk delay.
You can already disable walk delay through config settings.

For normal attacks it's in battle.conf:

// Should normal attacks give you a walk delay? (Note 3)
// If false, characters can move as soon as they start an attack (attack animation
// or walk animation may be omitted client-side, causing cropped attacks or
// monsters that teleport to you)
// Otherwise, the delay is equal to the 'attack animation' (amotion)
attack_walk_delay: 15

For skills it's in skill.conf

// This delay is the min 'can't walk delay' of all skills.
// NOTE: Do not set this too low, if a character starts moving too soon after
// doing a skill, the client will not update this, and the player/mob will
// appear to "teleport" afterwards.
default_walk_delay: 300

Just set these to 0 if you don't want walk delay.