[Project] Orbiter MMU (oMMU) development thread

[gattispilot]

Thanks. Sounds good.

Maybe for version 2
Definition of attachment points (Hand, foot, back?
Ability to change cockpit view mesh?

[Woo482]

Attachment points along with some way of interacting with attached payloads (probably a set of clbkGeneric messages) is already planned - cockpit meshes are likely a v2 feature though.

[gattispilot]

Like UMMu will you have a o2 level when suited? Air filled areas? guy dead if you crash or land hard?

[Abdullah Radwan]

Quote:

Originally Posted by Woo482

 Attachment points along with some way of interacting with attached payloads (probably a set of clbkGeneric messages) is already planned - cockpit meshes are likely a v2 feature though.

UCSO can be used for payload management. If you want, I might be able to write UCSO implementation for you (depends on your code complexity).

[gattispilot]

Any progress. I am interesting how you solved the place the guy where you want and not the center

[Woo482]

For landed vessels? This thread should point you in somewhat the right direction: https://www.orbiter-forum.com/showth...609#post596609

For in-flight vessels it should be as simple as adding the offset coordinates to the vessel's rpos

[gattispilot]

Thanks. I may just wait for your add on to come out

[Woo482]

Quote:

Originally Posted by Woo482

 I was just thinking about that while finishing off implementing vessel -> vessel transfers. The best way I can think is to have an oMMU vessel interface exposing functions to be called when events happen in the core - allowing custom behaviors on events, denying ingress when a docking port is closed etc. Something along the lines of this (excuse the pseudocode):

class IMMUVessel{
public:
bool OnTryTransferCrew(const oMMU &otherVessel, const oMMUCrew &crewMember,int dockingPortID = 0) = 0;
bool OnTryCrewEnter(const oMMUCrew &crewMember, int airlockID = 1) = 0;
}

Playing around with this some more I think having a proper event system will be far more robust, and allow for add-ons that need to hook into vessels (e.g., XRRR) to function more cleanly; the structure I'm thinking of can be seen in the docs - http://files.woo482.co.uk/oMMU/html/..._1o_m_m_u.html If anyone has any feedback I'm open to it, but I think this is the best way to implement it. I think this (after too many changes ) can be considered the final API, while you're in there find the unannounced scope creep