Pnuematic AmbientBleedStaticFlow too strong even at very low values

Version: 1.5.27.0

Frequency: Consistently

Severity: High

Bug description: Modern Pnuematic System!

For area entries, the AmbientBleedStaticFlow setting is very hard to tune for realistic behavior and seems to act like a required field.

In the default 737 pneumatic example, AmbientBleedStaticFlow is not present for the areas, but in practice the sim behaves as if some non-zero value is required. In my own testing:

  • 0.0001 is the smallest value the sim appears to read. Anything below that is ignored.

  • From 0.0001 up to about 0.1, the effective “leak” rate into the cabin feels the same. At these values, ambient temperature leaks into the cabin too quickly for a “doors closed” situation.

With doors closed, I’d like the cabin temperature to stay stable without a noticeable constant ambient leak. Instead, I’d rather have door/window openings be the main driver that quickly equalizes both pressure and temperature with outside air (the way pressure already behaves when an opening is made).

What I’d like to request:

  1. Either:

    • Allow AmbientBleedStaticFlow to be truly optional or zero (no static ambient temperature leak with doors closed),

    • Or expand its usable range so we can set much smaller effective values with finer control over the leak rate.

  2. Ensure that opening doors and windows can be used to quickly balance cabin temperature with ambient air, even if AmbientBleedStaticFlow is very small or zero—matching how openings already affect cabin pressure.

Hello @Flysimware

I have made some tests with the C208, spawning in a cold start configuration.

Its areas have this parameter set to 0.05. Changing the exterior temperature shows the cabin temperature slowly converge towards exterior temperature, as expected. (simrate was 8x here, to demonstrate the behavior)

StaticFlowDefault

I have then tried both setting it explicitly to 0.0, or removing the attribute from the area lines.
The result is the temperature does not change at all regardless of the exterior temperature.

StaticFlowZero

Isn’t this what you observe?

Regarding the possibility to have temperature/pressure equalize based on window/door opening, this seems to be the purpose of these parameters:

Is this something you have tried already?

Regards,
Sylvain

Was that with the doors and windows open or closed? And engines running? Outside air should not effect inside when closed if there is cool air or heat is being added to the cabin.

With doors closed, I’d like the cabin temperature to stay stable without a noticeable constant ambient leak.

Everything closed, engine stopped.

That is what occurs when setting it to 0.0.

Hi @FlyingRaccoon

We also tested the C208 as you suggested, and we noticed that no matter how low we set the value, the temperature changes about one degree Celsius per second, even though that plane isn’t pressurized. In our pressurized aircraft using #AmbientBleedStaticFlow:0.1, we’re seeing a similar rapid temperature change, which is too fast for a sealed cabin scenario. We need it to be slower, especially when we have our own heating or cooling in effect. Also, when we open and close doors in our pressurized setup, we don’t see the expected temp change increase.

Yes… #OpeningNames:MAIN EXIT (name of the interaction points) does nothing. This should rapidly depressurize and balance out the ambient temps.

I’m not sure why I don’t see the same behavior.
Can you please share the latest version of your Learjet package with us?
I’d like to make sure we are looking at the same thing, and that the change we will suggest will work on your aircraft.

Regards,
Sylvain

1 Like

Planning to do this for the last few weeks. Had a hardware failure took time to resolve it. And I also have a failure system not finished and don’t want to send a copy that could trigger failures without you knowing. I will be done in a few days and will send over the latest version and instructions about the failure system.

1 Like

Hello @Flysimware

Just had a look at the latest version of the package you sent and I still do not observe any change in the cabin temperature with AmbientBleedStaticFlow set to 0.
Just to clarify, I am testing in cold start conditions and with manual weather presets, adjusting the temperature through the weather panel.
With your aircraft up and running, with the temperature control knob set to manual, you are still dynamically adjusting the target temperature depending on external conditions so it’s not necessarily easy to test, but still observed that as long as the target temperature doesn’t change, the cabin temperature, once stabilized, does not change with external temperature modifications.

Can you please clarify your testing conditions to make sure we are looking at the same thing?

Regarding the expected equalization when you open the MAIN EXIT interactive point, I found an issue on the way the area OpeningNames is handled.
What you provide is essentially ignored. I will log a bug so this get fixed for SU5.
Note that, if your indices are not subject to changes with merging, you can use OpeningIndices and set it to 2 instead and you’ll see the temperature will now quickly equalize when opening the cabin door.

Regards,
Sylvain

Hi @FlyingRaccoon, thanks for the reply.

Appreciate you confirming the OpeningNames issue — glad you’re logging it as a bug. We’ll use the OpeningIndices workaround for now and look forward to the fix.

Thanks again.

1 Like

Hi @FlyingRaccoon, thanks for the reply.

On AmbientBleedStaticFlow: after more testing, we’ve realized it’s actually crucial/required. Once you stop pressurizing (i.e., remove the pressurization source), the cabin won’t properly unpressurize/equalize without this term, which matches the SDK marking it as required. We’ve found 0.1 (the lowest value) gives a reasonable equalization rate for our use case, and we’re happy with the behavior at that setting. So there is no bug to report on this tag.

Thanks again.

1 Like

Hello @Flysimware

The issue with OpeningNames parameter value being ignored has been fixed in SU5 Beta.

Regards,
Sylvain

1 Like

Hi @FlyingRaccoon

Glad to hear. Will not be able to check as stated in another post we no longer use the modern Pnuematic system for this aircraft project.

Thanks for the update and fix!

1 Like

Hello @FlyingRaccoon,

I am using a pneumatic system on SU5, and it seems OpeningNames parameter does not have any effect on my area temperature. Opening or closing the interactive point does not change anything.

Can you please confirm it should be working? Are there other parameters that could alter the effectiveness of this parameter?

Thanks.

Hello @AZP

I just tested again and I could make it work.
Please open a dedicated bug report and provide us with your package and we’ll have a look.

Regards,
Sylvain

1 Like

This topic has been automatically closed after 60 days of inactivity since it was marked as fixed.

If there is important new information about this same report, you can use the “Request reopen” button below to ask the moderation team to review it again.
For other issues or broader discussion, please open a new topic in the appropriate category.