@Emdek: Yes, I had considered the performance impact also - however, what if a function could be used to define the animation and it's output cached in some basic C++ data structure that's really fast for use in the game engine? I've been experimenting caching of function output in my experiments with mutators, so hopefully I'll find some workable solutions soon.
By having functions define animations, optionally cached (or default cached), much more natural animations could be created without the tedium of manually plugging loads of numbers in to a strange text file (I can't remember what the text files are called, but I found one in my travels and their format gives no real indication of what's supposed to be happening). Using JS functions would provide a more transparent way of "describing" an animation via some mathematical formula, and likely make experimenting with animations much easier (for those that, unlike me, are good at maths). With the output cached, the game engine can use whatever data structure it wants, but for me I feel the big hurdle is defining the animation in a transparent, hackable and maintainable manner in the first place.
Just for my own sake, I'll explain how I came to be even pondering about animations, an area of the game I know nothing about.
I was thinking about how the whole config of the game hangs together. My repeated attempts to decipher the tech tree and tech prereq's were leading mostly to frustration. I eventually started to get to a point where I could identify key research paths, and then started to see patterns in how certain techs affect certain things. This was all done from the perspective of coming up with a data structure that an AI script could understand, so it could make decisions about what to research next based on current game state and so on.
Each defining techs applicable to some part of the research path, or some similar aspect of the game. This would make finding and editing techs very easy, it would make adding new techs trivial as well, and it would be very clean way for the game to load the data because it just eval() on each file to create an active JSO that both C++ and JS can interact with.
There would then be a repository of pre-requisites (this idea actually based on Shadow Wolf TJC's recent post
about how it works in WZ already.
So that then started me thinking, along with my JS API documentation, what if large chunks of the game could be ported to JS - massively cleaning the codebase in the process? That's discussed more in mutators
That then made me think.. what if we could make everything more consistent. By chance I'd just stumbled on to one of the animation files and my first thoughts were "I have no idea what any of this text means". I think to get more people contributing there needs to be greater clarity in the code and config, and more concise or descriptive ways of doing things.
A lot of the game code and config can be done in a much higher level language, because it's infrequently processed during a game. So there might be a whole bunch of JS for the engine to parse at the start of the game, but it doesn't really matter as that process is actually quite fast anyway in recent JS engines, and the extra clarity of config and game code more than justifies a couple of extra seconds waiting for a game to start.
@Jorzi - just spotted your post, I need to grab food but will respond when I get back.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."