Issue Information
-
#004249
-
2 - Fair
-
Fixed
Issue Confirmations
-
Yes (0)No (0)
Originally posted by tiagoeu
http://www.eathena.w...er&showbug=4249
It happened a few complaints on my server on an issue. GRF, to edit. ACT skills of the players managed to remove the delay of the skills that had the file. ACT edited. I tested using the time. GRFEditado and time without using it. GRFEditado. Actually the delay is reduced even the low amount of SP faster.
PS: if you want to. GRFEditada only comment I send the link.
http://www.eathena.w...er&showbug=4249
It happened a few complaints on my server on an issue. GRF, to edit. ACT skills of the players managed to remove the delay of the skills that had the file. ACT edited. I tested using the time. GRFEditado and time without using it. GRFEditado. Actually the delay is reduced even the low amount of SP faster.
PS: if you want to. GRFEditada only comment I send the link.
Originally posted by Ind
Maybe if we matched the animation delay server-side, not sure.
Maybe if we matched the animation delay server-side, not sure.
Originally posted by xazax
If we would find a way to measure the animation delays precisely ( generate it from the animation files or measure it via a client side hook ) maybe it would worth adding a new field in skill_cast_db or a new db for animation delays.
After that if the configuration against this kind of grf edit is on, the delay applied on skills should be:
max(delay, anim_delay)
otherwise just
delay
If we would find a way to measure the animation delays precisely ( generate it from the animation files or measure it via a client side hook ) maybe it would worth adding a new field in skill_cast_db or a new db for animation delays.
After that if the configuration against this kind of grf edit is on, the delay applied on skills should be:
max(delay, anim_delay)
otherwise just
delay
Originally posted by sketchyphoenix
This would be better suited to the RAthena Development board since we're going into the idea of new functionality, rather than a true software bug (the issue itself is a client exploit technically).
This would be better suited to the RAthena Development board since we're going into the idea of new functionality, rather than a true software bug (the issue itself is a client exploit technically).
Originally posted by Epoque
I imagine it'd take little effort to write an ACT parser to read the animation length for the damaged and skill-cast frames, and convert that into a separate database or as a new column in the skill_cast_db.txt, I'll see what I can muster up.
I imagine it'd take little effort to write an ACT parser to read the animation length for the damaged and skill-cast frames, and convert that into a separate database or as a new column in the skill_cast_db.txt, I'll see what I can muster up.
Originally posted by Ind
create as per your suggestion: http://rathena.org/b...no-delay-issue/This would be better suited to the RAthena Development board since we're going into the idea of new functionality, rather than a true software bug (the issue itself is a client exploit technically).
Originally posted by Epoque
Should be fixed in [rev=15105], let me know if there are any problems.
I tested the code I committed on a no-delay Sniper sprite and it worked perfectly. I also checked it on a different delayed sprite (High Wizard, delay active, Jupitel Thunder at both 173 ASPD and 196 ASPD) and the animations seems to match fine.
Should be fixed in [rev=15105], let me know if there are any problems.
I tested the code I committed on a no-delay Sniper sprite and it worked perfectly. I also checked it on a different delayed sprite (High Wizard, delay active, Jupitel Thunder at both 173 ASPD and 196 ASPD) and the animations seems to match fine.