skiselkov

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.

NEAREST APTS MIN RWY is applied to the NEAREST APTS subpage of DIRECT-TO and the magenta airports displayed on the MFD map when in MAP SYMBOLS > NEAREST APTS is enabled. The "APTS" function just shows all airports with any runways. Note in the screenshot below that the magenta airports are the "NEAREST APTS" (to which the runway length filter is applied). The blue ones are all the other ones ("APTS"). Why the XLF<whatever> airports have a runway defined, I cannot say, but according to the scenery data, they most definitely have one. In case of XLF000D, for example, there's a 986 ft runway defined. In short, working as intended, X-Plane says there's a runway there, so we show it.

Can you clarify which nav sources are permissible on the non-steering side? Is there any checking for the active nav source at all? Or is it entirely irrelevant? We're essentially trying to reverse engineer's Collins' coding decisions here. It seemed to me that on-side FMS would be the safest/most sensible option. The other options are: any FMS source, or literally any source. Which options have you tested?

We can commit to at least 12 months of support for X-Plane 11 after X-Plane 12 goes final. Important caveat: new features which depend on X-Plane 12 functionality will not be backported. That doesn't mean no new features will be developed for XP11. Things that are entirely straightforward, like the medevac cabin layout, will get backported. But things like the windshield rain effects, or weather radar, probably will not.

Hey, this unfortunately seems like some kind of problem with plugin rendering when running on Mesa in Vulkan mode. I suspect the GL->Vulkan bridge is somehow borked on Mesa and it's just not sending over the pixels we render. For the time being, I suggest remaining on XP11 in OpenGL mode. Mesa's GL driver is pretty great, and should give you quite good performance. I will follow up with Laminar & the Mesa driver team, to see if we can nail down what's happening and how to work around/fix it. I can't make promises as yet, but as a fellow Linux myself, I can tell you I'll give it a pretty hard try.

Fixed in build v1.7-beta39.

You've run into a very rare corner case where a compiler bug broke the CL650 on macOS. We have a workaround for this in the v1.7 beta version, which is available to any existing CL650 owners. I'll send you an unlock code for the beta in a direct message.

We probably don't exhibit this exact quirk/bug. I've got the system coded so it smoothly transitions to geometric vertical guidance only when the approach is an SBAS approach and is being flown in SBAS mode vertical guidance (selected using the mode switch on the ARR DATA page). If geometric vertical guidance is enabled, then from 5NM inbound to the FAF, I start blending the baro-VNAV with geometric guidance, until at the FAF it becomes purely geometric. As usual, Collins doesn't detail the exact bugs of their code in their user manuals, and so in absence of information to the contrary, I made it do the "smart" thing. Perhaps I should "fix" this and make it do the dumb thing? I'll give the docs you linked a read and think about it.

Thank you for the report, filed under issue #3211. Bug root-caused & fixed for v1.7.

Having had a look at your video, there doesn't seem to be anything obviously wrong you're doing and I cannot reproduce the behavior you've got there. It might be a bug in v1.5 that I've since fixed. Retest with v1.6 when it's out.

Uhm, not seeing any videos. Try uploading them to Youtube.

Please record a video of your test flight so we can see what you're doing. Your broad description doesn't seem to suggest you're doing anything wrong, so seeing the exact steps might help narrow the cause down.

Hey there, I think you're fighting another issue here. If you're using yoke-linked steering, that's X-Plane only giving you some very limited steering authority. I'd recommend using one of your axes on the throttle quad as a rudder. With a rudder axis bound, you will get the full +-20° steering authority on the nose wheel, which combined with the TBM's short wheelbase will give you plenty of steering authority even around very tight spaces. For brakes, just using the regular 'B' key (brake effort regular) will provide sufficient braking during a landing or speed control. In absence of a brake axis, the system simulates gradual application of the brakes on a 'B' keypress, so you can "pulse" the key to get partial braking. It won't be as smooth as a true axis, but it won't slam on the brakes with full force right away.

Added support in v1.6

Please attach the saved FMS flight plan file. You'll find it under Output/CL650/airframes/<airframe-UUID>/avionics/nvram/FMC_pilot_routes. Otherwise I cannot reproduce this.

Ok, this is the thing that explains it. Outdated magvar measurement. As you can see below, the IGRF magnetic model agrees that in 1980 the magnetic variation at the VOR was indeed 4 degrees east: