Project Project Mercury

[BigMac]

Hello all,

I've been working for some time on a revamped Project Mercury which is now probably about at the point that it is ready to release -
it is still very much a work in progress currently, however most of the neccessary functionality to fly a complete mission should be in place.

I've modelled the capsule systems in some detail using the familiarisation manual and other sources for reference where possible, so the result
should (hopefully!) pefrorm fairly close to reality, althought there are several areas in which data wasn't available that had to be filled in with best guesses.
Also provided is the ability to configure failures for many of the modelled components which should impact the spacecraft in a realistic manner.

The capsule modelled is that of Glenn's Frienship-7 used on the MA-6 mission, also included are both the Atlas and Redstone boosters used by the program - these feature a more limited systems/failures model.



Download link can be found here:

https://drive.google.com/file/d/1tuRCj1rvGIrYOOX94wKj9StOTu9veJGx/view?usp=sharing

For documentation, the Meadville Space Center has some great resources available:

Meadville Space Center

In particular the first instance of the familiarisation manual gives a good overview of how things should work.

I fully expect there to be some issues present initally, so any feedback would be much appreciated.

Happy orbiting!

Requirements:

• Orbiter 2016 - local light sources enabled in the launchpad
• Orbiter Sound
• D3D9 client - reflections enabled for periscope rendering
• I would recommend setting a reasonably high ambient light level in the launchpad to allow the horizon to be visible during night

Installation:

• Unzip into your main Orbiter directory
• There have been some reports of the Orbiter_NG.cfg file getting replaced when Orbiter is first run after installation - I am currently looking in to this but in the meantime it is probably a good idea to back up this file prior to launching Orbiter for the first time

Controls:

• A - command abort
• L - start booster launch sequence
• Toggle switches - left click to move left, right click to move right
• Switch guards - left click to open, right click to close
• Rotary switches - left click to rotate clounterclockwise, right click to rotate clockwise
• Dials - hold left click to rotate clounterclockwise, hold right click to rotate clockwise
• Pushbuttons - right click to toggle cover, left click to activate
• Pull tabs/control handles - left click to pull out, right click to push in
• Windows/shades - left click on nearest hinge to open, right click to close
• Mirror - left click to open, right click to close
• Abort handle - double click to command abort

Configuring failures:

A number of the modelled components can be configured to fail to allow off-nominal flights to be simulated. Once a failure occurs a randomly generated value between 0 and 1 is created and used to define the behaviour of the component on failure - this value can also be specified in the scenario file to allow particular events to be defined.

A full list of the components that be configured is listed below:

Spoiler: Mercury Capsule

Batteries/Inverters - on failure will have their outputs multiplied by the generated value
MainBattery1
MainBattery2
MainBattery3
StandbyBattery1
StandbyBattery2
IsolatedBattery
Main250Inverter
Main150Inverter
Standby250Inverter

Solenoids - on failure will remain closed
SuitShutoffValveSolenoid
PitchUpHighSolenoid
PitchDownHighSolenoid
PitchUpLowSolenoid
PitchDownLowSolenoid
RollLeftHighSolenoid
RollRightHighSolenoid
RollLeftLowSolenoid
RollRightLowSolenoid
YawLeftHighSolenoid
YawRightHighSolenoid
YawLeftLowSolenoid
YawRightLowSolenoid
RatePitchUpSolenoid
RatePitchDownSolenoid
RateRollLeftSolenoid
RateRollRightSolenoid
RateYawLeftSolenoid
RateYawRightSolenoid

