Ankle Snare

I checked mine and it's working fine I don't get trapped. tested with mob also and it traps fine as it used to be.

[quote name="THPO" timestamp="1410679598"]
I checked mine and it's working fine I don't get trapped. tested with mob also and it traps fine as it used to be.[/quote]

try it in pvp or gvg

true sometimes it traps the user and sometimes not.

Officially, if Knockback is not possible (MVP/WoE) then the trapped person will still end up moving to the target cell (and activate all traps on the path). Target is unable to move again until the given status change expires, though. Maybe that's what you are experiencing?

Other than I'd say it should always work.


Edit: If it's bugged here, maybe it's related to:

case SC_ANKLESNARE:
if(st->mode&MD_BOSS) // Lasts 5 times less on bosses
tick /= 5;
sc_def = st->agi*50;
break;

But this should only affect duration because of a flag...

//Natural resistance
if (!(flag&8)) {

Hmmmm...

That's strange, the flag was changed!

eAthena:
/*==========================================
* Starts a status change.
* 'type' = type, 'val1~4' depend on the type.
* 'rate' = base success rate. 10000 = 100%
* 'tick' is base duration
* 'flag':
* &1: Cannot be avoided (it has to start)
* &2: Tick should not be reduced (by vit, luk, lv, etc)
* &4: sc_data loaded, no value has to be altered.
* &8: rate should not be reduced
*------------------------------------------*/


Hercules:
/*==========================================
* Starts a status change.
* 'type' = type, 'val1~4' depend on the type.
* 'rate' = base success rate. 10000 = 100%
* 'tick' is base duration
* 'flag':
* &1: Cannot be avoided (it has to start)
* &2: Tick should not be reduced (by vit, luk, lv, etc)
* &4: sc_data loaded, no value has to be altered.
* &8: SI will not be sent to the client
*------------------------------------------*/

Someone changed the meaning of the flag? o.o

[quote name="Playtester" timestamp="1410685042"]
Officially, if Knockback is not possible (MVP/WoE) then the trapped person will still end up moving to the target cell (and activate all traps on the path). Target is unable to move again until the given status change expires, though. Maybe that's what you are experiencing?

Other than I'd say it should always work.


Edit: If it's bugged here, maybe it's related to:

case SC_ANKLESNARE:
if(st->mode&MD_BOSS) // Lasts 5 times less on bosses
tick /= 5;
sc_def = st->agi*50;
break;

But this should only affect duration because of a flag...

//Natural resistance
if (!(flag&8)) {

Hmmmm...

That's strange, the flag was changed!

eAthena:
/*==========================================
* Starts a status change.
* 'type' = type, 'val1~4' depend on the type.
* 'rate' = base success rate. 10000 = 100%
* 'tick' is base duration
* 'flag':
* &1: Cannot be avoided (it has to start)
* &2: Tick should not be reduced (by vit, luk, lv, etc)
* &4: sc_data loaded, no value has to be altered.
* &8: rate should not be reduced
*------------------------------------------*/


Hercules:
/*==========================================
* Starts a status change.
* 'type' = type, 'val1~4' depend on the type.
* 'rate' = base success rate. 10000 = 100%
* 'tick' is base duration
* 'flag':
* &1: Cannot be avoided (it has to start)
* &2: Tick should not be reduced (by vit, luk, lv, etc)
* &4: sc_data loaded, no value has to be altered.
* &8: SI will not be sent to the client
*------------------------------------------*/

Someone changed the meaning of the flag? o.o[/quote]

I guess the bug appears in this commit..

[url="https://github.com/HerculesWS/Hercules/commit/e7be72538ea9c203bfd7a976d82e268e04303ca4"]https://github.com/HerculesWS/Hercules/commit/e7be72538ea9c203bfd7a976d82e268e04303ca4[/url]

Yep, looks like it.


A quick fix would be to change[quote]
sc_def = st->agi*50;[/quote]to:[quote]
tick_def = st->agi*50;[/quote]But to fix on emulator one should check through that whole commit and see if the old "unavoidable" flag is really not needed. Well, theoretically you don't need it because resistance is based on the type of status change and not on the skill used, I guess! But the person who changed it probably overlooked that the old flag is still used in get_sc_def and that sometimes sc_def is used instead of tick_def, relying on said flag.

Fixed in: [url="https://github.com/HerculesWS/Hercules/commit/5ea9f0b2facd123d607591eb5a408b508cb56c6c"]https://github.com/HerculesWS/Hercules/commit/5ea9f0b2facd123d607591eb5a408b508cb56c6c[/url]
Thanks to csnv