Complex rotations don't work on the first ineraction
DrprofLuigi opened this issue ยท 1 comments
The convertible on the UNU 750 De Luxe Convertible in UNU Civilian Pack V4.2.1 does not fold properly when it is first folded up. Activations after the first one work perfectly fine. This is somehow related to the visibility variable since I'm pretty sure this didn't happen before I added the visibility variable to the rotation.
Basically, the 'appliesAfter' ignores the inherited rotations, and everything rotates with the first rotating bit.
So, this issue is due to how animations work. Long story to follow:
When you fist place a vehicle, animations need to be set. In that case, some variables may be 1, some may be 0. Doors are an example of this. Some are open when you spawn vehicles, some are shut. When MTS first calculates an animation, be it a visibility, rotation, or translation, it sets the model object to the spot at that animation instantly. This is so when you spawn a vehicle and the doors are open, they don't all do their open animations. Same for other things. The key thing to remember is that animations, on their first calculation, move instantly to their positions.
Now, as to visibility variables: when MTS calculates animations, and encounters a visibility variable (or an active inhibitor), it will skip all further calculations. This is because there's no reason to waste FPS/TPS on calculating 3 rotations that you aren't going to apply anyways because the object is invisible.
What's happening here is the visibility variable is true when the vehicle is first placed. That blocks calculating all the following rotation variables until the top is closed. At that point, they are calculated for the first time since the visibility variable was blocking them. So the top does instant animation for those animations.
There's not really a good code way to fix this without a significant performance hit. For your case, I'd suggest either making the visibility variable the first variable so you just get an instant-close rather than a funky close. Or you can invert the open/closed door positions, but that's a lot of work for something that's a minor gain. Not to mention if the top is up when you first spawn the vehicle, then you'll not have this issue as all those animations won't be blocked by the false visibility. Your call on how you want to handle this, but I'm afraid it's a limitation of the code that I want to keep.