Project Orbiter MMU (oMMU) development thread

[Woo482]

So will be where you can place a virtual airlock and tie the animation to the opening/closing of the airlock.

Well, I won't handle tying the logical opening and closing of airlocks against animations in oMMU itself - IMHO it's best for the developer themselves to handle that though the airlock management functionality of the API.

Multiple airlocks would be nice.

You'll be able to have as many airlocks as you need to implement whatever behavior your vessel requires, up to around 1 million or so (I've not worked out the exact amount beyond "a lot" :lol. Currently there are two types of airlock defined in the oMMU Core, a generic airlock that can be placed anywhere but doesn't support vessel -> vessel transfers and one that is tied to a docking port and supports vessel -> vessel transfer.

Pseudocodeish examples of the two airlock types initialization below:
Creating an airlock from a docking port:

	ommuCrew->CreateAirlockFromPort(0,true);

Creating an arbitrary airlock:

       	Airlock myAirlock;
	myAirlock.miscID = -1;
	myAirlock.isOpen = false;
	myAirlock.position = _V(0, 0, 0);
	myAirlock.radius = 5.0f;
	myAirlock.type = AirlockType::sphere;
	ommuCrew->AddAirlock(&myAirlock);

I expect the 1st option to see the most use, but I saw no harm in allowing flexibility through defining your own airlocks.

 

[gattispilot]

One thing that would be nice. Not sure how possible it would be.

Make the airlocks work for non ommu's.

So if I have an eva vessel that I am using. But I want it to enter the vessel/exit.

 

[Loru]

One thing that would be nice. Not sure how possible it would be.

Make the airlocks work for non ommu's.

So if I have an eva vessel that I am using. But I want it to enter the vessel/exit.

Not sure how it could be done. Spawning and despawning your EVA vessel would require something like definition in EVA vessel's cfg but that might pose some problems for vessels that need special parameters during spawning.

oMMU_spawnable_vessel = true;

 

[Woo482]

Well, I only intended for oMMU to work with oMMU, what exactly is the use case you're thinking? The oMMU MMUs themselves will be highly customizable so should be adaptable to most representations of crew members

 

[gattispilot]

I though so.

But like in our Interstellar we have 3 Ummus But Thought about making them have animations.

Or I am thing an animated astronaut. Where arms,. legs are animated

Just wishful thinking.

 

[Woo482]

I'm unlikely to be able to add that to version 1.0 - The feature set is mostly frozen as of last night, but I'll add it to the list for future versions.

 

[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?

 

[dbeachy1]

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?

Wouldn't that all that be handled by each individual vessel? Because the key to use, and the callout (if any) would vary by vessel, wouldn't it?

 

[Ripley]

Can somebody tell me the differences between the two?

Planned features for the first release:

• ...
• (DONE) Crew transfer - Egress from one vessel and ingresss at an other...
• ...
• (DONE) Ship -> Ship crew transfers
• ...

 

[Marijn]

Can somebody tell me the differences between the two?

One could be transfer of crew between two vessels which are docked. The other one involves a little spacewalk between the vessels. Just my thought..

 

[Woo482]

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.

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]

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

 

[Woo482]

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 :lol

 

[jedidia]

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]

Kinda works (boilerplate vessel for rendering testing):

 

[gattispilot]

Is there a beta for testing?

 

[Loru]

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]

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]

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]

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.