Sensors - on failure will have their outputs offset by a multiple of the generated value
Altimiter
Variometer
PitchScanner
RollScanner
PitchRateGyro
RollRateGyro
YawRateGyro
GnatPitchRateGyro
GnatRollRateGyro
GnatYawRateGyro
HorizontalGyroMainAxis
HorizontalGyroSecondaryAxis
VerticalGyroMainAxis
VerticalGyroSecondaryAxis
SuitTemperature
CabinTemperature
SteamTemperature
ManualFuelQuantity
AutoFuelQuantity
CabinPressure
SuitPressure
CompressorPressure
LowOxygenPressure
CoolantQuantity
PrimaryOxygenQuantity
SuitOxygenQuantity
SuitHumidity
MainAccelerometer
ImpactSensor
RetroAttitudeSensor
MaxAltitudeSensor
ShutoffValveSensor
EmergencyRateSensorManual
EmergencyRateSensorAuto
DCAmmeter
DCVoltmeter
ACVoltmeter
BoosterThrustSensor

Squibs - on failure will not fire
TowerJettisonSquib
EscapeRocketFireSquib
JettisonRocketFireSquib
AdapterSquib
PosigradeSquib
Retro1
Retro2
Retro3
RetroJettisonSquib
GTriggerSquib
RetroJettisonedSquib
DrogueDeploySquib
AntennaFairingSquib
MainEjectorBagSquib
MainUnreefSquib
LandingBagSquib
InertiaSwitchSquib
EmergLandingBagSquib
SnorkelDoorSquib
InletValveSquib
OutletValveSquib
MainChuteDisconnectSquib
FlotationBagVentingSquib
BalloonAntennaTetherSquib
ManualHeliumSystemValveSquib
BalloonAntennaCoverSquib
FlotationBagSquib
ReserveChuteDisconnectSquib
ReserveChuteEjectorSquib
ReserveChuteDeployGunSquib
MainChuteDisconnectSquib
ReserveChuteDisconnectSquib
ReserveChuteEjectorSquib
WhipAntennaSquib

Valves - will remain locked in their last position on failure
PrimaryReducer
SecondaryReducer
SecondaryToMain
CabinReliefValve
CabinControlValveCutoff
OutflowSnorkelDoor
OutflowValve
CabinControlValve
SuitBleedAneroid
SuitReliefValve
SuitRegulator
EmergencyO2Rate
SuitShutoffValve
AutoHeliumRegulator
ManualHeliumRegulator
ReserveHeliumRegulator
AutoPitchUpHighValve
AutoPitchDownHighValve
AutoYawRightHighValve
AutoYawLeftHighValve
AutoRollRightHighValve
AutoRollLeftHighValve
AutoPitchUpLowValve
AutoPitchDownLowValve
AutoRollRightLowValve
AutoRollLeftValve
AutoYawRightLowValve
AutoYawLeftLowValve
RatePitchUpValve
RatePitchDownValve
RateYawLeftValve
RateYawRightValve
RateRollLeftValve
RateRollRightValve

Thrusters - on failure will have their thrust multipied by the generated value
RCSPitchUp24ManualDirect
RCSPitchDown24ManualDirect
RCSYawRight24ManualDirect
RCSYawLeft24ManualDirect
RCSRollRight6ManualDirect
RCSRollLeft6ManualDirect
RCSPitchUp24Manual
RCSPitchDown24Manual
RCSYawRight24Manual
RCSYawLeft24Manual
RCSRollRight6Manual
RCSRollLeft6Manual
RCSPitchUp24Auto
RCSPitchDown24Auto
RCSYawRight24Auto
RCSYawLeft24Auto
RCSRollRight6Auto
RCSRollLeft6Auto
RCSPitchUp1Auto
RCSPitchDown1Auto
RCSYawRight1Auto
RCSYawLeft1Auto
RCSRollRight1Auto
RCSRollLeft1Auto

Limit switches - on failure will be set closed if value is greater than 0.5, and open if value is less than 0.5
AdapterSeparationLimitSwitch
CapsuleSeparationLimitSwitch
BoosterLimitSwitch
TowerLimitSwitch
RetroPackLimitSwitch
LandingBagLimitSwitch
AntennaFairingLimitSwitch

