Potential pitch for Experimental Animation

[Logzombie]

Admittedly this is a much needed improvement over what's already being used. The current animation part is unfortunately fraught with issues, such as the loop function not functioning at all, the inconsistency when used on an imported mdl entity causing the animation to not only play at the incorrect rate but also from a random frame, and the incredible inability for two animation parts to play at once.

So I am pitching a new idea for what might be ideal to implement on a newer, more functional part for all to use without having to find workarounds just to use properly. This is what I personally feel would benefit the part most and will benefit users attempting to create new events with it, as PAC has transitioned from just an outfitter into an event-heavy creationfest.

Firstly: Keep everything that works. Ping pong loop, rates, min and max and invert frames can all stay. Staples that regardless of their functionality have a niche for specific events. Aside from brushing up on a few unstable functions, there is little need to improve something that works to a good degree otherwise.
Secondly: The looping function will probably need to be fixed, and the emphasis on playing the animation from start to end at the displayed rate needs to be maintained for both looping being enabled and disabled respectively. Additionally, remove the cap on how fast or slow you can attempt to make an animation. Currently users have to use the invert frames function to get their animation rates above the current maximum rate by setting their rates to -3 and beyond to achieve specific speeds. This is mostly for convenience. Also easier transitioning between separate animation parts will benefit us all, so I'll put this here too.
Thirdly: New potential functions, such as animation priority. Functioning similar to draw order, this will allow two animations to play simultaneously with one overriding the other without breaking the animation rates. This will help with periodic idle animation setups, as a transitioning animation playing on an event being hidden, will override the idle animation which may immediately be triggered once parameters for it being re-enabled are first activated. Additionally, I was considering perhaps moving a lot of the functions from the Gesture part into this part for convenience, however this is not the main goal, and maybe keeping the two separate is a better idea, but may still be on the table for handling gesture support.

The overall goal of this is to add some quality of life changes that on paper are very doable, fixing a lot of issues and potential for complex usage, while making the part easier and more convenient for the user to utilise in their creations.