Playtester - Sep 14, 2014 17:29
Michi requested me to write in detail how all of this should work.
As this is a very complicated matter, I will write it in requirement form to get it as simple and as testable as possible. I will write how it should be, please note that I'm not 100% sure how it works on Hercules right now, so some of the things might already work.
If you need references or have questions, I will answer them (and provide as many as I can). Most of this can be easily perceived by just playing on official servers and is well known among players.
Hitlocking:
[b]REQ01[/b] - When hitting a monster or player, the target should stop on the closest cell. This should apply for all monsters, even bosses including MVPs. Only exception is "Endure".
[b]REQ02[/b] - A flinch timer in duration of dMotion should be started on hit, when no flinch timer is existing for the unit yet.
[b]REQ03[/b] - Monsters should start walking again exactly at the moment their flinch timer has passed (dMotion) with no further delay.
[b]REQ04 [/b]- When continously attacking a monster (including MVPs) in the same regular interval, you should exactly then be able to hitlock it when the following applies:
There exists a natural number x (1, 2, 3, ...) for which the following statement becomes true:
[b][i][(x*HitDelay - dMotion) < Speed/2][/i][/b]
(Hint: HitDelay = (200-ASPD)*20)
That means you need to hit a monster faster than (Speed/2)ms after its flinch ended to prevent it from moving a cell. See posts below for further info.
[b]REQ05[/b] - When a unit is hit while its flinch timer is active, the unit should not be stopped again and no new delay should be applied.
[b]REQ06 [/b]- When a player is hit by a monster and clicks right after that on a cell (or just kept pressing the mouse if he was already walking), he should immediately continue moving after hit server-sided.
Position Display:
[b]REQ07[/b] - During the "Flinch" animation, the player / monster should not be displayed as moving and instead display the flinch animation. Right after the flinch animation, the client should display movement towards the cell the player / monster is really on. For a player with agi up that equals about 3-4 cells. The speed of the movement displayed should depend on the distance the unit moves. If it's 3 cells or more it looks very fast, if it's just 1 cell, it looks like normal speed or even slower.
[b]REQ08 [/b]- When a player / monster is hit DURING his flinch animation, the flinch animation will start from the beginning, however, at the time the [b]first[/b] flinch animation would have ended, the position gets updated (again displaying movement to actual cell, no teleportation, see above). So even if the unit gets hit faster than its flinch animation, it should not mean that the position is never updated.
Monster Behavior (regarding delays):
[b]REQ09[/b] - It should not be possible to walk right through a monster without the monster starting an attack, even if the monster is slow (e.g. Zombie). It should start its attack a few milliseconds after the moment you come into its attack range. This should be visible by the monster clearly displaying the first frame of its attack animation (e.g.Zombie leaning back).
[b]REQ10[/b] - When a monster starts its attack (normal attack only), it should not connect until after the attack animation (almost a second for zombies). This means the player might already be several cells away from the monster the moment he gets stopped (attack WILL connect even if you are very far away). The player should never be pulled back next to the monster unless he was next to the monster in the first place.
[b]REQ11[/b] - Monsters should start moving again right after their attack was applied. They should NOT wait for their attack delay to move again. So if the player was 3 cells away when hit, you can see the monster immediately starting to walk towards him.
In a follow-up post I'll add how I remember it worked on emulators. As far as I can tell none of the statements above are true yet and all need to be fixed.
This post has been edited by
Playtester
on Sep 15, 2014 15:42
Rikter - Sep 14, 2014 18:10
I looked into this issue, as well.
As far as I saw, hercules is handling the movements to a target cell by "timing" it (aka. time it needs to arrive from cell A to Target cell B).
When you get hit, the flinch animation starts, and update this "walk time" by increasing it. Nothing wrong with that, but what I noticed is that if you doesn't "click" again to re-send a movement packet, client stucks at the cell where you got damaged. Serverside, you moved (with proper walk delay) and arrived at destination cell (You'll see that if you got damaged by a monster, this moster will move to your destination cell to attack you again, as server correctly informs you about your current position, and upon being hit again, client will be updated and informed about that position too).
Imo, what's really missing is communication beetween server and client when receiving a damage packet. Resending the movement packet at the end of flinch animation temporally fixes this issue, but it's not really the best way to manage this issue.
Playtester - Sep 14, 2014 18:49
Alright, this post will refers to the requirements above and will
a ) Explain how I think it currently works on emulators (but should not)
b ) Post theories on how I think it works on official servers based on my tests
[b]REQ01[/b] - a ) Emulators currently have no stopping and no delay for boss types.
b ) I assume this was done out of desperation because nobody could find a solution to "lighten" the delay so that it's not possible to easily hitlock MVPs.
[b]REQ02[/b] [b]/ REQ03[/b] - a ) Both monsters and players seem to stop a lot longer after being hit than they are on official servers.
b ) I guess they don't restart walking again fast enough.
[b]REQ04 / REQ05 [/b]- a ) On emulators, this is very black and white. There is currently nothing in between "Permanent Endure" and "Very easy to hitlock everything with 190+ aspd". Even if you don't set a walk delay and just make the target stop on emulators, it's still incredibly easy to hitlock any slower monster.
b ) I have a theory here how it works on Aegis: If a unit gets hit, a timer (think of it like a status change) will be created for the duration of the flinch animation. While this timer is active, the unit is immune to be stopped by additional hits and no additional timers are created. At the end of the timer, it will trigger an event that updates the position of the unit.
This would actually explain everything I noticed during my tests and also explains why you need to hit each monster in a different interval to stop it (almost) completely and why faster ASPD ruins it again.
[b]REQ06 -[/b] a ) This might actually work already, but I say for sure that on emulators it's always SOOO hard to get away from monsters if you got hit once. On Aegis it seems muuuuuch easier. In fact no monster there can get me stuck forever. Not even being attacked by 20+ venatus at the same time can.
b ) Might be related to what I write above. Might be proof that the stop immunity does not only apply for monsters, but also for players.
[b]REQ07 [/b]- a ) Often big position lag seems to appear on emulators here. But might only be the case for REQ08.
[b]REQ08 - [/b]a ) If you hit a monster very fast on emulators it's position is NEVER updated. It won't show "fast movement" in regular intervals at all. The monster will display on the same cell you started attacking it until it is right next to you and launched an attack. Then suddenly the monster will be teleported next to you on the client. This is nothing like official servers at all.
b ) Again I think it is related to the "timer" system explained above. When a unit gets, it will start a timer that ends after the duration of one flinch animation. At the end of the time span the position of the unit hit will always be updated. At least for this I'm almost sure it's like that. Even being hit during flinch animation won't increase the time until your position gets updated again. Hence I think the timer is created only on first flinch and only a new timer is created when the previously timer was deleted. You will display the flinch again and again, but the old timer remains remember and at the end of it, your position will always be updated, even if you are in the middle of a follow-up flinch.
[b]REQ09 [/b]- a ) On emulators I can easily pass right through a slow monster without it attacking me. Very obvious with Zombies like monsters. While on official I can't walk through it, on emulators I just walk through it and the Zombie even continue one or two cells into the direction it original went to. It takes very long compared to official servers only it actually even starts turning around.
b ) I think it is simply not checked often enough if there is a target in attack range. How often is this checked? Almost feels to me like this doesn't even happen every cell? For a zombie it feels almost like half a second until it turns around at all. On Aegis it's maybe... 100ms until it starts displaying it's attack animation?
[b]REQ10 / REQ11[/b] - a ) Not sure if REQ10 works on emulators, but I remember on emulators that I was mostly hit while being right next to the monster. On officials I'm almost always 3-4 cells away at the time of the hit, I just can't remember this being like that on emulators.
Regarding REQ11 this is a very noticable difference. On emulators a zombie will for example wait his whole aDelay until it walks again. On official servers it will be moving a few milliseconds after his attack applied.
b ) The monster thinking on officials seems to be like this (I leave random walking out):
Step 1: Check for target.
Step 2: Target in range: Check for skills (depending on condition and state) and launch them immediately or start cast time.
Step 3: Target in visible range and no skill to use: Start movement towards target.
Step 4: Target in attack range and no skill to use: Wait until aDelay is done.
Step 5: aDelay done: Start normal attack animation. Apply aMotion and aDelay.
Step 6: Wait for aMotion.
Step 7: aMotion done: Attack hits.
Step 8: Jump directly to Step 1 without waiting (i.e. monster can move and use skills during aDelay!)
This post has been edited by
Playtester
on Sep 14, 2014 18:50
Playtester - Sep 14, 2014 18:56
[quote name="Rikter" timestamp="1410718228"]
I looked into this issue, as well.
As far as I saw, hercules is handling the movements to a target cell by "timing" it (aka. time it needs to arrive from cell A to Target cell B).
When you get hit, the flinch animation starts, and update this "walk time" by increasing it. Nothing wrong with that, but what I noticed is that if you doesn't "click" again to re-send a movement packet, client stucks at the cell where you got damaged. Serverside, you moved (with proper walk delay) and arrived at destination cell (You'll see that if you got damaged by a monster, this moster will move to your destination cell to attack you again, as server correctly informs you about your current position, and upon being hit again, client will be updated and informed about that position too).
Imo, what's really missing is communication beetween server and client when receiving a damage packet. Resending the movement packet at the end of flinch animation temporally fixes this issue, but it's not really the best way to manage this issue.[/quote]Actually I'd say it's the opposite.
I just tested it on iRO and when you are hit you WILL stop and you won't walk again until you click again or keep the left mouse button pressed. On officials you will stop on both client and server-side. You can however move right away after being hit (even though it won't display until the first flinch time ended).
So the wrong part on emulators is that you aren't stopped properly server-sided.
The other wrong part is that on emulators the location of the target hit isn't updated after first flinch time ended. If you don't act again (on emulators), it will display you on the wrong cell forever.
Rikter - Sep 15, 2014 8:47
[quote name="Playtester" timestamp="1410720984"][quote name="Rikter" timestamp="1410718228"]
I looked into this issue, as well.
As far as I saw, hercules is handling the movements to a target cell by "timing" it (aka. time it needs to arrive from cell A to Target cell B).
When you get hit, the flinch animation starts, and update this "walk time" by increasing it. Nothing wrong with that, but what I noticed is that if you doesn't "click" again to re-send a movement packet, client stucks at the cell where you got damaged. Serverside, you moved (with proper walk delay) and arrived at destination cell (You'll see that if you got damaged by a monster, this moster will move to your destination cell to attack you again, as server correctly informs you about your current position, and upon being hit again, client will be updated and informed about that position too).
Imo, what's really missing is communication beetween server and client when receiving a damage packet. Resending the movement packet at the end of flinch animation temporally fixes this issue, but it's not really the best way to manage this issue.[/quote]Actually I'd say it's the opposite.
I just tested it on iRO and when you are hit you WILL stop and you won't walk again until you click again or keep the left mouse button pressed. On officials you will stop on both client and server-side. You can however move right away after being hit (even though it won't display until the first flinch time ended).
So the wrong part on emulators is that you aren't stopped properly server-sided.
The other wrong part is that on emulators the location of the target hit isn't updated after first flinch time ended. If you don't act again (on emulators), it will display you on the wrong cell forever.[/quote]
This make sense too, I never tested on iRO, so I didn't know that you stops when you receive an attack. Either way, yeah, the problem's still the same, just different way to handle it :)
Playtester - Sep 15, 2014 11:12
(cross-post from rAthena, seems like I should re-evaluate how hitlocking works)
After running several tests, I'm almost sure that hitlock is in direct relation to dMotion (aka "attackedMT" on Aegis).
Generally:
1. Higher dMotion often makes it harder to hitlock a target.
2. Monsters with the same dMotion usually need the same ASPD to be hitlocked.
3. Hitlock actually stops working with higher ASPD values (if you can hitlock at 190 aspd, that doesn't mean you can at 193 aspd).
I created a list of MVPs with reported values of ASPD at which you can hitlock them and looked up their corresponding Speed and dMotion values.
Keep in mind that ASPD means (200-ASPD)*20ms delay between attacks.[quote]
Name,AspdForHitlock,Speed,dMotion
Atroce,187,150,240
Baphomet,190,100,576
Boitata,185,200,288
Dark Lord,188,100,480
Detardeus,188,250,360
Doppelganger,185,100,288
Dracula,185,145,576
Drake,189,400,360
Egnigem Cenia,184,100,288
Evil Snake Lord,189,200,420
Fallen Bishop,190,150,360
Gloom Under Night,190,200,576
Golden Thief Bug,187,100,480
Gopinich,188,150,432
Hardrock Mammoth,190,150,588
Hatii,189,400,336
Ifrit,190,130,360
Ktullanux,187,400,216
Maya,187,100,480
Memory of Thanatos,187,120,504
Moonlight Flower,185,150,288
Satan Morroc,189,100,432
Stormy Knight,185,200,288
Nidhoggur,191,150,864
Orc Lord,191,100,360
Orc Hero,189,150,648
Osiris,189,100,384
Pharaoh,185,125,288
Phreeoni,185,200,288
RSX 0806,184,220,240
Samurai Specter,190,135,576
Tao Gunka,190,150,144
Tendrillion,190,100,360
Vesper,188,180,432
Wounded Morroc,188,100,432[/quote]It gets interesting if you group those MVPs togethers that have the same value for dMotion:
[b]dMotion 288[/b]
Boitata 185
Doppelganger 185
Egnigem Cenia 184
Moonlight Flower 185
Stormy Knight 185
Pharaoh 185
Phreeoni 185
As you can see the hitlock values reported are always 184 or 185 aspd. That's a delay from 300ms to 320ms between hits.
Interesting is that dMotion is 288ms, which is only slightly lower than that.
That means to hitlock a monster you need to hit it right after it's dMotion has passed.
Coincidence? Maybe. So let's see other dMotion values!
[b]dMotion 360[/b]
Detardeus 188
Drake 189
Fallen Bishop 190
Ifrit 190
Orc Lord 191
Tendrillion 190
Interesting again that all the ASPD values reported are close to each other. While 288 all were 184 or 185, here they are between 188 and 191. The lower ASPD needed for Detardeus and Drake can be explained by their slow movement speed.
So let's look again at the delay between the hits: 180ms to 240ms.
So now let's look at the delay between every two hits: 360ms to 480ms.
Again, this is slightly higher (or equal) than dMotion. Again these mobs are hit shortly after their dMotion ends. Detardeus has 120ms to move, but it needs 250ms to move a cell (125ms to move half the cell), not enough to succeed at doing so.
Well I can already see a pattern here... but let's make sure with some more...
[b]dMotion 432[/b]
Gopinich 188
Satan Morroc 189
Vesper 188
Wounded Morroc 188
Again very similar ASPD values. 188-189. That means 220ms-240ms between hits. And that means 440ms-480ms between two hits. Aha! Again every second hit is right after dMotion.
[b]dMotion 480[/b]
Dark Lord 188
Golden Thief Bug 187
Maya 187
Let's make it short: 187-188 aspd. 240ms-260ms between hits. 480ms-520ms between two hits. Again every second hit right after dMotion.
[b]dMotion 576[/b]
Baphomet 190
Dracula 185
Gloom Under Night 190
Samurai Specter 190
Now you might be like "Oh no, Dracula doesn't fit in", but think carefully. 190 aspd means 200ms between hits 400ms between two hits and 600ms between three hits. That means in this case the third hit hits right after dMotion.
For the reported value on Dracula, that's 300ms between hits and 600ms between two hits. Tada! Now it makes sense, right?
Seems this rule applies for all monsters. If they are hit right after their dMotion ends, they can't move a cell, but if your attack rhythm is off, you can't stop them.
For 100 speed monsters, you need to hit them within 50ms after their dMotion ended so they are hitlocked. Detardeurus with 250 speed is still hitlocked 120ms later. Which seems to indicate that it really is speed/2.
This seems to apply just for too many MVPs to just be coincidence if you ask me.
Playtester - Sep 15, 2014 11:48
Updated REQ02 to REQ06 based on new tests (see post above).
Edit:
[url="https://www.youtube.com/watch?v=5DOOM7lSCMU"]https://www.youtube.com/watch?v=5DOOM7lSCMU[/url]
Here is proof that it's possible to hitlock MVPs. Please note how strongly the slow down decreases when buff is gone and his ASPD drops from 193 to 192.
This post has been edited by
Playtester
on Sep 15, 2014 15:43
Playtester - Oct 14, 2014 13:42
All the sections of "monster behavior" should be fixed now, Michi merged the fixes I did on rAthena for that.
Hitlocking also should be improved.
However, the position lag issues are still there.
It's almost impossible to fix to without restructuring the whole damage code. The problem is that right now we have dMotion all over the place and modify it in various locations too. We have nothing to to ensure that the dMotion value send to the client (for example in clif_attack) is equal to the walkdelay that is actually applied.
How it should be... is actually that the "walkdelay" sent to the client should contain the remaining walkdelay after the hit. If you get hit during flinch, you don't actually get a new walkdelay, but keep the old one, but we need to inform the client about it too. Currently we just keep telling it that there is a new walkdelay of 400-800ms. No wonder that it goes desync.
Also I've high doubts that dMotion is actually AGI dependent as we put it in our source code. I wonder what the source for that was? Maybe people got the impression that they get away easier with higher AGI? But I think that's just because you can easily run away if a hit misses.
Aegis would rather indicate a static delay of either 288ms or 600ms for players (there are two different sources, not sure which one is actually used). But without packet capturing I guess we won't be able to tell.
It's not easy to connect walkdelay with the client info because it goes through so many different function and many skills even directly access it. I wonder why it was implemented like this at all. Why not remove giving dMotion to anywhere and just draw it from the status instead? Then fix up the status to actually contain the real value.
There are more issues than just position lag from being hit, though. There is also the issue with knockback not displaying you on your new position half of the time. And there are some issues with certain spells where the motion delay is completely desync with the walkdelay (for example monsters can move while casting waterball server-sided, but it won't display them moving, especially bad with Waterball 10).