Fuses - if value is greater than 0.5 position 1 will fail, if less than 0.5 position 2 will fail
FuseEmergCapSepCntrl
SuitFanFuse
EnvrControlFuse
FuseEmergDrogue
FuseEmergMain
FuseReserve
FuseEmergLandingBag
FuseEmerEscapeRocket
FuseEmerTowerJett
FuseEmerTowerSep
FuseTowerSepControl
FusePeriscope
FuseEmergPosigrade
FuseEmerRescueAids
FuseRetroJett
FuseManRetroFire
FuseRetro1
FuseRetro2
FuseRetro3
FuseEmergRetroJett
FuseASCSG
FuseEmergG
FuseEmergRetroSeq

Heat exchangers - on failure will have their heat transfer multipied by the generated value
SuitHeatExchanger
CabinHeatExchanger
SuitFreonHeatExchanger
CabinFreonHeatExchanger

Compressors - on failure will have their mass flow rate multipied by the generated value
CabinFan
Compressor1
Compressor2

Other components - on failure will not function
ASCSCalibrator
RSCSCalibrator
ASCSTorqueController
RSCSPitch
RSCSRoll
RSCSYaw
SatelliteClock

Spoiler: Redstone Booster

Inverters - on failure will have their outputs multiplied by the generated value
Inverter

Solenoids - on failure will remain closed
PressurisationSolenoid

Sensors - on failure will have their outputs offset by a multiple of the generated value
PitchRateGyro
RollRateGyro
YawRateGyro
HorizontalGyroMainAxis
HorizontalGyroSecondaryAxis
VerticalGyroMainAxis
VerticalGyroSecondaryAxis
IntegratingGyro

Valves - will remain locked in their last position on failure
FuelPressValve
LoxPressValve
PeroxidePressValve
FuelRegulator
LoxRegulator
PeroxideRegulator
LoxReliefValve
FuelReliefValve
PumpControlValve
FuelFlowValve
LoxFlowValve

Actuators - on failure will remain in their last position
ActuatorPitch
ActuatorYaw
ActuatorFuelFlow
ActuatorLoxFlow
ActuatorLoxPress
ActuatorFuelPress
ActuatorPeroxidePress

Pumps - on failure will have their pressures multiplied by the generated value
TurboPump

Engines - on failure will have their thrusts multiplied by the generated value
Engine

Spoiler: Atlas Booster

Inverters - on failure will have their outputs multiplied by the generated value
Inverter

Solenoids - on failure will remain closed
PressurisationSolenoid

Sensors - on failure will have their outputs offset by a multiple of the generated value
PitchRateGyro
RollRateGyro
YawRateGyro
HorizontalGyroMainAxis
HorizontalGyroSecondaryAxis
VerticalGyroMainAxis
VerticalGyroSecondaryAxis
IntegratingGyro

Valves - will remain locked in their last position on failure
FuelPressValve
LoxPressValve
VernierFuelPressValve
VernierLoxPressValve
FuelRegulator
LoxRegulator
VernierFuelRegulator
VernierLoxRegulator
LoxReliefValve
FuelReliefValve
CorePumpFuelControlValve
CorePumpLoxControlValve
BoosterPumpFuelControlValve
BoosterPumpLoxControlValve
CoreFuelFlowValve
CoreLoxFlowValve
Booster1FuelFlowValve
Booster1LoxFlowValve
Booster2FuelFlowValve
Booster2LoxFlowValve
Vernier1FuelFlowValve
Vernier1LoxFlowValve
Vernier2FuelFlowValve
Vernier2LoxFlowValve

Actuators - on failure will remain in their last position
ActuatorPitch
ActuatorYaw
ActuatorVernier1
ActuatorVernier2
ActuatorCoreFuelFlow
ActuatorCoreLoxFlow
ActuatorBooster1FuelFlow
ActuatorBooster1LoxFlow
ActuatorBooster2FuelFlow
ActuatorBooster2LoxFlow
ActuatorVernier1FuelFlow
ActuatorVernier1LoxFlow
ActuatorVernier2FuelFlow
ActuatorVernier2LoxFlow
ActuatorLoxPress
ActuatorFuelPress
ActuatorVernierLoxPress
ActuatorVernierFuelPress

