Bug description: The Pneumatic debugger errors will not clear until I restart the sim. So it’s a long process to figure out if you solved the issue. Also there is a few errors messages that does not clearly state the exact issue or how to resolve it.
I can’t remember the exact messages!
Negative energy in component’s input.
Simvar depreciated ???
My main large code does not have this error but every time I try to build a simple project for testing I get this error when I clearly have the valves circuit ID’s set to 1 thru 3.
Attempting to access valve with an invalid ID. Should be between 1 and 3, is 0.
Attempting to access area with an invalid ID. Should be between 1 and 1, is 0.
I resolved why I am getting this error.
Attempting to access valve with an invalid ID. Should be between 1 and 3, is 0.
This happens if you have logic trying to set a valve that does not exist. Should had figured that out yesterday.
Restarting the sim to clear old errors still stands. But I figured out after you click build all, any old errors, will re appear first, then fresh errors. Clicking clear errors will clear the old errors and only the current ones will show.
I have confirmed Simvar depreciated or something like that will not clear until a restart!
I also found the fan does not work and toggles back and forth. Maybe that is why it’s in the SDK drawing but left out of the code due to an issue.
Another issue is the AmbientBleedStaticFlow for an area. The 737 left this out as it’s required. But I find that 0.0001 is the smallest value before it stops reading the value. And it seems that 0.1 or less is the same rate, which is too fast to leak in ambient temps from outside with the doors closed. I would prefer to just use no value but have the opening of windows or doors quickly balance out the temps like it does for the pressure.
I have logged a bug for the error/warning messages in the console that keep being displayed.
Regarding the FAN: do you have a minimal sample that reproduces the issue?
The same request applies to the SIMVAR_PNEUMATICS_JUNCTION_OPENING_STATUS error.
As for the setting, you can set it to 0. Unless there’s a bug in this which I couldn’t reproduce we’ll also need a sample that demonstrates the behavior on your side.
The fan issue can be tested from the B737. In the debugger there is a fan on the OutFlow Valve and it never turns on and is always off. Also there SDK shows fans on the return to the mixer and these are not in the code at all since you can’t turn them on. Seems to flicker if you try.
I take back what I said about wanting to use zero. it should change rate based on smaller values this way the ambient temp does not enter into the cabin as soon as you stop the cool air.
————————————————————————————–
I’ll share a clean copy of our Lear 35 pneumatic setup shortly (about a day). In the meantime, I wanted to outline some limitations we’ve run into specifically because this aircraft doesn’t use packs. The new Pneumatic system is fantastic—exactly how future sim systems should be coded—and we’d love to see a few additional options over time so no-pack aircraft are fully covered.
Bugs & current limitations (no-packs aircraft)
Packs assumed/required: The current Pneumatic framework presumes aircraft have “packs.” For aircraft like the Lear 35 that do not, this creates two issues:
Ground cooling gap: No native way to cool the cabin during taxi/ground ops without packs.
In-flight cooling path: We can cool in the air via ram air, but there isn’t a straightforward no-pack path exposed, so it’s awkward to model.
See “Requested future options” below for the two solutions that would cover both cases.
Openings only affect pressure (not temperature): “Opening indices/names” (doors/windows) currently equalize pressurization but don’t also blend cabin temperature toward ambient. That makes openings feel incomplete—pressure moves realistically, temperature does not.
Trim Air
Turning off the trim air only (hot air valve) is not stopping the hot air coming from the engines to the area and the packs can still warm up the area. Only turning of both the trim air and packs works. Seems illogical.
Requested future options & improvements
Add a Ram-Air Mixing Box path (no compression cycle):
An official component/flag for a standard ram-air mixing box that blends ambient air with hot air to regulate cabin temperature without a pack/compression cycle—covering aircraft that cool in flight purely via ram air at speed/altitude.
Add a DC-powered refrigerant A/C unit (ground cooling):
Support a separate, DC-powered refrigerant air conditioner (as on the Lear 35) used on the ground/taxi to keep the cabin cool before takeoff.
Needs its own dedicated circuit (additional pneumatics/electrical-tied entry) with on/off control, electrical load, and thermal effect on selected cabin areas.
Tie openings to temperature blending (not just pressure):
When a door/window opens, optionally accelerate ambient-to-cabin temperature blending.
Scaled by opening size/type: Doors produce a stronger, faster blend; windows a smaller effect.
Respect active HVAC: Do not force full equalization if heaters or the DC A/C are still outputting hot/cold air—allow a residual offset based on active flows, but trend cabin temp meaningfully toward ambient.
Config hooks & QoL controls:
A simple no-pack aircraft flag that enables the ram-air path.
Per-area targets (cockpit/cabin) for both ram-air and DC A/C.
Tunables for blend rates, flow caps, and HVAC vs. opening priority to match real-aircraft behavior.
Valves — springs, pressure, and electrical behavior
◦ Current limitation: In the stock pneumatic valve logic, the valve position only changes when electrical power is available. You can still toggle modes, but that doesn’t move the valve—so position changes effectively require electrical power.
◦ Pressure + spring option: Add a setting for pressure-actuated, spring-returned valves. Example: Pressure-to-Open (pressure holds the valve open; loss of pressure lets the spring drive it closed). This covers simple Open/Closed behavior without relying on electrical power.
◦ Electrical + spring options: Support selectable spring-return behaviors for powered actuation: Power-to-Open (depowered-to-Close) and Power-to-Close (depowered-to-Open). On power loss, the spring drives the valve to the defined fail position.
◦ Bonus — Emergency bypass valve: Add a two-route diverter valve that sends hot bleed air directly to the cabin when in EMERGENCY. Triggers: (1) pilot-selected Emergency Bleed switch (electrical command), (2) automatic on cabin altitude exceeding a threshold (developer-set), and (3) fail-safe to emergency on loss of DC power, loss of bleed-solenoid control, or loss of source pressure (spring drives the valve). Include a reset workflow (descend below the recovery altitude, then cycle bleed switches OFF→ON to return to normal). Note: thresholds and exact interlocks can be custom-coded by the developer; the core feature is the valve redirecting one line or the other, not both.
Pressurization air system (nice-to-have)
◦ Add an optional pressurization “Rate” control/knob: Not strictly required, but many aircraft include a user-adjustable cabin climb/descent rate. Exposing a rate setpoint (with matching SimVar/event) would let devs model typical behaviors more accurately while remaining compatible with existing targets and schedules.
As a temporary workaround, we simulated a no-pack path by clamping our LVAR cabin-temp knob so it can only tune down to the current ambient low, effectively behaving like a one-stage ram-air mixing box instead of a pack. For ground cooling (no engines, no APU available), we repurposed the APU logic purely as a DC-motor stand-in—keeping it “spinning” in the background with RPM only (no electrical tie-in), then toggling bleed/pack logic as needed to drive a refrigerant A/C effect. We also bypassed the normal engine → hot-air valve → mixer path and routed the cooling directly to the cabin, as in the real airplane. We’re still refining this approach and will share our current project shortly; I’ll also attach an image from our graph editor so you can see exactly how this workaround is wired.
Another helpful feature for developers is a graph editor—this makes setup much easier, even with a custom tool.
The SDK is also missing details about the new engine variables for bleed-air PSI and kPa, which are important for tuning against area sizes. We also found the B737 area sizes don’t match cubic meters, so we adopted a practical scale: take cubic feet and divide by 3.5—this has produced good results.
Another bug I found is engine 2 is not displaying the psi correctly in the debugger. And both engines when off are showing 12.5 psi when powered off rather than dropping to zero.
Found another issue. Outlet components have a variable to show the temperature. These temps will increase but after cutting them off using a valve the temp stops rising but never drops in temp. So hard to simulate the required temperature for the windshield deice for example that requires hot air. Will be nice to see these drop temperature once we close the valve over time.
In the Lear you can over heat when using windshield deice from low altitude and semi freezing weather. So the real switch allows you to adjust the valve position to get less hot air. This will be nice to simulate. Hope to see this fixed or help on how to set this up properly.
