skiselkov

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.

The oscillation is being caused by a positive feedback with the ground spoilers deploying whenever the ATS commands idle thrust and pulls the thrust levers back to the idle stop. This causes the nose to either drop or rise, which then feeds back into the speed excursion, the ATS changes power settings again, the vertical guidance starts hunting for the VPATH and the whole cycle repeats. Ground spoiler deployment can only happen if: Ground spoiler arming switch is either in AUTO or ARM, and Thrust levers are idle, and Either weight-on-wheels is detected, or wheel spin-up is detected Neither of 3 should theoretically be possible, but seeing a recording of the aircraft from the outside to see if the wheels are spinning in the wheel bins would be helpful. We do tell X-Plane to STOP the wheels from spinning when retracted, but if there's some sort of physics bugs going on inside of X-Plane's wheel logic, then it might be spinning the wheels anyway. This would trigger the PSEU wheel spin-up signal and that might be causing the ground spoiler deployment in flight. I can tell you that for sure we set both the l_brake_add and r_brake_add datarefs to non-zero values to tell X-Plane to NOT DO THAT, but if it is ignoring our input, then it's out of our hands.

Hey there. I did some googling on this and it seems the only fix people have found is to reboot your computer. Really perplexed. Some folks have also suggested this may be due to some overactive antivirus/anti-malware triggering false positives, or in general screwing things up in the app. Wish I could do more, but I suspect a reboot might be your only workaround here.

These are the PDFs that are included with the airplane in the Documentation folder. Reposting them here for users who have not yet bought the model, or who wish to read them on another device. QuickStartGuide.pdf UIGuide.pdf DataRefs+Commands.txt NormalChecklist01.pdf NormalChecklist02.pdf

This has been fixed in v1.8, issue #4138. The issue is being caused by the letter 'T' in the runway identifier, which only occurs at 5 airports in the whole world. As Pilsner noted, you can temporarily work around this by flying into these airports without synthetic vision enabled. The following airports are affected: BGTL, NZFX, NZSP, NZWD and YWKS.