https://github.com/ohrrpgce/ohrrpgce/commit/79177c0dca8d9573845f419b2e7268aa5b7e53ee
Author: teeemcee <teeemcee@7d344553-34f0-0310-a9b1-970ce8f1c3a2>
Date: Thu Jan 8 05:40:40 2026 +0000
Fix enemy/hero flinches sometimes overshooting and not returning to
original position
Only happened with certain attack + attacker animations combos: I believe
Normal, Drop, Spread-Ring, and Scatter + attacker animations with no wait
for
retreat, e.g. heroes using Null and SpinStrike or most enemies.
This was actually two separate bugs. r13551/3a0641d8 added a one tick pause
before the return flinch starts, and the conversion of flinches to slice
velocity meant that anim_end could reset positions before the slice
velocity had
finished, (before that, there might have been a 4px jump on the last flinch
tick?). And Normal, Drop, etc wait just 5 ticks after starting a flinch
before
the animation ends, if there is no attacker retreat. I decided to only
extend
it to 6 ticks if necessary, not in general (as waits between chaining
attacks
are already too long).
I've added two safety measures:
-anim_flinchstart does an anim_waitformove to ensure flinches can't overlap
(this never happens currently, but might in future when animations are
customiable)
-anim_end waits for slice velocity before actually resetting and ending
(I doubt there's any need to reset at all any more, but we probably do
need to
wait in case of a chain)
bmod.rbas | 34 ++++++++++++++++++++++++++++++----
bmodsubs.bas | 1 +
whatsnew.txt | 2 ++
3 files changed, 33 insertions(+), 4 deletions(-)
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
