Project Universal Astronaut and Cargo System (UACS)

[gattispilot]

That's because the nearest action area (and airlock) logic gets the nearest vessel first, then it returns the nearest action area in it. This will not always yield the actual nearest action area, because it's possible that an action area in a far vessel is nearer than an action area in the nearest vessel.

What are you trying to do exactly? If I understood correctly, you have a vessel with several airlock, then you have an astronaut in range, and when you're inside the astronaut and press Ctrl + I nothing happens. Is this true? If so, you must be in either nearest or vessel HUD mode to ingress. If you pressed Ctrl + I and the ingress is not successful, an error message must appear. What's the error message?

As for the CTD, you must verify that the output of the GetAttachmentHandle method is not null, otherwise you will have an CTD when you call GetAttachmentStatus. Also, you must call GetAttachmentStatus for the vessel that has the attachment handle, NOT your vessel. A proper code will be like this:

VESSEL* v = oapiGetFocusInterface();

vAttachHandle = v->GetAttachmentHandle(true, 1);

if (vAttachHandle && GetAttachmentStatus(vAttachHandle))

I am not sure about your code design, but I think you should also verify if the focus vessel is actually the vessel you want.

So on the action area. Not sure how to fix other than putting all action areas in one vessel?
So the guy is at the action area zone of LPAd4 vessel. But can't do anything as it doesn't recognize the area?


On the attachment
OBJHANDLE hV = oapiGetFocusObject(); VESSEL* v = oapiGetFocusInterface(); UMMU1 = v->GetAttachmentHandle(true, 1); if (GetAttachmentStatus(UMMU1))
This is for an action area.
I think the focusObject is the UACS guy. It see if attached or not if not then do something.


On the airlock. I have this:
UACS::AirlockInfo airInfo, airInfo1, airInfo2, airInfo3, airInfo4, airInfo5; airInfo.name = "Front"; airInfo.pos = { 0,-1.948,5 }; airInfo.dir = { 0,0,-1 }; airInfo.rot = { -1,0,0 }; //airInfo.hDock = CreateDock({ 0,-1, -1 }, { 0,-1,0 }, { 0,0,-1 }); airInfo1.name = "Aft"; airInfo1.pos = { 0,-1.948,-5 }; airInfo1.dir = { 0,0,-1 }; airInfo1.rot = { -1,0,0 }; //airInfo1.hDock = CreateDock({ 0,-1, -1 }, { 0,-1,0 }, { 0,0,-1 }); airInfo2.name = "T_Pad_Left"; airInfo2.pos = { -39,-3.85,-1 }; airInfo2.dir = { 0,0,-1 }; airInfo2.rot = { -1,0,0 }; //airInfo2.range = { 5 }; airInfo3.name = "T_Pad_Right"; airInfo3.pos = { 39,-3.85,-1 }; airInfo3.dir = { 0,0,-1 }; airInfo3.rot = { -1,0,0 }; //airInfo3.range = { 5 }; airInfo4.name = "A_Pad_Left"; airInfo4.pos = { 12,-11.234,89 }; airInfo4.dir = { 0,0,-1 }; airInfo4.rot = { -1,0,0 }; //airInfo4.range = { 5 }; airInfo5.name = "A_Pad_Right"; airInfo5.pos = { -12,-11.234,-89 }; airInfo5.dir = { 0,0,-1 }; airInfo5.rot = { -1,0,0 }; //airInfo5.range = { 5 }; //airInfo.gndInfo.pos = { -1.7,-4.05, -2.7 }; vslAstrInfo.airlocks.push_back(airInfo); vslAstrInfo.airlocks.push_back(airInfo1); vslAstrInfo.airlocks.push_back(airInfo2); vslAstrInfo.airlocks.push_back(airInfo3); vslAstrInfo.airlocks.push_back(airInfo4); vslAstrInfo.airlocks.push_back(airInfo5); but it says the airlock is open and I have crew guy and I get no error message. but the guy can't exit.
vslAstrInfo.airlocks.at(0).open = DOOR_proc >= 1;//FRONT vslAstrInfo.airlocks.at(1).open = DOOR1_proc >= 1;//AFT vslAstrInfo.airlocks.at(2).open = APAD_proc >= 1;//APAD vslAstrInfo.airlocks.at(3).open = TPAD_proc >= 1;//TPAD
airlock status is based off animation. I would like to change this so if doors are starting to open then airlock is open.

