skiselkov

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.

It is a dataref, but X-Plane treats writing to it as a trigger for the recomputation. So just write something in there (I use the number 1, but technically could be any integer) and X-Plane will perform the cubemap rebuild.

In addition to the link Cam sent you, these documents are also provided inside of the aircraft in a folder called "Documentation" - this is the standard location where most 3rd party aircraft vendors supply documentation. I'd recommend using the online link though, as that often gets updated more rapidly (shipped documentation is only updated when a new release is made). I had a look at the log file you sent and it doesn't appear to show a crash, but rather, an orderly shutdown: That is X-Plane logging that a shutdown of the sim has been commanded by the user. This is then followed by a number of deinit messages and plugins exiting, and finally at the end: A crash would look more like this: We need a log from when the sim crashes (that means closes without you commanding it to), rather than just loading into the main menu and then exiting again. Looking at your XP11 log, it ends in: Are you using Reshade by any chance? Even reusing the same folder for an update/reinstall might still leave bits of Reshade behind and cause issues. I would recommend trying it without reshade first. Moreover, this log doesn't appear to show attempting to load the CL650 at all. Instead: That appears to be somebody else's 3rd party aircraft (at least, I'm not aware of XP11 ever shipping a Piper Aerostar).

Hi Rlondon. Sad to hear it's giving you issues. We'll need the Log.txt file from your X-Plane installation folder when the airplane crashes, otherwise we can't really tell what's going wrong. The walkaround system is fundamentally incompatible with direct VR movement. VR is a completely isolated movement & view control mode that we do not get to control - that's all in X-Plane's hands. About the maximum we can do is provide a few pre-defined positions to which you can "teleport" using a VR controller. There is no facility to define walkable surfaces or walls. As a temporary workaround, the best solution I can offer is to not use VR while moving around the aircraft, then switch to VR when you sit down in the pilot's seat. I will also prepare a vrconfig file for you that will have a few pre-defined teleport locations. Those might help out a little, but it will never feel as fluid as using keyboard & mouse with a conventional display. You will need to be a bit more specific as to what would constitute manuals/documentation to your satisfaction. We supply: An 11-page full-size read & do checklist, and a 4-page compact printable checklist 34-page expanded normal operating procedures document, with explanations and screenshots on what each step is for 16-page FMS primer to get people started on using the FMS for A-to-B flights 30-page aircraft operations reference, including basic operational information, walkaround process, standard flight profiles, operations in icing, steep approaches with special supplements to specific airports and ETOPS guidance 13-page document on the FLEX/MTO feature 15-page manual on how to set up and operate the shared cockpit feature 6-page sample training scenarios + 10 pages of QRH pages pertaining to the shipped training scenarios In all, these total well over 100 pages of documentation. We are always looking for suggestions on improvements, so if you have areas where we should focus, we'd love hear about them. Please note that we cannot provide full AFM, FCOM and QRH docs, as those are proprietary resources which we do not own the copyrights to. However, much of the information in those documents can be found with a bit of googling. Might I suggest search terms such as "smart cockpit challenger 605." Hope this helps.