Sounds good. So you would enter the handle to the transferee vessel? That sounds good.
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.
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.
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?
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.
me Too!!!Ha, tell me about it! :lol:
Will be with a GPL compatible license, so we could include it in SSU as well?
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.
Its much easier to develop closed-source add-ons and just don't give a damn. :dry:
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.