Jump to content

intelfx

Members
  • Posts

    27
  • Joined

  • Last visited

Posts posted by intelfx

  1. 6 hours ago, oisin650 said:

    Turning the HDG selector and taking off - sounds like correct behaviour.

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

    Quote

    The PFD reference airspeed bug also returns to the manual setting when the FLC flight director mode is selected by the crew or by the FMS. Other conditions, such as overspeed, can also return the airspeed bug to a manual value.

     

  2. 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.

    Снимок экрана 2022-04-30 005001.png

    718269058_2022-04-30215944.png

    • Like 1
  3. 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.

  4. (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.

  5. 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.

    • Upvote 1
  6. 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

  7. 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

  8. On 1/21/2022 at 5:25 AM, Graeme_77 said:

    Report 2270 (If online, keep temp effects disabled until after landing, even with disconnect)

    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.

  9. 2 minutes ago, Pils said:

    Good request in general. However, does your hardware hold a command when in position? Because “hold brakes max” works fine for me.

    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.

  10. 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".

  11. 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.)

    • Like 1
    • Upvote 2
  12. 17 hours ago, Goran_M said:

    It could very well be the time compression.  Also, check your default X-Plane failures, and make sure they're all listed as "always working"

     

    Yes, of course, I've double checked that the built-in failures were all disabled (i. e. "always working").
    So, I just flew the same route (that I unsuccessfully tried to fly twice yesterday) without time acceleration and the problem did not occur. This is far from hard evidence but it supports the theory.

    So, is it a bug? IOWs, should I expect this to be fixed someday or should I just view this as an inherent limitation and refrain from using time acceleration?

  13. I'm sorry for necroposting, but I have just reproduced this exact bug, can confirm and also provide a possible explanation. It happens when UI scale is not set to 100% (which explains the reproducibility — @robder likely has a high-DPI Retina screen which probably necessitates the use of UI scaling).

    Any chance this could be fixed (along with other bugs that manifest when UI scaling is used)?

  14. (Okay, now I'm embarrassed about the amount of topics I created in recent days, but this one is a serious question.)

    In recent days, I made four simulated flights with TBM900 (not counting various experiments and training — that is, long flights). During all four of these, the TBM900 broke in (almost) the same way.

    Three times (#1, #2 and #4), the engine suddenly caught fire and the crash bar dropped without any intervention on my part. One time (#3), ITT suddenly spiked to 1000°C and continued to raise extremely rapidly through 2500°C, at which point I pulled fuel and ITT started to drop, but unlike the above case, the plane did not lose electric power. In all cases, post-landing inspection revealed broken turbines and combustor.

    I'm not sure what could cause this. I tried to operate the plane according to the checklists found in the FMS and supplementary information found in the real-world TBM900 manual. All of these times the plane was in level flight with engine set up for long range cruise. After the third crash, I surmised this could happen because I operated the plane without inertial separator (and the checklists are vague about whether I should keep it or not after takeoff and climb). However, last time I flew with inertial separator on and the plane has just crashed again.

    The only other nontrivial thing in common between the four crashes is that I used time acceleration, and the plane crashed when it was on.

    Any ideas?

    I'm attaching the logs and airframe state files from the last two failures. The "crash 3" dump was taken a short while after the crash, when I already stabilized the plane for emergency descent and landing. The "crash 4" dump was taken almost immediately (within 1 second) of the autopilot disengage warning sound, with simulator paused.

    Please advise if I can provide any other relevant logs or data.

    TBM900 spontaneous failure.zip

×
×
  • Create New...