Project Universal Astronaut and Cargo System (UACS)

[n72.75]

I don't know a whole lot about licenses. I simply chose GPLv3 because I think it's the main license for open-source projects, but I don't mind any license. Which license do you suggest?

(Disclaimer: I am not a lawyer)

Licenses do [at least] two things: they protect your rights to your work when you share the source code, and they guarantee the rights they specify to those that modify and redistribute the work in whole or in part.

If you don't have strong opinions about FOSS license philosophy I would encourage you to aim for a very permissive license, like the MIT license.

One of the challenges that licensing your work under GPL3 will bring, is that it probably can't be used with more permissive projects. This would effectively prevent it from ever being included in the Orbiter core, XR vessels, and even NASSP (which is GPL2 for complicated historical reasons). This graph shows a very basic overview of the compatibility (I could combined some MIT licensed code with your code, but not the other way around).

Almost all licenses boil down to: "I hereby grant you these rights, one of which is that you will also grant those rights to others." This almost universally prevents relicensing to a more permissive license, because to do so would be to fail to grant the rights guaranteed by the original license to others.



Personally I would go with the MIT license, but that decision is 100% your choice.

 

[Abdullah Radwan]

Thanks for taking on such an interesting project!

I see a bit of a challenge with the user interface:
Shift-Key commands are used for control. Normally Shift-Key commands are reserved for MFD's.
The UACS intercepts these commands, so MFD operation with keys is not possible.

Proposal: Use Alt-Key commands.

To my knowledge Alt-Key is unused, while Unmodified-Keys and Ctrl-Keys are used for vessel commands.

This is exactly the kind of feedback I am looking for. I will change it in the next alpha. Thank you so much!

(Disclaimer: I am not a lawyer)

Licenses do [at least] two things: they protect your rights to your work when you share the source code, and they guarantee the rights they specify to those that modify and redistribute the work in whole or in part.

If you don't have strong opinions about FOSS license philosophy I would encourage you to aim for a very permissive license, like the MIT license.

One of the challenges that licensing your work under GPL3 will bring, is that it probably can't be used with more permissive projects. This would effectively prevent it from ever being included in the Orbiter core, XR vessels, and even NASSP (which is GPL2 for complicated historical reasons). This graph shows a very basic overview of the compatibility (I could combined some MIT licensed code with your code, but not the other way around).

Almost all licenses boil down to: "I hereby grant you these rights, one of which is that you will also grant those rights to others." This almost universally prevents relicensing to a more permissive license, because to do so would be to fail to grant the rights guaranteed by the original license to others.



Personally I would go with the MIT license, but that decision is 100% your choice.

Alright. I will change the license to MIT in the next alpha.

 

[Face]

Alright. I will change the license to MIT in the next alpha.

Since you are not that much into license, be aware that MIT also allows this: take your open work, change something, distribute it closed further on. If you don't care about that, MIT is the perfect Orbiter addon license now that the core itself is marked that way.

 

[gattispilot]

Given that you said in PM the altitude is correct on Mars but not on the Moon, that most likely means you have an issue with the Moon elevation and surface data.

Great. now how to fix?

So on MARS I placed an EVA guy near the rover

Looks good all is just on top

But put the rover and guy in the moon base scenario.

they are above the surface.

Here i placed a dg there. the nose wheel is in the ground but the rear wheels are above it.

To simulate real life, you can move the LER very close to the habitat door, then ingress the astronauts from inside the habitat. I think this should work.

Maybe. But the problem is the airlock in the real vessel are above the surface.

Also will you have it so if a crew person is in a vessel a mesh can be seen in the vessel? I know the mesh will need to be specific to that vessel.

Also is it possible to have a vessel as a eva crew? I am think from my Interstellar addon the robots which had animations,......

 

[gattispilot]

I tried it on the vanilla orbiter and D3D9 R4.25. Default moon. Elevation looks good.

 

[Abdullah Radwan]

Alpha 4 released: https://github.com/abdullah-radwan/UACS/releases/tag/v0.4

It comes with MIT license, new API methods, new shortcuts so as not to interfere with MFDs, and bug fixes.

I really need some feedback on the API and its documents. Given this is anticipated to be a major addon if you will, I don't like me developing the API on my own, as it may be difficult to substantially change the API once the addon is mass implemented to preserve backward compatibility.

