Project Orbiter MMU (oMMU) development thread

[gattispilot]

Sounds good. So you would enter the handle to the transferee vessel? That sounds good.

 

[Woo482]

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.

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. Maybe CSSC v2.0 would be a good test bed for this :hmm:

 

[gattispilot]

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

 

[Face]

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.

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.

 

[Urwumpe]

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 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.

But having a common SPI for cargo handling in Orbiter might be good, so multiple different cargo or producer/consumer add-ons can interoperate.

 

[BenSisko]

Woo482, any updates?

 

[Loru]

I'm working on meshes ATM

 

[Woo482]

Woo482, any updates?

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.

---------- Post added at 16:19 ---------- Previous post was at 16:10 ----------

Well, progress may be too loose a term - it works perfectly at high time accelerations at least :lol:

 

[jedidia]

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.

Ha, tell me about it! :lol:

 

[gattispilot]

Ha, tell me about it! :lol:

me Too!!!

I don't think it can be perfect.

 

[BenSisko]

Woo,
No apologies necessary! Real life is real life!! I can wait until Tuesday

---------- Post added at 04:40 PM ---------- Previous post was at 04:28 PM ----------

h:I just watched the video, that oMMu is really movin'. I think you've made the Flash:leaving::rofl:

 

[gattispilot]

Any updates? I finally got my LER to drive. now it needs a crew.

 

[Woo482]

Sorry, I've been busy and haven't had the time to work on it properly - I'll have a look at how far along it currently is and put together a proper status update over the weekend.

 

[4throck]

No rush, but it would be great to have it....

I have Orion+Altair for 2016 working reasonably well, and some moon EVAs would be great.
It would also integrate well with the LER.

So oMMU is greatly anticipated !

 

[Urwumpe]

Will be with a GPL compatible license, so we could include it in SSU as well?

 

[jedidia]

I don't think there's any GPL-compatible closed-source licenses... :shifty:

 

[Face]

Will be with a GPL compatible license, so we could include it in SSU as well?

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.

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.

 

[Urwumpe]

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.

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.

Its much easier to develop closed-source add-ons and just don't give a damn. :dry:

 

[Face]

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.

 

[Urwumpe]

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.

I'll see, when it oMMU is close enough to release. Maybe everything will look different than compared to today.