aarthificial / reanimation Goto Github PK

[DRAFT]

[DRAFT]

Hello there, I stumbled over this neat animation project and decided to give it a try
It was a bit of a struggle to understand the driver concept but I think I got it

Until I stumbled across an issue where a node driver update appeared to not be applied.
In my case I have multiple animation states in a single animation to reduce the overhead of creating animation scripts a bit
You only need to read the bold text below, the next two paragraphs are just to describe the context of the problem

in my case I have a temporary move (blocking) which can be performed when in the 'idle' or the 'crouching' state
I tried to achieve this by appending the blocking frames to the idle and the crouching animation, but they aren't reachable by default
the IDLE and the crouch animation loops between frame 0-2 and the blocking animation starts at frame 3-5
when going into blocking state the graph goes to a switch node which updates the idle and crouch driver to the 3 to start the correspondig blocking animation at frame 3

This did not work however and I struggled to find out why until I logged the objects HashCode along with each Set call in the ReanimatorState class.
This finally lead me to the source of the problem - the ResolveDriver method in the ControlDriver class always uses previousState to update nextState, but in my case the switch updated the driver variable in nextState but it got overridden by the previousState

To clarify - the issue appears to be that SwitchNode driver updates are overridden by ControlDriver.ResolveDriver in a single frame.
I'm not sure how to resolve this correctly or if this method is even intended to work in your library
My goal was to reduce the amount of animation scripts in some way
I'm looking forward to hear from you regarding this issue :)

thanks and best regards,
Symbroson

[DRAFT]

The workflow in #12 failed due to a licensing issue caused by the following:

• Secrets are not passed to workflows triggered by a pull request from a fork.
• The license key is stored as a secret.
• The license key is required for the workflow to succeed.

This issue will cause any external PR to fail.
Possible ways of fixing it should be analyzed. If the chosen solution requires some configuration on the fork side, a proper contribution guide should be created.

[DRAFT]