Jump to content

  •  

Playtester

Member Since 24 Apr 2013
Offline Last Active Apr 20 2016 09:24 AM
-----

Issues I've Posted

    Hitlocking, position display, monster behavior

    Posted 14 Sep 2014

    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:

    REQ01 - 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".

    REQ02 - A flinch timer in duration of dMotion should be started on hit, when no flinch timer is existing for the unit yet.

    REQ03 - Monsters should start walking again exactly at the moment their flinch timer has passed (dMotion) with no further delay.

    REQ04 - 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:
    [(x*HitDelay - dMotion) < Speed/2]
    (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.

    REQ05 - 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.

    REQ06 - 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:

    REQ07 - 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.

    REQ08 - When a player / monster is hit DURING his flinch animation, the flinch animation will start from the beginning, however, at the time the first 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):

    REQ09 - 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).

    REQ10 - 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.

    REQ11 - 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.