Search results

First public release is out there! Time to work on integrating UACS into Deepstar and G42-200 Starliner!

Abdullah Radwan submitted a new addon: Universal Astronaut and Cargo System (UACS) - Astronaut and cargo management system for Orbiter Read more about this addon...

Universal Astronaut and Cargo System (UACS) is a free, open-source astronaut and cargo management system for the Orbiter space simulator. It features a rich API for modules, astronauts, and cargoes to integrate within UACS, detailed astronaut implementation, with an optional realism mode to...

This entire code needs to be rewritten since it was written for fixed astronaut meshes, not variable ones. Define an array to store astronaut mesh handles. Then for ingress, use the method I wrote to get the astronaut mesh, add the mesh to the vessel using AddMesh method, set its location, and...

Here is a sample code: std:string GetAstrMesh(const UACS::AstrInfo& astrInfo) { std::string configFile = std::format("Vessels/{}.cfg", astrInfo.className); FILEHANDLE hConfig = oapiOpenFile(configFile.c_str(), FILE_IN_ZEROONFAIL, CONFIG); if (!hConfig) return {}; char...

My perspective is that most vessels can't use the astronaut mesh directly as it needs to be modified. This means vessels will use custom astronaut meshes to display astronauts once inside regardless of the astronaut actual mesh, which negates the need to expose the astronaut mesh to vessels. To...

It doesn't make sense to display meshes based on airlocks. Think of people setting in chairs in a building that has several doors in a game. Does it make sense to display people based on the chair they're sitting on or the door they entered through? The chair of course. The same applies here...

When the astronauts are inside a vessel, they are merely stored as information in the vessel, not as active Orbiter vessels (unlike cargoes for example), so they can't have their own calculations. Regardless, I think it's better to leave this up to each vessel, as the vessel has complete control...

You can use the Carrier to egress the astronaut from an elevation above ground. Currently, a fall from ~120m is deadly. As for disabling the option, it's linked to the EnhancedMovements option. I can make it a separate option if you want to. I am planning to support UACS in G42 and Deepstar...

New release! One step closer to the first stable release. Please provide final feedback as the next release is most likely the first stable release. Download from here: https://github.com/abdullah-radwan/UACS/releases/download/v1.0-prerelease8/v1.0.Pre-release.8.zip Changelog: Added Astronaut...

Remove the role in every call to the method. In the line you provided: SetStationMesh(stationIdx, false); I will look into that.

Remove std::string_view role: void SetStationMesh(size_t stationIdx, bool show); Thanks! But this code doesn't show the part where the mesh is flattened.

Have you changed the method definition in the header file? Remove role from the method parameters. As for the VC, it appears that you must load its mesh (VCMESH) using oapiLoadMeshGlobal for it to work, so you can leave it as it was set before. Other meshes can be added with AddMesh normally...

First, there is no need to use oapiLoadMeshGlobal to load the meshes. Change eva1_mesh and eva2_mesh variables type to UINT and load the meshes using AddMesh. void MMSEV::clbkSetClassCaps(FILEHANDLE cfg) { eva1_mesh = AddMesh("MMSEVUACS/MMSEVsuitleft1", &mesh1ofs)...

Yes, since Orbiter Sound library is dynamically linked. So XRSound default sounds can be used alongside Sound Bridge OS to basically have XRSound with dynamic linking. Yes, the SetStationMesh method is completely messed up. You need to write it properly and use the show parameter to hide/show...

New release with a lot of changes in preparation for first stable release. Special thanks to @Buck Rogers for his help and contributions! Please test and evaluate thoroughly for any bugs. As for compiling with static runtime for compatibility with XRSound library, that is sadly not possible due...

Not only the bottom should be at -0.65m. All sides should be at 0.65m (whether left, right, top, or bottom) as some vessels may attach the cargo from the top instead of the bottom, and some may attach it from the side. If you want your cargo to be compatible will all vessels, make it a box 1.3m...

There are several issues with your code: 1. The API clbkPostCreation method is not called in the vessel clbkPostCreation. That's why the attachment point position differs when you add a cargo vs when you reload the scenario. 2. The attachment points position height is set higher than the floor...

Can you send the vessel and cargo files and code so I can investigate further? I suspect you didn't set the attachment points properly. To unpack a cargo, release the cargo then unpack it (Alt + R -> Alt + U). You can set the release position by manipulating the slot info ground info struct...

Yes: https://github.com/abdullah-radwan/UACS/tree/master/Sources/Vessels/Carrier