Project UCSO development thread

Will it be a normal drop-in zipped archive, as most of the other Orbiter addons?
 
First pre-release here!

Current problems:
  • Lack of cargoes due to the lack of 3D models. I am not a very good 3D modeller, and I can't find suitable 3D models. I need 3D models for life modules.
  • I didn't get any feedback since I started the development. I don't know if the API functions are sufficient. I also need enough testing on the cargoes.
  • I have to work on integration with oMMU.

Looking for your feedback and comments!
 
Last edited:
And the second pre-release is here!

Added oMMU integration, new cargoes, new features, and more!
 
Last edited:
Nice. A couple of things. I guess there is not away to switch focus on the cargo from the f3 window but thru the scn editor?
6MOQEEx.jpg


might want to add legs or lower the edge to it is firmly in the ground. This is going to be an issue due to non flat surface.
c7x8RUm.jpg


nice furniture. Now if we had people inside. Will the door open?
fUX4HSU.jpg


You can use my lunar modules for habitat if you want. No interior just exterior
 
Thanks for your feedback :tiphat:

I guess there is not away to switch focus on the cargo from the f3 window but thru the scn editor?

This is intentionally done because it is useless to have cargoes in that window. You can change this behavior in the configurations file (Config\UCSO_Config.cfg).

might want to add legs or lower the edge to it is firmly in the ground. This is going to be an issue due to non flat surface.

Unfourtanly, this problem can't be solved. If I lowered the edge it will appear under the ground for flat surfaces (i.e. no solution works for both flat and non-flat surfaces). The cargoes are set for flat surfaces.

nice furniture. Now if we had people inside. Will the door open?

You can use my lunar modules for habitat if you want. No interior just exterior

No, it's just static mesh. You can't really open the door as this is a breathable module.

Thanks for your offer. I'll check them.
 
Then we can get Ommu to work. We can functioning bases. I have a LER sled. No habitat module on it. So I might try to add cargo to it.
 
Unfourtanly, this problem can't be solved. If I lowered the edge it will appear under the ground for flat surfaces (i.e. no solution works for both flat and non-flat surfaces). The cargoes are set for flat surfaces.

It's simple, extend the walls (or legs) down about a meter.

On a flat surface they will extend underground and be invisible.
On a slope you will see them extending down to the terrain.
 
Pre-release 3 released. Added the legs to the life module, fixed bugs and added features in the API. Download from OHM.

Don't forget to check the new G42-200 with UCSO support too.

Note: This is the last pre-release. Please test it and say everything you want in the first release.
 
Last edited:
Wish list for this would be the 'Advanced Lunar surface Experiments package" along with the laptop from UCGO 2010 and some spot lights and maybe the solar panels. Having the Chariot added to the Artemis lander as well as the newer LER would be super
 
So he has spotlights and solar panels. So for personal use only. You can use other meshes and make your own packages.
 
Gattis I just landed Altair and deployed the AMSO guys with the rover. Do you think that 2016 will ever be able to fix the terrain issue ? It doable but you need to use some imagination. If you do the Artemus Lander be sure to add your folding Chariot to it .
 
Version 1.1.1 was released (should have announced for versions 1.1 and 1.0.1, but whatever). It fixes some bugs and gives some freedom, with more assertive behavior if UCSO isn't installed. The full changelog is available at the GitHub repository. Download from OHM.
 
I don't know, if this is the right place to ask...or it might be more a G42-200 problem ?

I tested the latest UCSO package in the G42 Startliner.
The idea was, to have a tiny bit more fuel.
I tested the various functions which UCSO offers.
After hitting "SHIFT+C" I can see the UCSO-HUD.
Here I loaded/unloaded/grappled some cargos...all fine
The RESOURCE-transfer worked, too.

But:

How to switch off CARGO-MODE (SHIT-C) ?
The manual states SHIFT-C is a "toggle" for the dedicated UCSO-mode and its HUD.
However, after enabling the UCSO-cargo-mode, there seems to be no way to switch it off again.
So after the first SHIFT-C, all other following SHIFT-C's are not doing anything for me.
Stuck in cargo-mode now.

Disclaimer:
Currently, I don't have any Windows-box available, I am using various WINE versions in Linux.
So issues like above might be a WINE thing. (?)
 
From G42 sources G422_SIM_CONTROLS.cpp starting line 1095:

case OAPI_KEY_C:
if (ucsoInstalled) cargoMode = !cargoMode;
else timer = 0;

return 1;

default:
return 0;

Could this be the issue ?
I am not a developer but maybe "if (ucsoInstalled) cargoMode == !cargoMode;"...could help ?
One problem is the UCSO-HUD overlay but more important, all SHIFT-C related SHIFT-<whatever UCSO sepcific action) are all permanent active.

For the moment I don't have a Windows build system available to test this...any ideas ?

Again, from the G42-manual:

"...When in cargo mode, the HUD display will show cargoes data instead of normal data, and normal shortcuts that have Shift key in it won’t work....."
The problem is, I cannot "leave" the cargomode using SHIFT-C.
Only Orbiter-restart "fixes/forces" back to default-non-cargo-mode.
 
I don't know, if this is the right place to ask...or it might be more a G42-200 problem ?

I tested the latest UCSO package in the G42 Startliner.
The idea was, to have a tiny bit more fuel.
I tested the various functions which UCSO offers.
After hitting "SHIFT+C" I can see the UCSO-HUD.
Here I loaded/unloaded/grappled some cargos...all fine
The RESOURCE-transfer worked, too.

But:

How to switch off CARGO-MODE (SHIT-C) ?
The manual states SHIFT-C is a "toggle" for the dedicated UCSO-mode and its HUD.
However, after enabling the UCSO-cargo-mode, there seems to be no way to switch it off again.
So after the first SHIFT-C, all other following SHIFT-C's are not doing anything for me.
Stuck in cargo-mode now.

Disclaimer:
Currently, I don't have any Windows-box available, I am using various WINE versions in Linux.
So issues like above might be a WINE thing. (?)
It's a G42 issue, not a UCSO one. I found the issue in the code but since I am traveling, I can't fix it now. I will fix it once I am back home (should be after 2 weeks).
From G42 sources G422_SIM_CONTROLS.cpp starting line 1095:

case OAPI_KEY_C:
if (ucsoInstalled) cargoMode = !cargoMode;
else timer = 0;

return 1;

default:
return 0;

Could this be the issue ?
I am not a developer but maybe "if (ucsoInstalled) cargoMode == !cargoMode;"...could help ?
One problem is the UCSO-HUD overlay but more important, all SHIFT-C related SHIFT-<whatever UCSO sepcific action) are all permanent active.

For the moment I don't have a Windows build system available to test this...any ideas ?

Again, from the G42-manual:

"...When in cargo mode, the HUD display will show cargoes data instead of normal data, and normal shortcuts that have Shift key in it won’t work....."
The problem is, I cannot "leave" the cargomode using SHIFT-C.
Only Orbiter-restart "fixes/forces" back to default-non-cargo-mode.
Nope, this code is correct. The issue is that once in cargo mode, I don't listen to the Shift+C command anymore (there is no "case OAPI_KEY_C" in the switch statement in cargo mode). I don't know how I missed it!
 
Thanks for the info. So within the cargo-mode-loop there is no SHIFT-C check anymore (to leave the loop/cargo-mode).
Sorry for posting this issue in the wrong thread, but nice to know that a fix will be available soon.
There are much more interesting possibilities using UCSO, so no idea why it's not more used.
I will def. play a little bit more around with it. Esp the "consume" function is very interesting.
 
Back
Top