Attached to the plane are rockets, that can launch using the Attachment system Radagast wrote after determining Sander's approach lacked flexibility. Nevertheless Sander's work to bring units on walls has still been and is epic and can be admired in 0AD's brandnew upcoming Alpha release and Sander's work showed Radagast to which things he has to pay special attention and how the engine and scripting parts interact. Thanks for the bootstrap.
The fighter uses relative velocity particles, added to the particle code by wraitii, 0AD's master of its water.
After this proof of concept we now need some time to relieve the art department which is pretty poor if we consider they have to create heaps of entities from the course of history. Therefore the 0BC developers are working on code that targets to simplify both the artists' and content creators' tasks. This will be a steady process as increasing efficiency to the max is our goal.
The rewritten stackable entity system's power will be extended over the coming months. Even the creator Radagast hisminorself at first had underestimated its power until a colleague opened his eyes as of what the new constraint system we are currently adding allows for. Let's hope we can finish it soon despite all the cornerstones we surely yet have to encounter. It's quite fancy:
For example we currently try to make units pass things over to other units and allow units to jump from one entity to another.
All this is related to the inventory system Radagast has been working on since quite some time.
Of course animations are the limit for realism here because to create them is a work-intense process and we need plenty of animations (e.g. pick up that plank, but hey, the pick-up animation needs to be different depending on where the unit attaches the entity to, e.g. attaching to the belt requires another animation than attaching a feather to the helmet ... oh dear ... perhaps better start with one generic pickup animation before the artists start a revolt to bring down the dream department).
Thus we either find a way to automating things more or we find a code solution that makes reduces the amount of animations required. For sure we'll have to bend our mind around solutions for these issues in the upcoming moons too.
We should probably increase the flexibility of the animation system by interpolating animations, i.e. transition from one to another automatically like a morph, which sounds epic but will be hard to do.