Project Orbiter MMU (oMMU) development thread - Page 3 - Orbiter-Forum

**Woo482** · 02-26-2018, 08:14 PM

Quote:

Originally Posted by Interceptor

Hey Woo482 would it possible in a future version to a add an extra keystroke to arm the airlock before opening a specific airlock,for example if there were 4 airlocks on a vessel,you would press the key number of the airlock,such as 1.and,another key to open the airlock before the EVA,and a voice,and or text message would appear saying what number airlock is open,and ready for EVA?

oMMU is intended as a framework for other developers to use in implementing crews into their vessels - adding features like these would detract from that goal, though if I added UMMUFA-like features to allow any vessel to support oMMU without needing changes in the C++ module in the future a feature like mentioned would likely be a part of this.

Quote:

Originally Posted by Ripley

Can somebody tell me the differences between the two?

Exactly as Marijn said, ship -> ship transfers are done through docking port airlocks, the other type requires walking / flying your crew member between the vessels.

4throck · 02-27-2018, 09:12 AM

Suggestion: handle everything from a MFD where you can see available ports, ships, spawned EVA guys/girls, etc.

**Woo482** · 02-27-2018, 01:21 PM

For 1.0 I just want to focus on the C++ API itself and providing a good framework so that vessels like the XR Series can implement oMMU. The plan is to implement more advanced features like that in future versions - I already have a ton of ideas there (Universal oMMU, habitats, basic 'base' management, cargo frameworks, etc.) but if I started expanding the scope that rapidly now oMMU would turn into a Star Citizen level project of over promising and never delivering (Though unfortunately without the $50,000+ / day income

)

jedidia · 02-27-2018, 02:26 PM

Quote:

Suggestion: handle everything from a MFD where you can see available ports, ships, spawned EVA guys/girls, etc.

I really don't think an MFD is a good way to handle it. It would potentially bypass closed airlocks, since that functionality would be implemented by the vessel, not ommu itself.

It would be better to have a dialog box to manage vessels that don't have a ommu implementation, and lotherwise leave the implementation to the implementing vessel.

**Loru** · 02-27-2018, 03:52 PM

Kinda works (boilerplate vessel for rendering testing):

gattispilot · 02-27-2018, 03:57 PM

Is there a beta for testing?

**Loru** · 02-27-2018, 04:01 PM

Quote:

Originally Posted by gattispilot

Is there a beta for testing?

Not yet. It's pre-alpha ATM and I'm using default .CFG vessels for rendering tests of the models.

**Woo482** · 02-27-2018, 04:13 PM

The intention is for a private alpha with the XR-Series in a few weeks, with release of the initial public beta version not long after that.

gattispilot · 03-20-2018, 12:35 PM

So to transfer crew. Will the ships need to be docked?

The reason is lets say a vessel like my LER has a crew person and they want to exit into the habitat module. It would need to dock to it, right?

My issues is sometimes docked landed vessel don't do to well.

And because of terrain the docking may not visually align.

**Woo482** · 03-20-2018, 01:56 PM

There's no reason they have to be docked, I can add a function to the API to allow transfers by vessel handle if it'll be helpful. Also, apologies for blowing right past the estimated date for first release - I've been busier with other things than I had hoped.

gattispilot · 03-20-2018, 02:15 PM

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

**Woo482** · 03-20-2018, 02:15 PM

Quote:

Originally Posted by gattispilot

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

gattispilot · 03-20-2018, 02:34 PM

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** · 03-20-2018, 03:01 PM

Quote:

Originally Posted by Woo482

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** · 03-20-2018, 03:23 PM

Quote:

Originally Posted by 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

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.

03-20-2018, 02:15 PM	#42
Woo482 Moderator	Quote: Originally Posted by gattispilot 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 Last edited by Woo482; 03-20-2018 at 02:17 PM.

