intelfx

Is it described in maintenance documentation or something else that I don't have access to? The FMS Operator's Guide only says this:

Since a week or so ago, VATSIM rules were changed to allow more than one ATIS station to be manned by a single controller. Some are using this new rule to provide separate departure and arrival ATISes, using position callsigns <facility>_D_ATIS and <facility>_A_ATIS. They do not seem to be picked up by Challenger's datalink implementation. The feature request is to support these new callsigns in the Challenger's VATSIM ATIS datalink implementation and wire them up to the "SERVICE TYPE" selector on the "ATIS RQ" screen. Note that VATSIM controllers are not required to provide multiple ATISes, even at the facilities which have separate departure/arrival D-ATIS IRL, so it probably should support both position names transparently.

If you arm NAV and VNAV and subsequently give speed control to FMC (magenta speed bug) while on the ground, OR in the air if the magenta speed bug is limited by Vfe, then doing any of the following: turning the HDG preselector turning the ALT preselector taking off ...disengages VNAV speed control and reverts the speed bug to blue.

Just wanted to make sure it's logged.

The cabin lights switch ("CABIN" in the "MISC LTS" group) on the the overhead panel is nonfunctional:

(cross-posting from a duplicate topic) Seeing as this has not been fixed so far, I made a workaround in form of a modified checklists.xml where all F/O actions are converted to appropriate F/O checks: https://github.com/intelfx/hotstart-cl650-checklists/tree/auto-fo When these modified checklists are used, F/O will not act on its own, but watch your actions and advance checklists as you do them.

Seeing as this has not been fixed so far, I've made a workaround in form of a modified checklists.xml where all F/O actions are converted to appropriate F/O checks: https://github.com/intelfx/hotstart-cl650-checklists/tree/auto-fo When these modified checklists are used, F/O will not act on its own, but watch your actions and advance checklists as you perform them.

X-Plane reliably experiences a CTD after 30 seconds or so after reloading a specific saved state (latest for airframe 492ee3fe798e08542851f8ce in the attached archive). In case it's relevant for some reason, freeware KBTV scenery from x-plane.org forums was installed. Note: I trimmed irrelevant state saves from the airframe archive because the archive could not be uploaded otherwise; I did not adjust airframes.db accordingly. Log.txt airframes.zip

Raw reproduction steps (by memory; I'll refine it further once I land): KJFK-CYYZ via GAYEL V374 CFB V270 ULW DCT WOZEE DCT VERKO, uplink from simbrief, activate sec copy to sec, sec legs, delete all down from GAYEL sec fpln, insert Q818 WOZEE activate sec load JFK5 dep, LINNG5 arr (no trans, do not delete discon between WOZEE and LINNG) fly, on departure do a direct GAYEL, at ~20000 ft do a direct WOZEE Log.txt

I'd like to clarify, is this condition persisted in the auto-saved airframe state? When I experience a CTD flying online and then restart the simulator and reload the latest auto-save, the altitude jumps a significant amount suggesting that the CL650 "forgets" that it was connected to online networks earlier in this flight.

Yes, in fact I can reconfigure the hardware to emit "level-triggered" events but I'd prefer not to do that because it would mean I'll have to reflash the HOTAS every time I'm going to fly a different airplane or play a different game.

Currently, the CL650 has just one command to operate the parking brake (CL650/pedestal/park_brake). It would be very helpful for HOTAS owners if there could be separate commands to set and release the parking brakes, which then could be bound to separate positions of a hardware parking brake lever.

Given the FO configuration demonstrated in the attached file, when flying, the FO will automatically read, confirm and advance multiple checklist items in a row, despite actually performing no actions.

It would seem that the automatic FO keeps its own track of the current checklist/item and does not pay attention to the checklist and item that's currently selected on the MFD. If a wrong checklist is started or the current checklist/item is advanced by mistake, even if you re-select the correct checklist/item on the MFD, the FO will continue to track its own position in the checklists and not what is being shown on the MFD right now. Even if it's not a bug, it's unintuitive/unrealistic behavior because I'd expect my co-pilot to actually read stuff from the MFD, instead of going "hey, last item that I read was on the engine shutdown page, so I should insta-switch there and continue reading from that position despite my Captain's inputs".

For anyone else victim to the games that Russia is apparently playing with DNS infrastructure on a national level, you can try adding an override for navcen.uscg.gov into your hosts file (/etc/hosts on Linux, C:\WINDOWS\System32\drivers\etc\hosts on Windows): 206.65.196.29 navcen.uscg.gov (At least in this country, it would seem that the host itself is not being blocked, just the DNS entry is being filtered.)