It would be cool to have idle animations on ships. Since it still needs to fit into the data budget, I think complexity will be reasonable.
![[Image: Q9MMu4n.png]](https://i.imgur.com/Q9MMu4n.png)
Potential applications:
Transform was another idea. Instead of states, they would just move like turrets using rotations and degrees per second. Spinning things would cover most animation needs, and be more fluid at the same time. Maybe make a hard vertex budget for transformations, as they'll probably be heavier at runtime and they're harder to include into the data budget.
aX aY aZ T PlaceAxis
Everyone else, would you use this feature? What would you do with it?
Potential applications:
- Functional Observatories/Orreries
- Moving engine parts
- Coffee replicator [beam in coffee (startup) -> spinning coffee bubbles (active) -> coffee goes into garbage (deactivating)]
- Breathing/beating organs
- Deploying animated bridge (eg. Gipsy Danger)
- Milling Wind Mill
- Add State gives 4 options
a. Inactive. A starting, resting, "off" state. If there is no inactive state, the loop will stop on whatever "Active" state is active at the time, and start on "Active 1" when the design spawns. All animations have and start with an "Active 1" state. b. Startup. Starting the animation will run through these states before entering the loop. c. Active. The active cycle of states. They show at their "time". "Delays" would add time to the cycle, effectively pausing the timer if they are present. They mean there is a delay before that part shows. All animations start with an "Active 1" state, and it cannot be removed. d. Deactivating. Turning off the animation will run through these states before resting on "Inactive" once again. Using a time from the loop will be when the loop breaks, and states will be spaced using "delays". Breaking the loop means that, when the trigger to turn off is made, the last loop will run all its states from time 0 to the deactivation time. i. Deactivating states with different times or 0 delay will cause errors, and shouldn't let you leave this window without sorting them. - Powered means that the reactor must be on for the animation to start. Pressing switches or sitting down or otherwise, nothing will happen. If there is no "Powered" or "Event", the animation will always loop from the moment the design spawns.
- Events are triggers that activate the animation. "Switches" and "Proximity" use the same placement function as door switches. Occupied Seats are "Associated" with the animation part.
- Animations are made using a Part -> Make -> Animation function.
- For the sake of preventing too much abuse, voids, barriers and paths cannot be associated with these states. They are treated like landing gear for collision and volume.
Transform was another idea. Instead of states, they would just move like turrets using rotations and degrees per second. Spinning things would cover most animation needs, and be more fluid at the same time. Maybe make a hard vertex budget for transformations, as they'll probably be heavier at runtime and they're harder to include into the data budget.
aX aY aZ T PlaceAxis
- Absolute X degrees
- Absolute Y degrees
- Absolute Z degrees
- Time Interval (frames, or 1/60 seconds), the how frames between updating the angle.
- PlaceAxis, select the spot the thing spins around.
Everyone else, would you use this feature? What would you do with it?