Pumps - on failure will have their pressures multiplied by the generated value
CorePump
BoosterPump

Engines - on failure will have their thrusts multiplied by the generated value
CoreMotor
Booster1Motor
Booster2Motor
Vernier1Motor
Vernier2Motor

Failures can be configured by adding the following lines to the scenario file after the rest of the configuration for the vessel:

FAILURE GLOBAL,<Enabled>,<FailureTime>
Will enable/disable failures for all components with the average time to failure being <FailureTime> seconds, e.g.:
FAILURE GLOBAL,1,600 will enable failures with an average failure time of 10 minutes
FAILURE GLOBAL,0 will disable all failures

FAILURE COMPONENT,<ComponentName>,<Enabled>,<FailureTime>
Will enable /disable failue of an individual component with the average time to failure being <FailureTime> seconds, e.g.:
FAILURE COMPONENT,MainBattery1,1,600 will enable failure for the first main battery with an average failure time of 10 minutes
FAILURE COMPONENT,MainBattery1,0 will disable failure of the first main battery

FAILURE COMPONENTTIME,<ComponentName>,<FailureTime>,<FailureValue>
Will enable failure of a particular component with an average time to failure of <FailureTime> seconds, and the value assosciated with the failure being <FailureValue>, e.g.:
FAILURE COMPONENTTIME,MainBattery1,300 will enable failure of the main battery at an average time of 5 minutes with the battery output dropping to a random value on failure
FAILURE COMPONENTTIME,MainBattery1,300,0.5 will enable failure of the main battery at an average time of 5 minutes with the battery output dropping to half it's nominal output on failure

FAILURE COMPONENTABSOLUTE,<ComponentName>,<FailureTime>,<FailureValue>
Will enable failure of a particular component at a specific mission elapsed time, e.g.:
FAILURE COMPONENTABSOLUTE,MainBattery1,120 will enable failure of the main battery 2 minutes in to the mission with the battery output dropping to a random value on failure
FAILURE COMPONENTABSOLUTE,MainBattery1,120,0.5 will enable failure of the main battery 2 minutes in to the mission with the battery output dropping to half it's nominal output on failure

Notes/known issues:

• Some of the systems may be a bit unstable at high time acceleratoions - I would reccomend using no higher than 10x for the time being.
• Given the size of the meshes/textures involved and the number of components modelled performance may not be great depending on your system - there is definitely the potential to impove this
• If you have wind effects enabled in the launchpad the accelerometer may jump around quite a bit during reentry - this just seems to be an artifact of how winds are currently simulated in Orbiter
• On my PC I have an issue with the frame rate dropping substantially during ground contact, however this does not manifest itself on my laptop so it may just be something specific to the system I'm using

A few elements of the control panel are currently non functional:
Right panel:

• Comms switches
• Blood press/programmer fuses
• Excess suit/cabin H20 warning lights
• Retro warn/retro reset warning lights
• Blood pressure start/stop buttons
• O2 flow switch

Left Panel:

• Launch control switch
• Pressure regulator lever
• Low frequency telemetry switch

Periscope:

• Filter handle

Screenshots:

 

[n72.75]

https://imgur.com/bCVeARt

Well that looks incredible! Looking forward to playing with it tonight, when I get home.

 

[indy91]

I've quickly tried MR-3, very impressive. Love the sound effects. I wonder, how does the periscope work using the Orbiter API? Does it just have a different FoV or also a variable view direction which is different from the main window view. I just wonder if you found a solution that can be translated to the sextant/scanning telescope in the Virtual Cockpit of NASSP. I had kind of assumed this wasn't possible in Orbiter without some major hackery

 