I also need a lot of testing. The code is massive and it's very hard to test everything. I am fairly sure there is a bug lying around somewhere.

 

[gattispilot]

Are there documents? Movement is good. One thing I noticed before there was more info on the HUD. But now all I see is oxygen and time.
Can you switch out of the suit in oxygen like on Earth?
Can you set up a area on the moon,... with air?

On the pb hud. Maybe move the text to the right?

I didn't see cfg for airlock location,.... for PB.

on the cfg for astronauts
"C 0 -0.45 1.05 0 -1 0 0 0 -1 SCRG ; The cargo attachment point, direction, and rotation when the suit is weared."
should be:
"C 0 -0.45 1.05 0 -1 0 0 0 -1 SCRG ; The cargo attachment point, direction, and rotation when the suit is worn."

exited good except for location. But how to get back in?

One issue really not related is the placement of the cargo. As you said you have to move the cargo and then they are good.

 

[4throck]

Gave it a try and it works

But the astronaut performs no actions... at least I wasn't able to do anything with it.
The astro has no HUD with key options, only on the PB.

Is the base door supposed to open? Does the EVA guy have lights for night operations?
It would be nice if the astro could move cargo around and unpack it.

Jumping would also be "nice to have", along with the kangaroo jump, but it's not a priority.

 

[Abdullah Radwan]

Are there documents? Movement is good. One thing I noticed before there was more info on the HUD. But now all I see is oxygen and time.
Can you switch out of the suit in oxygen like on Earth?
Can you set up a area on the moon,... with air?

On the pb hud. Maybe move the text to the right?

I didn't see cfg for airlock location,.... for PB.


on the cfg for astronauts
"C 0 -0.45 1.05 0 -1 0 0 0 -1 SCRG ; The cargo attachment point, direction, and rotation when the suit is weared."
should be:
"C 0 -0.45 1.05 0 -1 0 0 0 -1 SCRG ; The cargo attachment point, direction, and rotation when the suit is worn."

exited good except for location. But how to get back in?

One issue really not related is the placement of the cargo. As you said you have to move the cargo and then they are good.

I meant the API documents. I still have to write the user documents. As for the astronaut, it's my mistake for changing the HUD mode shortcut, sorry! Use Alt + M to change the HUD mode. The last 2 HUD modes are for showing shortcuts.

It's possible to remove the suit in a breathable cargo. Try going into the life module and removing the suit there using Alt + S.

Moving some text to the right is a great idea. I will do that in the next alpha.

It's not possible to change ShuttlePB airlock or slot position, as it's hard-set in the code. I see no need to make them modifiable, as ShuttlePB isn't supposed to be used as a normal UACS vessel, but rather as a testbed for UACS capabilities. When the first public release is out, I will try to add UACS support to several vessels, such as the default DeltaGlider and G42-200 Starliner.

Good catch on the typo! I will fix it in the next alpha. I will look into the airlock position as well.

To get back in, switch the HUD mode to Vessel HUD using Alt + M, then ingress using Alt + I.

Gave it a try and it works

But the astronaut performs no actions... at least I wasn't able to do anything with it.
The astro has no HUD with key options, only on the PB.

Is the base door supposed to open? Does the EVA guy have lights for night operations?
It would be nice if the astro could move cargo around and unpack it.

Jumping would also be "nice to have", along with the kangaroo jump, but it's not a priority.

Sorry, it's my fault on the astronaut. You can change the HUD mode using Alt + M and navigate to the last 2 modes, where you will have a full list of all shortcuts.
The base (called life module) mesh is static, so there are no animations.

You can indeed add and move cargoes around. Check out the shortcuts to do so!

I am not sure how to implement jumping. If anyone has an easy way to do it, I would happily implement it.

 

[gattispilot]

I will take a look at the API.
On the PB and other vehicles will there be a way to make airlock either hard code or cfg?

On the jumping. I think if you move the mesh up and down when moving

 

[gattispilot]

Page 22 API
Currently, this is used to link grapplde cargoes to their slots after loading the scenario


should be:
Currently, this is used to link grapple cargoes to their slots after loading the scenario


All looks good.

So to transfer you must be dock, right? I am wondering how to do this on the surface when the hatch may be above the surface?