if (key == OAPI_KEY_D && !KEYMOD_SHIFT(kstate) && !KEYMOD_CONTROL(kstate))
{

if (astrHUD.airlockIdx == 0) RevertDOOR();//right
if (astrHUD.airlockIdx == 1) RevertDOOR1();//left
if (astrHUD.airlockIdx == 2) Revertapadairlock();//right
if (astrHUD.airlockIdx == 3) Reverttpadairlock();//left

// if (astrHUD.airlockIdx == 2)vslAstrInfo.airlocks.at(2).open = 1;//FRONT
// if (astrHUD.airlockIdx == 3)vslAstrInfo.airlocks.at(2).open = 1;//FRONT
return 1;
}

Not sure if it matters but the vessel is attached? But here it shows Apad open and pressing ALT and I gets no response

 

[gattispilot]

I have this in the poststep. So if the Proc >=1 then the airlock is open right?
vslAstrInfo.airlocks.at(0).open = DOOR_proc >= 1;//FRONT vslAstrInfo.airlocks.at(1).open = DOOR1_proc >= 1;//AFT vslAstrInfo.airlocks.at(2).open = APAD1_proc >= 1;//FRONT vslAstrInfo.airlocks.at(3).open = APAD2_proc >= 1;//FRONT vslAstrInfo.airlocks.at(4).open = TPAD1_proc >= 1;//FRONT vslAstrInfo.airlocks.at(5).open = TPAD2_proc >= 1;//FRONT