[BigMac]

I've quickly tried MR-3, very impressive. Love the sound effects. I wonder, how does the periscope work using the Orbiter API? Does it just have a different FoV or also a variable view direction which is different from the main window view. I just wonder if you found a solution that can be translated to the sextant/scanning telescope in the Virtual Cockpit of NASSP. I had kind of assumed this wasn't possible in Orbiter without some major hackery

The periscope/mirror are implemented using the custom camera functionality of the D3D9 client which allows you to define a camera and blit it's output to a texture. I'm using two cameras, one with a wide FOV for the main periscope area and one with a narrow FOV for the magnified area, both rendering to a separate texture in the VC.
The downside is that this doesn't work with the native graphics client and that the refresh rate can be fairly low, however I'm not sure how else to achieve this kind of effect natively in Orbiter - perhaps someone more knowledgeable can give some pointers.

I think this kind of approach would work for the Apollo sextant, although I've noticed that distant celestial bodies sometimes render a bit strangely which might be a problem.

 

[GLS]

The periscope/mirror are implemented using the custom camera functionality of the D3D9 client which allows you to define a camera and blit it's output to a texture. I'm using two cameras, one with a wide FOV for the main periscope area and one with a narrow FOV for the magnified area, both rendering to a separate texture in the VC.
The downside is that this doesn't work with the native graphics client and that the refresh rate can be fairly low, however I'm not sure how else to achieve this kind of effect natively in Orbiter - perhaps someone more knowledgeable can give some pointers.

I think this kind of approach would work for the Apollo sextant, although I've noticed that distant celestial bodies sometimes render a bit strangely which might be a problem.

I'm pretty sure this isn't possible in MOGE, only with the functions in D3D9. I use them for the CCTV in SSV, and I think the only "issue" with them is that shadows don't show in the image. Other than that they work fine, and allow several views at the same time!
For now a "graceful degradation" solution is needed to handle MOGE, but eventually it will be retired and D3D9 will become the standard, so it should be temporary.

 

[Urwumpe]

For now a "graceful degradation" solution is needed to handle MOGE, but eventually it will be retired and D3D9 will become the standard, so it should be temporary.

I hope we can then also get an general Orbiter API for the many D3D9 specific API functions.

 

[GLS]

I hope we can then also get an general Orbiter API for the many D3D9 specific API functions.

I think that's what has been done in the D3D9 branch.

 

[n72.75]

Some feedback:

Wonderful addon. Very immersive. The visuals are fantastic, and the sound is of a quality I don't think I've ever seen in an Orbiter addon before.

• Something odd happened when I launched Orbiter for the first time after installing it. It appears as though Orbiter deleted the Orbiter_NG.cfg and replaced it with the default. Background: I installed this in my Orbiter Beta install to test first. It appears as though this has happened to a few others too, looking on Discord.
• Something odd seems to happen with long timesteps, either if there is a bit of lag, or with moderate time acceleration (30x). The cabin fan sound will change to a very high-pitched tone, and then a few seconds later Orbiter will abruptly close. Is there an access violation occurring or something memory-unsafe going on there? Because that is the reason Orbiter is closing.

It's obviously completely up to you as you are the author, but have you considered making this project open source?

 

[Mr. Residuals]

Okay, so it looks like I "wake up" to a dark and cold space craft. Essentially, when I leave the sim while I am in-orbit and then open the sim again. My space craft is dark with no power or anything on. The retro-pack and the parachute system is competently gone.

Please refer to the screenshot bellow and the "Issue.txt" file.

 

[BigMac]

Some feedback:

Wonderful addon. Very immersive. The visuals are fantastic, and the sound is of a quality I don't think I've ever seen in an Orbiter addon before.

