Pretty much, the vessel would have to implement oMMU to receive the transfer but it'd otherwise work the same as a docked transfer.Sounds good. So you would enter the handle to the transferee vessel? That sounds good.
That would be a good thing for base developers. With UMmu, AU had to circumvent the transfer-when-docked restriction by means of creating a virtual docking situation AKA hooking into GetDockStatus(). It worked pretty well, but yeah... it was just a hack.This type of functionality would also be useful for bases as vessels / modules (e.g., how Ascension Ultra worked for managing ummus) - so it'll definitely be added.
I would suggest separating both passengers/crew and cargo. While both are just payloads from a spaceflight perspective, its better if you could choose the framework that suits you best, instead of getting bloat.Are thinking about cargo if the future? Like UCGO
UCGO kinda works but with no ummu to open it is dead weight/visual
Look forward to testing on the Ranger and LEr on the moon
I've made some progress, but it's a busy time of year (I have two assignments, a project proposal and 5 exams due :lol so there's been a larger delay than I would've hoped for, apologies. As of now the main crew management API is done, I'm just working on the oMMUs themselves - Orbiter 2016's touchdown points have made smooth ground movement somewhat complicated so that has been a hold up, but progress is being made there.Woo482, any updates?
AFAIK, WooMMu will be closed source, so you can't link to it in plain GPL code. However, you could perhaps implement the WooMMu linking part as a separate module licensed with something like MIT, that offers functions via "operating system" channels like clbkGeneric. In other words: load it as module, let it interact with your GPL-vessels only via Orbiter.Will be with a GPL compatible license, so we could include it in SSU as well?
Yeah, exactly, that would be a possible workaround. But still, I had to ask there, for avoiding annoying discussions what a system dependency is in our case, because if we extend the definition in our application to other Orbiter add-ons, I fear to open a really bad can of worms there.Sure, this might ignite the discussion whether or not Orbiter is even the "operating system" for the GPL-vessels to start with, but we have another thread for that. If you are seeing GPL vessels as linkable to Orbiter, the above method should be as compatible as it gets.
Indeed it is, as sad a conclusion that might be for the Orbiter community. If the SSU project needs some help with the above mentioned work-around (and a similar thing for XRSound), I'm willing to help, though. The described code would be so trivial to do that I wouldn't have a problem contributing it as MIT code to SSU.Its much easier to develop closed-source add-ons and just don't give a damn. :dry:
I'll see, when it oMMU is close enough to release. Maybe everything will look different than compared to today.Indeed it is, as sad a conclusion that might be for the Orbiter community. If the SSU project needs some help with the above mentioned work-around (and a similar thing for XRSound), I'm willing to help, though. The described code would be so trivial to do that I wouldn't have a problem contributing it as MIT code to SSU.