Recent content by Woo482

I wouldn't say I've abandoned the project or left, I just became busier than I imagined and pretty much lost all time for working on anything outside of work. I'll see if I can get things into a more usable state but I don't think I'll make the mistake of making any promises.

Sorry, I didn't realise it'd be so broken; I'll try and get things fixed up soon. The plan was MMUs to be configured via a config file, with override in the code if needed but that's not finished yet.

Sorry, lockdown has got me losing track of time :lol: Here's a basic sample vessel https://maudsley.dev/wp-content/uploads/2020/05/oMMU-PB.zip ---------- Post added at 20:42 ---------- Previous post was at 20:35 ---------- You can grab a compiled copy of the library from here now too -...

I'll see if I can put together an example on how to use it, it might reach the weekend before I have the chance though

Tuesday

Why would it? :shrug:

Don't worry, my intention wasn't to dump a repository of buggy code and run :lol: I still intend to maintain the project

So, this has been stuck in eternal dev hell for long enough for various reasons - I plan to open source what I have, hopefully to get some contributors and get things finished. I'll post an update at some point this week with more details on what's done, what's needed, where to access the...

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

For landed vessels? This thread should point you in somewhat the right direction: https://www.orbiter-forum.com/showthread.php?p=596609#post596609 For in-flight vessels it should be as simple as adding the offset coordinates to the vessel's rpos

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.

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

That's already possible when creating a crew member - oMMU_API::oMMUCrew newMember; newMember.age = 123; newMember.role = "Capt"; newMember.name = "Jane Doe"; newMember.pulse = 123; newMember.weight = 123; newMember.evaMesh = "blah.msh"; crew->AddCrew(newMember); I'd like to expand that to...

If you're wanting to copy the attitude / heading of the vessel that deployed the cargo vessel it should be possible to avoid touching arot at all - this is how I've solved it in oMMU: /* New MMU status variables */ VESSELSTATUS2 vesselStatus; memset(&vesselStatus, 0, sizeof(vesselStatus))...

Turns out it was a simple enough fix - I just needed to convert the airlock's local-space position into the horizon frame using VESSEL::HorizonRot and then add that offset to the lat / long coordinates of the parent vessel when creating the MMU vessel.