• Something odd happened when I launched Orbiter for the first time after installing it. It appears as though Orbiter deleted the Orbiter_NG.cfg and replaced it with the default. Background: I installed this in my Orbiter Beta install to test first. It appears as though this has happened to a few others too, looking on Discord.
• Something odd seems to happen with long timesteps, either if there is a bit of lag, or with moderate time acceleration (30x). The cabin fan sound will change to a very high-pitched tone, and then a few seconds later Orbiter will abruptly close. Is there an access violation occurring or something memory-unsafe going on there? Because that is the reason Orbiter is closing.

View attachment 28645

It's obviously completely up to you as you are the author, but have you considered making this project open source?

Thanks for the feedback!

To address the couple of points you've raised:
The Orbiter_NG.cfg getting replaced is a bit of a headscratcher - there's certainly nothing in the code explicitly trying to access or modify that file, so I'm not sure exactly what might be causing this. Probably not significant but my testing was done against a non-beta version of Orbiter 2016 and I haven't tried it yet against the beta.
I'll try and take a proper look this evening and see if I can replicate it locally but for the time being I'll stick a warning in the OP that this might be an issue.
Out of curiosity, does this file only get replaced on the first run with the addon, or is it persistent?

The issue with the long timesteps is probably due to how the fluids are modelled - I've set up a number of pressure vessels/valves to replicate the setup in the capsule, and the flow through these is then simulated. I'm not currently using any numerical integration for the flow through the valves, and given that some of the pressures involved are very high this can lead to some potentially unstable behaviour if the timestep is long enough. I've fudged this somewhat to have the fluids components only be updated at 1x time regardless of the time acceleration used in Orbiter, however this may not protect against lag of stutters in the sim if they are long enough.
For the particular symptoms you are seeing, the high pitched sound is probably the tone assosciated with some of the warning lights coming on once the issue occurs, and Orbiter closing is most likely due to a calculation somewhere breaking down - probably a division by zero.
On my local machine I'm able to see something similar if I bump up the time acceleration high enough, although Orbiter does not close (this may just be because the time steps are small enough not to completely break things).
I think it should be possible to put in place a short term fix for this which I'll try and do later today - long term it would be nice to add some proper numerical integration to the valve flows.

I'd definitely like to make things open source at some point, however I would like to get it in a reasonably stable place first and tidy things up to ease the pain of anyone unfortunate enough to have to look at my code.

 

[BigMac]

Okay, so it looks like I "wake up" to a dark and cold space craft. Essentially, when I leave the sim while I am in-orbit and then open the sim again. My space craft is dark with no power or anything on. The retro-pack and the parachute system is competently gone.

Please refer to the screenshot bellow and the "Issue.txt" file.



View attachment 28647

Thanks for raising that - I'll take a proper look this evening but on first glance it looks like there was a problem saving the config of the systems when you closed the sim, hopefully an easy one for me to fix.

 

[4throck]

Brilliant meshes, really like the rockets with all those small details. The Redstone is a bit too smooth/reflective from certain angles, but that's nitpicking
I found some minor issues testing Mercury-Redstone:
» Redstone rocket has no sound, other sounds play normally
» Wild gyrations while on the main parachute after engaging 10x time acceleration. Returning to normal 1x time they don't cancel out. After landing, the capsule starts to spin faster and faster. (as mentioned probably related to 10x but it points towards some instability that might manifest itself on lower frame rates)
» Droge fall into capsule after the main parachute opens (needs more horizontal speed on jettison I guess)

But again, it's a great addon!

 

[BigMac]

Brilliant meshes, really like the rockets with all those small details. The Redstone is a bit too smooth/reflective from certain angles, but that's nitpicking
I found some minor issues testing Mercury-Redstone:
» Redstone rocket has no sound, other sounds play normally
» Wild gyrations while on the main parachute after engaging 10x time acceleration. Returning to normal 1x time they don't cancel out. After landing, the capsule starts to spin faster and faster. (as mentioned probably related to 10x but it points towards some instability that might manifest itself on lower frame rates)
» Droge fall into capsule after the main parachute opens (needs more horizontal speed on jettison I guess)

