Project Orbiter MMU (oMMU) development thread

[Woo482]

Well, my primary motivation for keeping oMMU (Not WooMMU, dammit! :lol closed source is keeping the distribution controlled - I don't want 20 different versions floating around as it has the potential to ruin the user experience (IMHO). If there's the demand for the source to be open, and there's a compatible licence that lets me keep some amount of control over my work I'll be happy to consider it.

 

[Face]

(Not WooMMU, dammit! :lol

Too late for that. :rofl:

 

[jedidia]

I don't want 20 different versions floating around as it has the potential to ruin the user experience

If it helps any, in my experience that doesn't happen. I know the thought is a bit scary, but you can generally rely on the laziness of people.

Not WooMMU, dammit!

Indeed, way too late. We officially request, nay, demand this be the official name. And if you don't agree, we'll just keep calling it that anyways! :lol:

 

[Woo482]

Fine, I'll get Loru to put together a new logo :lol:

 

[gattispilot]

Hope you do better than this:

Sometimes the terrain covers the guy

 

[Urwumpe]

What is the maximum number of astronauts, that WooMMU can handle? (In the sense of: How many crew members will be allowed inside a vehicle? UMmu had a rather low limit for some applications.)

HUGE EDIT: Request for comments: And could your API support something like a "custom data pointer" for an astronaut, for storing a pointer to a structure of vehicle specific data? It would make some modding a lot easier and could also be used to allow chains of add-ons adding their own data easily without your module needing to manage it.

Of course, for lazy developers functions like:

void * GetExtensionData(ASTRONAUT_HANDLE hA, DWORD extensionID) const;
void * SetExtensionData(ASTRONAUT_HANDLE hA, DWORD extensionID, void * newData);

would be more comfortable since you do a lot of the job. extensionID would just some identifier for different plugin APIs, 0x0 could be reserved for vessel specific data (I assume, your plugin will be similar to Ummu and store the crew on a per vessel base). But:

void * GetExtensionData(ASTRONAUT_HANDLE hA) const;
void * SetExtensionData(ASTRONAUT_HANDLE hA, void * newData);

would also be close enough for committee work. Then its up to the developers.

With a global call back function like:

void OnCrewEvent(CrewManagement &reference, DWORD eventID, long lParam, void * pExtData) {
 ...
}

//and

void RegisterCrewEvent(CREW_EVENT_FUNC * callbackfn);

....It should be possible to even install extensions to a crew simulation as Orbiter Plugins, so generic vessel add-ons could get extended without implementing the function or including a component in Multistage / genericvessel.

For example, to understand better, what I am up to: Lets imagine, somebody made a huge passenger spacecraft with a WooMMUForAll and GenericVessel and somebody else adds a Orbiter-Passenger-Plugin, that adds ticket, destination and departure information to the crew simulation of WooMMU, which can be displayed with a MFD. And later, somebody else adds a generic medical simulation plugin. Or a generic "Passenger personality plugin".

Could all be done without such extension support from your side, of course. But the required skill level for the plugin developers would be much higher and it would be much easier to create incompatibilities that would annoy the players (they would have more work finding out which add-ons work together)

 

[Woo482]

They're stored as a STL vector, so 'a lot' is about as close as I have to a limit; I never bothered working out the actual limit :lol: way more than you could ever practically want though.

 

[Urwumpe]

They're stored as a STL vector, so 'a lot' is about as close as I have to a limit; I never bothered working out the actual limit :lol: way more than you could ever practically want though.

Well, I am right now working on something that could have 92 people onboard, that would be outside the scope of UMMU. :lol:


But a STL vector would really be enough... we could fit the whole population of a few countries into 4GB Orbiter memory space then. :lol:

 

[jedidia]

HUGE EDIT: Request for comments: And could your API support something like a "custom data pointer" for an astronaut, for storing a pointer to a structure of vehicle specific data? It would make some modding a lot easier and could also be used to allow chains of add-ons adding their own data easily without your module needing to manage it.

I thought about the same, the trouble I essentially see with it is: How do you persist that data over multiple sessions? I.e. how do you handle serialising and deserialising it?

 

[Urwumpe]

I thought about the same, the trouble I essentially see with it is: How do you persist that data over multiple sessions? I.e. how do you handle serialising and deserialising it?

Hmmm.... good question. Letting the plugin define how to handle this would be the best choice, but we have no way to save data outside a MFD mode.


There would need to be a way to call a LoadState/SaveState pair from a vessel during those functions. Or not call anything at all, should there be no serialization/deserialization intended or implemented.

 

[Enjo]

If it helps any, in my experience that doesn't happen. I know the thought is a bit scary, but you can generally rely on the laziness of people.

I completely agree. There aren't 10 versions of my module messaging lib. There were just 2 and then we switched everything to the new one in peace anyway. I learned that, that as long as you use your control wisely (don't abuse it and keep developing the software), it won't be taken away.

 

[N_Molson]

Congrats to all people working on this, good thing to see the pillars of the community working on such "meta-plugins" :thumbup:

 

[jedidia]

How do you persist that data over multiple sessions? I.e. how do you handle serialising and deserialising it?

There aren't 10 versions of my module messaging lib.

Ha! You just set my mind in motion there!

Serialising custom data wouldn't be a problem for WooMMU, it could provide a base class for the data-object and let the vessel-specific implementation do the writing.

The problem is of course that you have to delegate instantiation of the data to the vessel it belongs to when you load, because you don't know the class to instantiate.
But that could be solved by generic messaging. Parse all the custom data blocks as string, and send it around to all instantiated vessels at clbkPostCreation via clbkGeneric, or possibly using enjo's module messaging (Haven't looked at the API, so no idea if suitable), and everyone that sees that there's data in there that's relevant to it instantiates the data and injects it back into WooMMU. I'm open for better ideas, but this one should work.

