I was thinking of spawning the phoenix capsule at the end of a mission, so that the crew can return to Earth via direct aerobrake, but its not a big deal.
For that you'd need to make a new module type that can spawn a vessel. Not extremely difficult, now that I come to think about it, at least in the basics. To make it more generally applicable, say to set conditions under which it can spawn or not spawn, and what it consumes to do it is a bit more complex.
Plus it might be a bit of work to integrate the functunality into the control panel... :shifty:
Obviously Ive never worked with anything this complex before, but what exactly is the barrier to taking IMS modules apart after integration? If we delete the modules data, spawn the vessel & reset vessel behaviour, arent we pretty much good to go?
Yes... and no. This is basically it, but doing it is a lot more complex than it sounds, which is mostly due to the somewhat limited core architecture, which doesn't treat modules as classes, but as several structs storing several parts of their data. For example, a usual module stores all its data in a Module struct. An engine, however, needs an additional Engine struct to store its engine-specific parameters. Any module with a generator dumps its generator-related data into a struct which is managed by the power system class, The core doesn't even know it's there.
All these structs are merely connected among each other by the module index.
Here's a funny example of how stuff happens in that convoluted system:
Module 5 is a habitat module with a generator. While evaluating the temperature struct of module five, it is noted that module five has overheated and needs to shut down. A message is passed to the core to shut down module five. The core shuts down module five. Because it has habitation capacity, it substracts the modules habitation capacity from the vessels overall crew capacity and updates the overall crew capacity. It shuts down module five.
In the next iteration, the powersystem goes through its generators. It looks at the module index of its generators, and calls up the module struct of each index. When it arrives at the power generator coupled to module index 5, it sees that the module has shut down. Ergo, it shuts down the generator.
Now imagine the nightmare of having
dynamic module indices in a system like that, which you need to have if you want deconstructability. The work clawing together all these structs and updating their indices is tremendous and very prone to be an absolute bug-fest, and we're talking fatal bugs here.
Plus, you don't know where the attachment point was that got deleted when the module got integrated.
It's a big can of worms, and probably only a bit more work, but a lot more stable, to rewrite the entire architecture first to something that is actually designed with deconstructability in mind (i.e. treating each module type as an inherited class from a basic module class, instead of just as a flag in the module struct).
. Lots of projects with websites arent nearly as cool as this. Nobody made anything at all though?