But again, it's a great addon!

Thanks a lot!

I was playing around with the new metalness shader for the Redstone which does seem to be a bit too reflective from some angles, however I think it probably looks a bit better than with the default shader. There should be sound, however it is fairly subtle - the astronaut reports generally noted the sound of the booster engines to be fairly muted which is what I've tried to replicate.
I'm going to try and release an update this evening UK time with some fixes for the problems that have been raised so far - I'll definitely include some changes to the stability under the parachute and the drogue separation as part of that.

 

[Lodkins]

Somehow, when i boot up MR-6 in Beta, entire Earth is this grey/black-ish water

so ideas as to what's happening?

 

[Thymo]

So a couple of things I've noticed.

When I turn the suit fan off, I get a CABIN PRESS and O2 QUAN warning. Turning the suit fan on again does not clear this and the fan sound is also way quieter than before.
Is this just my incompetence or does this still need to get implemented?

If I open the external MFD and wiggle it around/resize it I get a consistent CTD. In addition when I have a GUI open and scroll up and down all systems appear to freeze.
At first I though this may be an issue with varying timestep lengths. When are you executing your system code? It should still execute while interacting with GUIs.

It feels like powerstate is only checked at the end of a timestep. Given the following procedure:

1. ASCS AC BUS - Off
2. FANS AC BUS - Off
3. CABIN PRESS Warn audio - Off
4. O2 QUAN Warn audio - Off
5. ASCS AC BUS - Norm
   1. Cabin lights will briefly flicker and turn off

 

[Thymo]

@Lodkins Your orbiter_ng.cfg was probably overwritten by ProjectMercury. I assume you had a split texture dir to use Orbiter2016's textures. You'll need to reapply those.

 

[BigMac]

Somehow, when i boot up MR-6 in Beta, entire Earth is this grey/black-ish water

so ideas as to what's happening?

Would it be possible to post a screenshot?
I haven't tested the addon against the beta, so it's possible that there might be some compatibility issues there.

 

[BigMac]

So a couple of things I've noticed.

When I turn the suit fan off, I get a CABIN PRESS and O2 QUAN warning. Turning the suit fan on again does not clear this and the fan sound is also way quieter than before.
Is this just my incompetence or does this still need to get implemented?

If I open the external MFD and wiggle it around/resize it I get a consistent CTD. In addition when I have a GUI open and scroll up and down all systems appear to freeze.
At first I though this may be an issue with varying timestep lengths. When are you executing your system code? It should still execute while interacting with GUIs.

It feels like powerstate is only checked at the end of a timestep. Given the following procedure:

1. ASCS AC BUS - Off
2. FANS AC BUS - Off
3. CABIN PRESS Warn audio - Off
4. O2 QUAN Warn audio - Off
5. ASCS AC BUS - Norm
   1. Cabin lights will briefly flicker and turn off

I think that the issues with the suit fan are related to the points that n72.75 flagged up earlier - I'm currently working on a fix for this behaviour.

All of the code for the systems is being executed from the prestep/poststep callbacks, so I would think it should still excute with the GUI open - having said that I can replicate the behaviour locally so I'll look in to this.

With the given procedure, the reason that the lights don't come back on is that they are powered from the Fans bus rather than the ASCS one. The flicker is probably the standby inverter briefly kicking in when the ASCS bus is powered up again, so I think this behaviour is mostly correct.

 

[Lodkins]

Would it be possible to post a screenshot?
I haven't tested the addon against the beta, so it's possible that there might be some compatibility issues there.

https://imgur.com/g9HmaWM

 

[BigMac]

https://imgur.com/g9HmaWM

Thanks - I think Thymo is correct about this being related to the config file being overwritten.

Does anyone a bit more knowledgeable about Orbiter know what might cause this file to change without explicitly being asked to?