[Sanocon]

So looking at the wiki I notice the animation code is a bit... lacking. But I have some ideas to make ship animations more complex.

#1.Transition (and scaling?) This is a given. These should both be relative movement only. this should be written as +relative_trans and +relative_scale

#2.Multiple movements in one object animation. Now this would be cool to pull off. Here's and example on how it can work. let's say we have a fighter that has a gun that transforms when switching between the first and second weapon bank, however this gun has multiple parts that move or rotate more than one time in the animation. Each movement segment of animation could be called $frame: and the first 'frame' will start on 0.

Also to make things less buggy/complicated there will also be 2 flags to help it out: +flipper Those who use the Blender Game Engine may know this command. Those who don't, this flag will look and the animation data and play the animation forward if the program statement is true and if the statement is false, it will play the animation backwards from the frame it stopped on. This flag is more to save room on the table sheet.

Another flag that will help is +synctoobj:(add, object, names, here) (or Sync to Objects) The game will look through the associated objects of a ship the user has put in the table that has multiple animations when the animation plays, objects listed that finished their animation frame will wait for all objects that are listed to finish the same frame number before moving to the next frame.

Also i would recommend for the script table that there would be a way to limit user input while the animation is playing. (Like you cant fire the weapon when the gun is transforming.)

So that's all the ideas I have right now. If you want me to elaborate on something on here, go ahead and ask. You can change the flag names if you wish. They just popped into my head while planning this thread out.

[zookeeper]

#2.Multiple movements in one object animation. Now this would be cool to pull off. Here's and example on how it can work. let's say we have a fighter that has a gun that transforms when switching between the first and second weapon bank, however this gun has multiple parts that move or rotate more than one time in the animation. Each movement segment of animation could be called $frame: and the first 'frame' will start on 0.

Can't you do that already, by providing multiple animations and then using delays to make each movement occur at different times instead of simultaneously?

If it doesn't work currently for some reason, then fixing that would allow you to do what you're talking about, right?

Also i would recommend for the script table that there would be a way to limit user input while the animation is playing. (Like you cant fire the weapon when the gun is transforming.)

There's no way to limit arbitrary input, but there ought to be a lot of individual things you can limit (such as firing weapons). And of course you can take all control away from the player momentarily, if needs be.

[The E]

Also i would recommend for the script table that there would be a way to limit user input while the animation is playing. (Like you cant fire the weapon when the gun is transforming.)

There's no way to limit arbitrary input, but there ought to be a lot of individual things you can limit (such as firing weapons). And of course you can take all control away from the player momentarily, if needs be.

That part is already implemented. I don't have the table code handy at this time, but the various rotating weapons from BP:WiH (like the Kentauroi guns) all require the unfold animation to play completely before being ready to fire.

The other feature requests are definitely things we want, but at this point, it seems that implementing them requires a complete refactoring of the entire animation system, a task that noone has been willing to tackle to date.

[Goober5000]

Yes, the animation code is a sprawling mess with very little coherent design.  The best way to fix it would be to scrap it completely and then write a more robust system that uses the same table options.

[Sanocon]

Yes, the animation code is a sprawling mess with very little coherent design.  The best way to fix it would be to scrap it completely and then write a more robust system that uses the same table options.

Good idea. I would also recommend making a new .cpp file for animation tables. The ship.cpp file is cluttered as it is, thats probobly one of the reasons no one wants to work on it.

Also, Zookeeper, while the delay funtion is good, it's not as efficient and leads to the mod builder doing a lot of number guesses. Which new people wanting to make a fs2 mod probobly won't want to do.

[Goober5000]

Sanocon, it sounds like you have a pretty good idea of how the animation code should work.  Why don't you take a shot at the rewrite?  We'll be happy to give you git or SVN access.

[Sanocon]

Sanocon, it sounds like you have a pretty good idea of how the animation code should work.  Why don't you take a shot at the rewrite?  We'll be happy to give you git or SVN access.

As long as you can pinpoint where the animation code in the file, I can see what i can do.

[m!m]

The main animation code is located in modelanim.cpp.

There is a project to replace the current model files FSO uses with the standardized DAE format but I have no idea about the status.
The obvious advantages would be that you wouldn't have to worry about getting the right features into the POF specification and a nice side effect would be that modders could test the animations in the 3D modelling program of their choice instead of having to first convert the models to POF.

[Sanocon]

There is a project to replace the current model files FSO uses with the standardized DAE format but I have no idea about the status.
The obvious advantages would be that you wouldn't have to worry about getting the right features into the POF specification and a nice side effect would be that modders could test the animations in the 3D modelling program of their choice instead of having to first convert the models to POF.

Problem, since everyone making ships use PCS, both the POF replacement coders and the person behind PCS will have to collaborate on implementing the features in order for it to work 100%.

So animation code, what variable uses the object vector data?
(also, we may need Bobboau to help us out on this...)

[Scooby_Doo]

Being able to just move (translate) subobjects would be nice.  I could always extend my landing gear/rotation script to include translation features.

[Nuke]

you might want to increase instance depth. there are only 5 levels of hierarchy to work with last i checked.

also since there has been talk of doing away with pof in favor of collada or some other format. so it might be a good idea to support the animations in that format. model file contains keyframe animations, which can be rigged in the modeling program. you really only have to be able to say 'use this sequence for this animation trigger', possibly tweak timing and a few other parameters and you are ready to go. you dont have to tweak 50 moving parts with hierarchy to orchestrate a complex movement by tweaking a table again and again and again.