Also like UMMU when the person is in the vessel it showed a mesh

 

[gattispilot]

yES.. alt+m CHANGES THE hud. But I could not change the vessel or airlock.

; === UACS cargo configuration file === PackedMesh = UACS\Container3 ; The packed cargo mesh file path from 'Meshes' folder, without .msh. CargoMass = 3000 ; The cargo mass in kilograms. CargoType = 2 ; 0 = Static, 1 = Unpackable only, 2 = Packable and unpackable. UnpackingType = 0 ; 0 = UACS module, 1 = Orbiter vessel. UnpackedMesh = UACS\LifeModule ; The unpacked cargo mesh file path from 'Meshes' folder, without .msh. UnpackedSize = 6.6 ; The unpacked cargo mean radius in meters. UnpackedFrontPos = 0 -1.87 3.99 ; The unpacked cargo front touchdown point position. UnpackedRightPos = 4.95 -1.87 -3.99 ; The unpacked cargo right touchdown point position. UnpackedLeftPos = -4.95 -1.87 -3.99 ; The unpacked cargo left touchdown point position. UnpackedAttachPos = 0 -1.87 3.4 ; Optional: the unpacked cargo attachment point position. UnpackedCS = 59.14 106.71 38.84 ; Optional: the unpacked cargo mesh cross sections, from Shipedit (see the manual for the explanation). UnpackedPMI = 13.84 17.74 7.09 ; Optional: the unpacked cargo mesh inertia tensor, diagonal from Shipedit (see the manual for the explanation). Breathable = TRUE ; Optional: if the cargo can be breathed in when unpacked. ; === Don't edit the data below === Module = UACS\Cargo

Is there a way to set the airlock/breathable area

 

[4throck]

I am not sure how to implement jumping. If anyone has an easy way to do it, I would happily implement it.

Thanks for the answers!
Like gattis mentioned, I think you can simply animate the mesh. An up/down animation cycle, using gravity to scale the maximum height achieved.

I was able to reenter shuttle PB, deploy cargo, EVA, grapple it with the astronaut and deploy it
That puts the fun back into orbiter, great job!

But I find that keyboard commands only seem to work on the HUD mode that doesn't show the shortcuts. That's a bit confusing


Overall great job. A few pictures just for fun:

Moving cargo in darkness


Cargo deployed!

 

[Abdullah Radwan]

Page 22 API
Currently, this is used to link grapplde cargoes to their slots after loading the scenario


should be:
Currently, this is used to link grapple cargoes to their slots after loading the scenario


All looks good.

So to transfer you must be dock, right? I am wondering how to do this on the surface when the hatch may be above the surface?

Also like UMMU when the person is in the vessel it showed a mesh

Fixed! Thanks for reporting.

Yes, a vessel must be docked to the airlock to transfer astronauts into it. It's not possible to transfer astronauts to the surface. To transfer astronauts into a base, egress and move them to the base.

Showing an astronaut mesh inside a vessel must be implemented by the vessel, not UACS. If anyone can modify the ShuttlePB external mesh to have an astronaut on the seat, I will implement it by swapping the default external mesh with the astronaut external mesh whenever an astronaut is onboard.

yES.. alt+m CHANGES THE hud. But I could not change the vessel or airlock.

; === UACS cargo configuration file === PackedMesh = UACS\Container3 ; The packed cargo mesh file path from 'Meshes' folder, without .msh. CargoMass = 3000 ; The cargo mass in kilograms. CargoType = 2 ; 0 = Static, 1 = Unpackable only, 2 = Packable and unpackable. UnpackingType = 0 ; 0 = UACS module, 1 = Orbiter vessel. UnpackedMesh = UACS\LifeModule ; The unpacked cargo mesh file path from 'Meshes' folder, without .msh. UnpackedSize = 6.6 ; The unpacked cargo mean radius in meters. UnpackedFrontPos = 0 -1.87 3.99 ; The unpacked cargo front touchdown point position. UnpackedRightPos = 4.95 -1.87 -3.99 ; The unpacked cargo right touchdown point position. UnpackedLeftPos = -4.95 -1.87 -3.99 ; The unpacked cargo left touchdown point position. UnpackedAttachPos = 0 -1.87 3.4 ; Optional: the unpacked cargo attachment point position. UnpackedCS = 59.14 106.71 38.84 ; Optional: the unpacked cargo mesh cross sections, from Shipedit (see the manual for the explanation). UnpackedPMI = 13.84 17.74 7.09 ; Optional: the unpacked cargo mesh inertia tensor, diagonal from Shipedit (see the manual for the explanation). Breathable = TRUE ; Optional: if the cargo can be breathed in when unpacked. ; === Don't edit the data below === Module = UACS\Cargo