Congrats to all people working on this, good thing to see the pillars of the community working on such "meta-plugins"

Actually, Woo is the only one working on it. The rest of us just make his neck hairs crawl with insane feature requests :lol:

 

[Urwumpe]

Actually, Woo is the only one working on it. The rest of us just make his neck hairs crawl with insane feature requests :lol:

I did not yet submit feature request A38: It needs more cowbell.

 

[Enjo]

Parse all the custom data blocks as string, and send it around to all instantiated vessels at clbkPostCreation via clbkGeneric, or possibly using enjo's module messaging (Haven't looked at the API, so no idea if suitable), and everyone that sees that there's data in there that's relevant to it instantiates the data and injects it back into WooMMU. I'm open for better ideas, but this one should work.

In the MM and MMExt one module sends data as one of the basic + basic Orbiter's types (*) and other modules are able to read them under a common name, for instance, they can expect, that the module "WooMMU" advertises a variable under a name "OnEVA" of a certain basic type and the client modules can read it, They can as well advertise messages under well known names for WooMMU to read. When multiple modules write the same message in the same time, the WooMMU could select which one to take.
I think Andrew will explain it better.
Jedidia: where is the initial problem description?

(*) Andrew added in MMExt a possibility to send std::strings and custom defined structs, provided that a central module (WooMMU) exposes their declarations in a header under OrbiterSDK/include.

 

[ADSWNJ]

Quick feature description of MMExt, so the folks on this thread can determine if it may be of use:

• Any to any interconnection (vessel to MFD, MFD, to MFD, etc).
• Pass by value for simple data types (e.g. int, double). One posts, the other optionally collects.
• Pass by value for Orbiter standard things (e.g. VECTOR3, MATRIX3, etc)
• Pass by value for OBJHANDLE, with additional checks to protect against object deletion.
• Pass by reference for C++ structs derived from a well-known base class. Lots of protection around this (versioning, sige of struct), to protect against mismatched versions.
• Wildcard search mode, for modules to discover new senders without needing hardcoding.

Examples: BaseSync, TransX, BurnTimeCalc, LagrangeMFD, LaunchMFD, Glideslope 2 ... all sharing variables to make the experience more intuitive.

I'd be happy to do some MMExt coding for this project if I can be of assistance.

 

[Face]

Quick feature description of MMExt, so the folks on this thread can determine if it may be of use:

Is there still the problem with missing runtimes, or is it fully late-binding now? I think the later would also be a "feature" to mention, given the middle-ware nature of WooMMU.

 

[Enjo]

Is there still the problem with missing runtimes, or is it fully late-binding now? I think the later would also be a "feature" to mention, given the middle-ware nature of WooMMU.

Andrew sorted it out. It's fully late binding, with VC runtimes statically linked.

 

[gattispilot]

I will be interested how you deal with touchdown points. I can change the y part so that the boot just touches the terrain. But then you move the guy in some parts and it covers most of him up?

 

[Woo482]

The best way I found to stop terrain eating the MMU was to set the touchdown points much larger than the physical footprint of the MMU, doing that avoided the terrain in most cases.

However my intention was / is to move away from touchdown points entirely, and update the vessel position directly through SetState - though that has enough problems on its own.