The Wild Mod [Fabric]

The Wild Mod [Fabric]

658k Downloads

Keyframe values call from the beginning of lifetime, not animation time

MerpisMe opened this issue ยท 5 comments

commented

Animations cannot play if they are not starting from the beginning of lifetime due to animationProgress not resetting to 0 after an animation finishes.
Possible workarounds:

  • Set animationProgress to 0 once an animation is finished, and only tick it up during the progress of a keyframe animation (breaks on servers)
  • Make from:0 relative to the beginning of the animation rather than lifetime
  • Create a separate animationProgress value for every type of animation (not good for performance, also would make the code a mess)

This breaks the Warden's sniffing, roaring, digging, and attacking animations and Frogs' eating animation.

commented

Hello! I added a system to the animationAPI that allows you to create a temporary animationProgress (the animationProgress still follows). In a nutshell, giving a start and end point (on animatonProgress) creates an animation that starts from 0 and reaches w (animationProgress-startPoint). After reaching w, it will return 0 again.

I hope that you can solve the issue with that, ping me for anything (is there a ping thing on gitHub? Lol)

https://www.geogebra.org/calculator/cfdkq6k9
visualization of animationTimer

commented

This breaks the Warden's sniffing, roaring, digging, and attacking animations and Frogs' eating animation.

Technically also breaks the emerging animation as well, it won't play if you check if it's currently emerging.

Also idk if I'll be able to fix this, AnimationAPI is quite complex and Liuk is infinitely better at math than I am. I'll give it a try if the fix doesn't require changing AnimationAPI itself, but I'm just saying there's a chance it won't be feasible for me to do.

commented

I hope that you can solve the issue with that, ping me for anything (is there a ping thing on gitHub? Lol)

yes. @LIUKRAST

commented

Should we resolve this issue? The new thing that Liuk added works perfectly. Although it's a workaround, it doesn't introduce any new loopholes or bugs, therefore we probably don't need to track this issue anymore.

commented

Should we resolve this issue? The new thing that Liuk added works perfectly. Although it's a workaround, it doesn't introduce any new loopholes or bugs.

yeah, forgot to do that when i marked it as workaround