Is there a way to set the airlock/breathable area

The breathable area is defined by the UnpackedSize.

Thanks for the answers!
Like gattis mentioned, I think you can simply animate the mesh. An up/down animation cycle, using gravity to scale the maximum height achieved.

I will see what I can do about this.

 

[gattispilot]

Thanks. Yes the vessel's code needs to add the mesh. But It needs to know there is a crew in it.

In UMMU there were lines of code you had to add into the vessel codes.....

On the breathable area. So if you had a large base like Moonbase Alpha. it would have to be a packable vessel?

On the HUD. I get no astronaut info


Also will it have action areas? Like the crew inside the vessel it would be hard coded. In the Moonbase Alpha we had UMMU could go to a door and if the right area press a key and the door would open.

 

[Abdullah Radwan]

Thanks. Yes the vessel's code needs to add the mesh. But It needs to know there is a crew in it.

In UMMU there were lines of code you had to add into the vessel codes.....

On the breathable area. So if you had a large base like Moonbase Alpha. it would have to be a packable vessel?

On the HUD. I get no astronaut info


Also will it have action areas? Like the crew inside the vessel it would be hard coded. In the Moonbase Alpha we had UMMU could go to a door and if the right area press a key and the door would open.

Vessels can know whether there is an astronaut or not, and know its position as well. That's how the ShuttlePB displays the onboard astronaut information whenever an astronaut is onboard.

Currently, it's not possible for vessels to be breathable unless they implement UACS cargo API in code. In the next release, I will make it possible for vessels to be breathable by adding an attachment point, like how vessels become stations now.

You're getting no astronaut info because, well, there is no astronaut on the default scenarios other than you. If you add another astronaut inside the ShuttlePB and egress it, the HUD should show its information.

I will look into implementing action areas.

 

[4throck]

Action areas would be interesting.

I haven't checked orbiter's API in years, but I think you can send a key command to another vessel.
If that's indeed possible, it would be the simplest solution, because it allows interaction with any existing vessels.

On the example gattis mentioned, I'm thinking of a door implemented in vessel builder using key animations.
If the eva guy is able to "press" the action key when close (~0.5m) (and without having to change the selected vessel) it would be great.

Just an idea!

 

[Max-Q]

I haven't checked orbiter's API in years, but I think you can send a key command to another vessel.
If that's indeed possible, it would be the simplest solution, because it allows interaction with any existing vessels.

Check out my LWLL addon. I implemented action areas for deploying the rover. Source code included, might be helpful?

 

[gattispilot]

You said the airlocks are hard coded, right? Will you provide lines of code to add airlocks. Then a coder person could add the lines.

I guess you can more than 1 airlock per vessel?

Just thinking how the eagle could be retro fitted so guy could enter her?

Might need to adjust the exit point. Ouch!!!

Added another guy from Interstellar. And the Lander. Will there something to make the airlock open or close. then tie to animation state? So if the lander door is closed so is the airlock?

On breathable area. So if some one added this to a base they could have a breathable area?

 

[Abdullah Radwan]

You said the airlocks are hard coded, right? Will you provide lines of code to add airlocks. Then a coder person could add the lines.

I guess you can more than 1 airlock per vessel?

Just thinking how the eagle could be retro fitted so guy could enter her?

Might need to adjust the exit point. Ouch!!!

Added another guy from Interstellar. And the Lander. Will there something to make the airlock open or close. then tie to animation state? So if the lander door is closed so is the airlock?

On breathable area. So if some one added this to a base they could have a breathable area?

I am planning on writing a full manual for both users and developers, stay tuned!

It's possible to add an infinite amount of airlocks. There are no limits. You can open and close the airlock as well.

For the base, you can define an attachment point in the base config file and the base will be a breathable area. The breathable area size will be the same as the vessel size, so you must set this properly.