skiselkov

I can assure the only reason this shows is because the probes are still hot. Possibly because from the last flight you're restoring, they were already overheated and the simulation doesn't cool them off between reloads of the saved state. So if they were very hot before, you reload the flight, they'll still be hot (all of this gets saved into the state file). If you switch off the probe heats and wait about 5-10 minutes, they will come back, rest assured. It just takes them some time to cool off. Testing, the TAT probe hit about 114°C with no wind to cool it off (~386.5 Kelvin in the dataref display there). From there, switching the probes off, it took around 7 minutes to cool off below 60°C, when the indications on the PFD returned.

Thank you for the test case here. I've been able to identify the source of the problem. (It has relatively little to do with SEC FPLN, but that's besides the point.) Before I commit to a fix, I need to map out some of the real avionics behaviors some more, which you might be able to help me with: When exactly does the VPATH intercept happen? Can it happen while you are flying the base leg, or do you have to be pretty well aligned with the final leg before it can capture? Reason I'm asking is that the FMS manual on page 18-21 seems to imply that VPATH will NOT be captured if track angle error exceeds 30°, which would obviously be the case on the base leg (see screenshot). So if you tell me that you can capture VPATH even on base, then we're dealing with yet another case of the manual lying (or missing important details) about what the avionics actually does.

Can you elaborate? In what way is it "stupid?" It should be exactly where you left it. You can also always just save a cold & dark state and reload it every time you want a clean jet set up the way you want it. That's cause you turned on the probe heats while on the ground with no airflow over the (non-aspirated) TAT probe housing. The TAT probe goes "--" once the temperature it reads hits about 70°C. This is behavior reproduced from the real jet. This is also why Bombardier tell you not to rely on the temperature indications on the PFD for PERF INIT and use ATIS or METAR data instead.

Welcome. Let's work on refining the details here. The way you describe it, I don't see why it shouldn't work in the sim already, so there's probably some step you're doing that's missing. Let's build up a specific test case so I can analyze what's going on in detail: which airport what is the original STAR+approach+runway selection in the ACT FPLN what exactly do you have entered in SEC FPLN? exactly where do you switch to HDG/ALT and what are the heading & altitude you fly then the exact sequence of button presses or mode changes you do - when do you activate SEC FPLN, what changes do you perform to the activated flight plan? crucially - what exact sequence of button presses leads to VNAV not activating as you expect it to - what modes do you expect to see? What do you see instead? Basically, I need an almost robotic sequence of steps, so I can repeat them on my machine and see the problematic behavior you're describing. Yeah, this has been on my pile of little things to fix for a while. I know the real avionics should default to inches of mercury rather than hPa, but I figured it's not a big deal for folks using persistent airframes (once changed with an airframe, it sticks).

Hey there. Got this root-caused. Our parser is a bit touchy about the type of whitespace used. You used hard tabs, whereas Laminar only uses regular spaces, and our parser didn't normalize tabs into spaces, so that confused it. The upstream fix is in place, but to make the file work with the version you have in your hands right now, all you need to do is use regular spaces instead of tabs to separate the fields. I've taken the liberty of converting the file you uploaded, so all you need to do is use this one: user_nav.dat

I can assure you, your computer can run even the latest macOS. Don't let Apple win the battle for planned obsolescence:

Your Ubuntu version is too old. You are on Ubuntu 22.04, whereas the C525 requires Ubuntu 24.04 or later. Ubuntu 22.04 sadly lacks some required functionality, so the way forward I would recommend here is to upgrade to Ubuntu 24.04.

Disable Zink and try without, but realistically, the problem is being out of VRAM. That's what's ultimately triggering the SVS code crashing. It simply cannot function if it cannot allocate memory on the GPU to do the 3D rendering. Disabling Zink simply enables the stock OpenGL driver from Nvidia, which will use RAM swapping in cases when you're out of VRAM, at the cost of performance. Might be an acceptable workaround, since the SVS really only operates at 20 fps anyway and is completely disconnected from the sim's rendering, so worst case is you'll get somewhat laggy SVS rendering.

Cannot reproduce. Here's XP12.1.2-b1 with precipitation intensity at about 10% (light), 40% (moderate) and 100% (severe). Seems to be working fine to me:

Good news everyone! NOAA fixed their data, so now the XP11 version should work once again. Of course in a future update I'll make it so this doesn't happen again. But just to show how broken the data that NOAA was giving us was: all altitudes in the encoded data was 0 meters (this is what was causing the crash - we expected an altitude gradient) all temperatures were 0.1°C there was no dew point data all winds were permanently at 226° and 0KT speed Anyway, I'll mark this as solved for now.

For the future, I would recommend following the checklists, where the test procedure and which switches to check is explained in detail:

Check both STALL PROT PUSHER switches are ON (on both the pilot's and copilot's side). Check breakers CB1-N4, CB1-N5 and CB4-C5 are pushed in

You weren't lied to: https://developer.x-plane.com/x-plane-bug-database/?issue=XPD-14673 Status: Fixed, expected in 12.0.8-beta-2 Laminar changed a dataref we were writing to read-only, which triggered an assertion failure (an internal consistency check) and we bailed. That is done on purpose, so problem's aren't just left to silently fester, but are instead detected and fixed. Now you chose to run a beta build of X-Plane. You should know that that means issues can and will crop up. If you want to fly X-Plane for fun, I would suggest keeping two copies installed.

The problem is that Simbrief are constructing certain flight plans in a bad way. They are encoding a fictitious SID transition (using the SIDTRANS line) that doesn't actually exist in the database. In the case of GZO3D, they're encoding the terminating waypoint as if it was a named enroute transition (GZO), which it is not (GZO3D contains no enroute transitions). The file with the SID & STAR would load just fine if they simply left that one line out. The official Laminar .FMS file format specification makes this clear: This will also work fine in countries (such as the US) which design procedures with named transitions - there, encoding the named procedure transition is correct. This was changed by Simbrief, not us. We have a workaround to detect these fictitious transitions in the next update, but it's not in the stable release. As such, for the time being, I would recommend not entering a SID & STAR in the flight plan and simply adding them via DEP/ARR in the airplane after the flight plan is loaded.

AUTO is the normal position. The checklists should make that clear.