and then you select the airlock and open/close it. if (key == OAPI_KEY_D && !KEYMOD_SHIFT(kstate) && !KEYMOD_CONTROL(kstate)) { if (astrHUD.airlockIdx == 0) RevertDOOR();//right if (astrHUD.airlockIdx == 1) RevertDOOR1();//left if (astrHUD.airlockIdx == 2) { if (APAD1_proc == 0) APAD1_proc = 1; else APAD1_proc = 0; } if (astrHUD.airlockIdx == 3) { if (APAD2_proc == 0) APAD2_proc = 1; else APAD2_proc = 0; } if (astrHUD.airlockIdx == 4) { if (TPAD1_proc == 0) TPAD1_proc = 1; else TPAD1_proc = 0; } if (astrHUD.airlockIdx == 5) { if (TPAD2_proc == 0) TPAD2_proc = 1; else TPAD2_proc = 0; } return 1; }

Also I notice the evaed guy can not scroll thru airlocks on this vessel??

 

[Buck Rogers]

Hi Abdullah

I've released an add-on (beta) utilizing UACS, and am very impressed with your work. So happy that you make these things possible in Orbiter again. Hope you are close to an official release!

After a few hiccups, it ran pretty smoothely.
Biggest issue so far: I had to move the camera offset way forward because I can't see through the helmet, would it be possible to add a flag for no external mesh in cockpit, or even better VC capability, I must admit I miss the sun visor toggle (and the breathing sound too!).

Another issue which I really don't know what the best solution would be is:
The Dalik problem; I have a HAB on stilts and two floors, one universal, simple solution might be to add a raise altittude key? ( not that I want to make the .cfg height thing even more confusing!)

On a side note: your stock/default models/tex. don't do your coding justice ( eg the lamp is terrible!)
And I got confused between UACS and UCSO, my bad, but I liked the other boxes so I added them in UACS, made norm maps, material fix, can update as a patch if you like?

 

[gattispilot]

I have run into an issue. It seems UACS and XRSound and OrbiterSound5.0 do not work well.
Error LNK2038 mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MT_StaticRelease' in EAGLE3UACSPASS.obj EAGLEPASSUACS D:\Orbiter2016\Orbitersdk\samples\EagleUACSpass

 

[Abdullah Radwan]

So on the action area. Not sure how to fix other than putting all action areas in one vessel?
So the guy is at the action area zone of LPAd4 vessel. But can't do anything as it doesn't recognize the area?


On the attachment
OBJHANDLE hV = oapiGetFocusObject(); VESSEL* v = oapiGetFocusInterface(); UMMU1 = v->GetAttachmentHandle(true, 1); if (GetAttachmentStatus(UMMU1))
This is for an action area.
I think the focusObject is the UACS guy. It see if attached or not if not then do something.


On the airlock. I have this:
UACS::AirlockInfo airInfo, airInfo1, airInfo2, airInfo3, airInfo4, airInfo5; airInfo.name = "Front"; airInfo.pos = { 0,-1.948,5 }; airInfo.dir = { 0,0,-1 }; airInfo.rot = { -1,0,0 }; //airInfo.hDock = CreateDock({ 0,-1, -1 }, { 0,-1,0 }, { 0,0,-1 }); airInfo1.name = "Aft"; airInfo1.pos = { 0,-1.948,-5 }; airInfo1.dir = { 0,0,-1 }; airInfo1.rot = { -1,0,0 }; //airInfo1.hDock = CreateDock({ 0,-1, -1 }, { 0,-1,0 }, { 0,0,-1 }); airInfo2.name = "T_Pad_Left"; airInfo2.pos = { -39,-3.85,-1 }; airInfo2.dir = { 0,0,-1 }; airInfo2.rot = { -1,0,0 }; //airInfo2.range = { 5 }; airInfo3.name = "T_Pad_Right"; airInfo3.pos = { 39,-3.85,-1 }; airInfo3.dir = { 0,0,-1 }; airInfo3.rot = { -1,0,0 }; //airInfo3.range = { 5 }; airInfo4.name = "A_Pad_Left"; airInfo4.pos = { 12,-11.234,89 }; airInfo4.dir = { 0,0,-1 }; airInfo4.rot = { -1,0,0 }; //airInfo4.range = { 5 }; airInfo5.name = "A_Pad_Right"; airInfo5.pos = { -12,-11.234,-89 }; airInfo5.dir = { 0,0,-1 }; airInfo5.rot = { -1,0,0 }; //airInfo5.range = { 5 }; //airInfo.gndInfo.pos = { -1.7,-4.05, -2.7 }; vslAstrInfo.airlocks.push_back(airInfo); vslAstrInfo.airlocks.push_back(airInfo1); vslAstrInfo.airlocks.push_back(airInfo2); vslAstrInfo.airlocks.push_back(airInfo3); vslAstrInfo.airlocks.push_back(airInfo4); vslAstrInfo.airlocks.push_back(airInfo5); but it says the airlock is open and I have crew guy and I get no error message. but the guy can't exit.
vslAstrInfo.airlocks.at(0).open = DOOR_proc >= 1;//FRONT vslAstrInfo.airlocks.at(1).open = DOOR1_proc >= 1;//AFT vslAstrInfo.airlocks.at(2).open = APAD_proc >= 1;//APAD vslAstrInfo.airlocks.at(3).open = TPAD_proc >= 1;//TPAD
airlock status is based off animation. I would like to change this so if doors are starting to open then airlock is open.

if (key == OAPI_KEY_D && !KEYMOD_SHIFT(kstate) && !KEYMOD_CONTROL(kstate))
{

if (astrHUD.airlockIdx == 0) RevertDOOR();//right
if (astrHUD.airlockIdx == 1) RevertDOOR1();//left
if (astrHUD.airlockIdx == 2) Revertapadairlock();//right
if (astrHUD.airlockIdx == 3) Reverttpadairlock();//left

// if (astrHUD.airlockIdx == 2)vslAstrInfo.airlocks.at(2).open = 1;//FRONT
// if (astrHUD.airlockIdx == 3)vslAstrInfo.airlocks.at(2).open = 1;//FRONT
return 1;
}

Not sure if it matters but the vessel is attached? But here it shows Apad open and pressing ALT and I gets no response

I can make the method get the actual nearest action area, but it will be rather expensive, which isn't good given that the method is called every frame, not a one-time call. So the solution is to make all airlocks in a single vessel. I am not sure if the performance tradeoff worths the benefit. What do you think?
Note that the astronaut can recognize and interact with all defined airlocks and action areas. The issue is that the nearest airlock or action area is not always the actual nearest one, but you can still access all airlocks and action areas by selecting them manually from the vessel HUD mode.

For the attachment, you need to verify that the vessel is actually the astronaut and it has the attachment point you need before doing any other operations. Otherwise, you will get an CTD if the vessel you selected isn't what you want.

As for the airlocks, I don't see anything wrong the airlock definition. You need to clarify what you mean by saying the guy can't exit. What's the return result of the EgressAstronaut method?

To make the airlock open as soon as the door starts to open, set the airlock open flag true in the method you mentioned just before calling RevertDoor and Revertapadairlock methods, like you did in the commented code.

I have this in the poststep. So if the Proc >=1 then the airlock is open right?
vslAstrInfo.airlocks.at(0).open = DOOR_proc >= 1;//FRONT vslAstrInfo.airlocks.at(1).open = DOOR1_proc >= 1;//AFT vslAstrInfo.airlocks.at(2).open = APAD1_proc >= 1;//FRONT vslAstrInfo.airlocks.at(3).open = APAD2_proc >= 1;//FRONT vslAstrInfo.airlocks.at(4).open = TPAD1_proc >= 1;//FRONT vslAstrInfo.airlocks.at(5).open = TPAD2_proc >= 1;//FRONT

and then you select the airlock and open/close it. if (key == OAPI_KEY_D && !KEYMOD_SHIFT(kstate) && !KEYMOD_CONTROL(kstate)) { if (astrHUD.airlockIdx == 0) RevertDOOR();//right if (astrHUD.airlockIdx == 1) RevertDOOR1();//left if (astrHUD.airlockIdx == 2) { if (APAD1_proc == 0) APAD1_proc = 1; else APAD1_proc = 0; } if (astrHUD.airlockIdx == 3) { if (APAD2_proc == 0) APAD2_proc = 1; else APAD2_proc = 0; } if (astrHUD.airlockIdx == 4) { if (TPAD1_proc == 0) TPAD1_proc = 1; else TPAD1_proc = 0; } if (astrHUD.airlockIdx == 5) { if (TPAD2_proc == 0) TPAD2_proc = 1; else TPAD2_proc = 0; } return 1; }

Also I notice the evaed guy can not scroll thru airlocks on this vessel??

Yes, but for performance reasons, you shouldn't do this in every frame, but rather in the same place you set the proc variable. So after you set the new value, put the line of code each for each as appropriate.

What do you mean by the astronaut unable to scroll? In the nearest HUD mode, you can only scroll through stations. To scroll through airlocks go to the vessel HUD mode.

 

[Abdullah Radwan]

I have run into an issue. It seems UACS and XRSound and OrbiterSound5.0 do not work well.
Error LNK2038 mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MT_StaticRelease' in EAGLE3UACSPASS.obj EAGLEPASSUACS D:\Orbiter2016\Orbitersdk\samples\EagleUACSpass

That's because OrbiterSound5.0 (and UACS) are built with /MD, but XRSound is built with /MT, and you can't mix those in your libraries (i.e. all libraries must either be /MD or /MT).

 

[Abdullah Radwan]

Hi Abdullah

I've released an add-on (beta) utilizing UACS, and am very impressed with your work. So happy that you make these things possible in Orbiter again. Hope you are close to an official release!

After a few hiccups, it ran pretty smoothely.
Biggest issue so far: I had to move the camera offset way forward because I can't see through the helmet, would it be possible to add a flag for no external mesh in cockpit, or even better VC capability, I must admit I miss the sun visor toggle (and the breathing sound too!).

Another issue which I really don't know what the best solution would be is:
The Dalik problem; I have a HAB on stilts and two floors, one universal, simple solution might be to add a raise altittude key? ( not that I want to make the .cfg height thing even more confusing!)

On a side note: your stock/default models/tex. don't do your coding justice ( eg the lamp is terrible!)
And I got confused between UACS and UCSO, my bad, but I liked the other boxes so I added them in UACS, made norm maps, material fix, can update as a patch if you like?
View attachment 36786View attachment 36787

Thanks for your comments! I believe I am very close to the first release. I am only waiting to see if there are more bugs before releasing. No new features are planned for the first release.

3D cockpit is too much work for me, I hardly have any experience with 3D design, and that's why all 3D models are suboptimal at best. If anybody can volunteer and make proper 3D models, I would happily include them with UACS.

I am not sure what's the issue with the camera offset. I can make an option in UACS configuration file to hide the astronaut mesh while in the cockpit view, the camera offset should be fine.

Adding a raise altitude shortcut would be too complicated unnecessarily. I think it's better to modify the height if it doesn't suit you. I would say that the elevation issue can never really be fully solved as this is just how Orbiter handles elevation data, so no matter what I do, it won't be perfect.

I can add the old UCSO containers. Send me what you have done (along with Blender files if you modified them), and I will include it in the next release.

 

[gattispilot]

That's because OrbiterSound5.0 (and UACS) are built with /MD, but XRSound is built with /MT, and you can't mix those in your libraries (i.e. all libraries must either be /MD or /MT).

Ok So Orbitersound 5.0 should work, right?

I get this:
Severity Code Description Project Path File Line Suppression State
Error LNK2038 mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' in EAGLE3UACSPASS.obj EAGLEPASSUACS D:\Orbiter2016\Orbitersdk\samples\EagleUACSpass D:\Orbiter2016\Orbitersdk\samples\EagleUACSpass\OrbiterSoundSDK50.lib(OrbiterSoundSDK50.obj) 1

runtimelibrary is:Multi-threaded DLL (/MD)

 

[gattispilot]

Also not sure on my eagle it as multiple airlocks.
But the eva can not scroll them.
scn:
BEGIN_SHIPS
eAGLE3B:EAGLE3UACS
ASTR_STATION 1
ASTR_NAME ROBBY
ASTR_ROLE Pilot
ASTR_MASS 70.00
ASTR_OXYGEN 0.99
ASTR_FUEL 1.00
ASTR_ALIVE 1
ASTR_CLASSNAME UACS\Astronauts\cylon1
ASTR_STATION 2
ASTR_NAME JohnG
ASTR_ROLE Pilot
ASTR_MASS 70.00
ASTR_OXYGEN 1.00
ASTR_FUEL 1.00
ASTR_ALIVE 1
ASTR_CLASSNAME UACS\Astronauts\SPACE1999-FD
STATUS Orbiting Moon
RPOS 159219.350 -1735136.400 -36772.184
RVEL 0.1233 0.0049 0.3011
AROT 4.648 -47.428 172.143
RCSMODE 0
AFCMODE 7
PRPLEVEL 0:0.974632
IDS 0:8 100 1:588 10
NAVFREQ 0 0
XPDR 468
GEAR 0 0.0000
BUGHATCH -2147483424 0.0000
BUG 1743151210 0.0000
DOOR 1 1.0000
DOOR1 0 0.0000
DOOR4 1 1.0000
END
AstronautRadwan1:UACS\Astronauts\Xemured
STATUS Landed Moon
POS -0.0426306 -85.9662445
HEADING 64.67
ALT 0.910
AROT 1.908 -25.310 175.537
RCSMODE 0
AFCMODE 7
PRPLEVEL 0:1.000000 1:0.988313
NAVFREQ 0 0
NAME Abdullah Radwan
ROLE commander
MASS 70.000000
ALIVE 1
SUIT_ON 1
HUD_MODE 1
HEADLIGHT 0
END
END_SHIPS

 

[Buck Rogers]

I believe I am very close to the first release.

Excellent news!

3D cockpit is too much work for me

Maybe I can make a generic cockpit?

I am not sure what's the issue with the camera offset. I can make an option in UACS configuration file to hide the astronaut mesh while in the cockpit view, the camera offset should be fine.

Camera offset is fine! hide the msh in cockpit view is exactly what I meant!

Adding a raise altitude shortcut would be too complicated unnecessarily. I think it's better to modify the height if it doesn't suit you. I would say that the elevation issue can never really be fully solved as this is just how Orbiter handles elevation data, so no matter what I do, it won't be perfect.

It's not height or elevation thats the problem. If you look here https://www.orbiter-forum.com/threads/hdu-dsh-z2-uacs-major-tom-at-solace-base.41621/ you'll see what I mean. I was thinking more on the fly adjusting altitude above ground (as in .scn alt)

I can add the old UCSO containers. Send me what you have done (along with Blender files if you modified them), and I will include it in the next release.

Yes please, I made new textures and manually changed a material value in a msh file, will upload. Can also do some of the other objects.

When one dies, runs out of air, could one make the astronaut lie down?
when running it takes a long time to stop, maybe to much momentum?
Haven't tried yet but can one attach more than one station breathing attachment to a vessel?

Thanks again!

 

[Abdullah Radwan]

Also not sure on my eagle it as multiple airlocks.
But the eva can not scroll them.
scn:
BEGIN_SHIPS
eAGLE3B:EAGLE3UACS
ASTR_STATION 1
ASTR_NAME ROBBY
ASTR_ROLE Pilot
ASTR_MASS 70.00
ASTR_OXYGEN 0.99
ASTR_FUEL 1.00
ASTR_ALIVE 1
ASTR_CLASSNAME UACS\Astronauts\cylon1
ASTR_STATION 2
ASTR_NAME JohnG
ASTR_ROLE Pilot
ASTR_MASS 70.00
ASTR_OXYGEN 1.00
ASTR_FUEL 1.00
ASTR_ALIVE 1
ASTR_CLASSNAME UACS\Astronauts\SPACE1999-FD
STATUS Orbiting Moon
RPOS 159219.350 -1735136.400 -36772.184
RVEL 0.1233 0.0049 0.3011
AROT 4.648 -47.428 172.143
RCSMODE 0
AFCMODE 7
PRPLEVEL 0:0.974632
IDS 0:8 100 1:588 10
NAVFREQ 0 0
XPDR 468
GEAR 0 0.0000
BUGHATCH -2147483424 0.0000
BUG 1743151210 0.0000
DOOR 1 1.0000
DOOR1 0 0.0000
DOOR4 1 1.0000
END
AstronautRadwan1:UACS\Astronauts\Xemured
STATUS Landed Moon
POS -0.0426306 -85.9662445
HEADING 64.67
ALT 0.910
AROT 1.908 -25.310 175.537
RCSMODE 0
AFCMODE 7
PRPLEVEL 0:1.000000 1:0.988313
NAVFREQ 0 0
NAME Abdullah Radwan
ROLE commander
MASS 70.000000
ALIVE 1
SUIT_ON 1
HUD_MODE 1
HEADLIGHT 0
END
END_SHIPS

You can't scroll through airlocks in the nearest HUD mode. If you want to scroll, go to the vessel information mode.

Excellent news!


Maybe I can make a generic cockpit?


Camera offset is fine! hide the msh in cockpit view is exactly what I meant!


It's not height or elevation thats the problem. If you look here https://www.orbiter-forum.com/threads/hdu-dsh-z2-uacs-major-tom-at-solace-base.41621/ you'll see what I mean. I was thinking more on the fly adjusting altitude above ground (as in .scn alt)


Yes please, I made new textures and manually changed a material value in a msh file, will upload. Can also do some of the other objects.

When one dies, runs out of air, could one make the astronaut lie down?
when running it takes a long time to stop, maybe to much momentum?
Haven't tried yet but can one attach more than one station breathing attachment to a vessel?

Thanks again!

If you can make a good 3D cockpit, I would be very happy to include it with UACS.

I will add an option to hide astronaut mesh when inside the cockpit in the next release.

I understand what's the issue now. I think the best solution is to simply avoid elevating the ground of a base. Any other solution would be either incomplete (doesn't work universally) or too expensive performance wise.

If I make the astronaut height modifiable in the scenario (or you modify the astronaut configuration file), it won't be possible to mix different bases while having the altitude set correctly. If you want to transfer from a base to another, you have to manually edit the height before entering the other base.

If I added an altitude parameter in the base itself, the astronaut would have to loop through all UACS modules every frame, check which one is nearest, check its altitude, and set its height accordingly.

A possible solution to make it possible to change the astronaut height in the astronaut itself by adding a shortcut. It's not very convenient nor realistic, but's it's the most feasible solution. Honestly, I think it's just better to have the base on ground level.

I will look into the files you attached and get back to you.

I will see what I can do regarding making the astronaut laying down when dead. I believe that will require additional parameters in the config file to set the side height correctly, so it may not be worth the complexity for it.

As for taking a long time to stop, it's not due to the momentum. The astronaut calculates an acceleration rate and a deceleration rate (less than based on the planet gravity. The stronger the gravity, the higher the values. You can see the actual calculations in the code, but it's generally linearly proportional to the plant gravity. If the gravity is 1/6th that of Earth, the rates are 1/6th that of Earth. I am open to any suggestions of that regard, but I think this is realistic enough. You can disable this altogether by disabling the enhanced movements option in UACS configuration file.

You can't add more than one resource and/or breathable attachment point to a vessel. You can only add a one, and it must be the last attachment point. This is done to improve performance. There is no need to add more than one, since the attachment point position isn't taken into account when calculating the distance to that vessel. If it's in the drainage range, it will be drained from.

 

[Abdullah Radwan]

A question for everyone: Should I compile UACS with /MT instead of /MD? I am mainly concerned about compatibility with other libraries.

 

[gattispilot]

I am not sure about the Libraries. I can't add XR sound or Orbitersound 5.0 due to that.

 

[gattispilot]

Still trying to get vessels with multiple airlocks to work and based off animation.

Here It looks like the guy should exit right aft airlock as it is open? but he exits the left front which is open.

How to set the airlocks close by key. so if airlock 1 is selected press a key and airlock is open>

You can't scroll through airlocks in the nearest HUD mode. If you want to scroll, go to the vessel information mode.

Not sure about this?

 

[Buck Rogers]

@gattipilot: I found it a little confusing at first, but there is a logic, there are different modes where you can only do certain things, keep cycling through with ALT+M, on one of the menus it should work?

@Abdullah Radwan:
Libraries: Can't say, but max compatibility would be good
Astronaut Alt: Too complicated is not good, not a vital issue and can be addressed later. (I thought that because "movement" is a position hack one could offset it easily like adjustig Alt in .scn)
Prone dead: I'd keep it simple, for the astronaut to work the .cfg height (above ground) must = COG = centre of mesh, so pitch -90 and Alt - COG? (will be half underground, but your dead after all?)
Stopping time: I thought it might be connected to grav. etc., thought this would effect top speed and endurance more, just "feels" a little wierd, but no biggy.
Attach: Reason I asked is I wanted to have different compartments (seperated) in the same vessel, if not viable I'll look for a work around.

 

[Boxx]

A question for everyone: Should I compile UACS with /MT instead of /MD? I am mainly concerned about compatibility with other libraries.

/MT is Multithread /MD is DLL multithread => what's the difference?! I always use /MD(+debug) but maybe I do a mistake...

 

[n72.75]

/MT is Multithread /MD is DLL multithread => what's the difference?! I always use /MD(+debug) but maybe I do a mistake...

/MD -> Links to MSVCRT.lib
/MT -> Links to LIBCMT.lib

/MD, -MT, -LD (Use Run-Time Library)

Learn more about: /MD, /MT, /LD (Use Run-Time Library)

learn.microsoft.com

 

[gattispilot]

So still confused on opening/closing airlocks, and selecting airlocks.

Airlocks/open closed based off animation. If the Door_proc>=1 door open then airlock is open else airlock is closed.

BUt how to it if no animation? scroll thru airlocks and press a key and now airlock is open or closed. Not sure on the code.

On the ALt M menu. Is what ever airlock you select the one the eva will happen from?

 

[nbcfrosty]

/MD -> Links to MSVCRT.lib
/MT -> Links to LIBCMT.lib

/MD, -MT, -LD (Use Run-Time Library)

Learn more about: /MD, /MT, /LD (Use Run-Time Library)

learn.microsoft.com

Linking with libcmt statically links the c runtime, whereas /md links it dynamically.

As such /Mt is better as it doesn't require any other dependencies.

 

[Buck Rogers]

UACS Astronaut VC WIP

Biggest problems were, clipping, but I've pretty much solved that, and back lighting, unless there's a magic solution than one will have to make a compromise.
It's quite hard to demonstrate a VC helmet in pictures so I've made a direct comparison with the good old original UMMU.
Without/with gold visor, and with max glare (sun at your back).



How much tint/glare is wished/tolerable is up to debate, too little, can't see an effect, or, too much, can't see anything, let me know what you think, or what the general consensus is.
If approved I'll finish the mesh and retexture so it's hopefully easily reskinable.