Quick Links	Need Help?
About Us Register to Participate Orbiter Website Orbiter Download Projects Recommended Addons Orbit Hangar Mods Photo Gallery Social Groups External Links	Did you forget your password? Rules & Guidelines Frequently Asked Questions Orbiter F.A.Q. Orbiter Tutorials Orbiter IRC Chat Search Forum Site Map Contact Us Mark Forums Read

02-26-2018, 08:14 PM	#31
Woo482 Moderator	Quote: Originally Posted by Interceptor Hey Woo482 would it possible in a future version to a add an extra keystroke to arm the airlock before opening a specific airlock,for example if there were 4 airlocks on a vessel,you would press the key number of the airlock,such as 1.and,another key to open the airlock before the EVA,and a voice,and or text message would appear saying what number airlock is open,and ready for EVA? oMMU is intended as a framework for other developers to use in implementing crews into their vessels - adding features like these would detract from that goal, though if I added UMMUFA-like features to allow any vessel to support oMMU without needing changes in the C++ module in the future a feature like mentioned would likely be a part of this. Quote: Originally Posted by Ripley Can somebody tell me the differences between the two? Exactly as Marijn said, ship -> ship transfers are done through docking port airlocks, the other type requires walking / flying your crew member between the vessels.

02-27-2018, 09:12 AM	#32
4throck Enthusiast !	Suggestion: handle everything from a MFD where you can see available ports, ships, spawned EVA guys/girls, etc.

02-27-2018, 01:21 PM	#33
Woo482 Moderator	For 1.0 I just want to focus on the C++ API itself and providing a good framework so that vessels like the XR Series can implement oMMU. The plan is to implement more advanced features like that in future versions - I already have a ton of ideas there (Universal oMMU, habitats, basic 'base' management, cargo frameworks, etc.) but if I started expanding the scope that rapidly now oMMU would turn into a Star Citizen level project of over promising and never delivering (Though unfortunately without the $50,000+ / day income )

02-27-2018, 02:26 PM	#34
jedidia shoemaker without legs	Quote: Suggestion: handle everything from a MFD where you can see available ports, ships, spawned EVA guys/girls, etc. I really don't think an MFD is a good way to handle it. It would potentially bypass closed airlocks, since that functionality would be implemented by the vessel, not ommu itself. It would be better to have a dialog box to manage vessels that don't have a ommu implementation, and lotherwise leave the implementation to the implementing vessel.

02-27-2018, 03:52 PM	#35
Loru Moderator	Kinda works (boilerplate vessel for rendering testing):

02-27-2018, 03:57 PM	#36
gattispilot Addon Developer	Is there a beta for testing?

02-27-2018, 04:01 PM	#37
Loru Moderator	Quote: Originally Posted by gattispilot Is there a beta for testing? Not yet. It's pre-alpha ATM and I'm using default .CFG vessels for rendering tests of the models.

02-27-2018, 04:13 PM	#38
Woo482 Moderator	The intention is for a private alpha with the XR-Series in a few weeks, with release of the initial public beta version not long after that.

03-20-2018, 12:35 PM	#39
gattispilot Addon Developer	So to transfer crew. Will the ships need to be docked? The reason is lets say a vessel like my LER has a crew person and they want to exit into the habitat module. It would need to dock to it, right? My issues is sometimes docked landed vessel don't do to well. And because of terrain the docking may not visually align.

03-20-2018, 01:56 PM	#40
Woo482 Moderator	There's no reason they have to be docked, I can add a function to the API to allow transfers by vessel handle if it'll be helpful. Also, apologies for blowing right past the estimated date for first release - I've been busier with other things than I had hoped.

03-20-2018, 02:34 PM	#43
gattispilot Addon Developer	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

03-20-2018, 03:01 PM	#44
Face Beta Tester	Quote: Originally Posted by Woo482 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.

03-20-2018, 03:23 PM	#45
Urwumpe Not funny anymore	Quote: Originally Posted by 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 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.