Pils

Hi Tom/Jan, I had originally planned to post this as a bug report, but on second thoughts it occurred to me that the current behaviour may be a deliberate choice as a "sim-ism"/affordance to limited hardware/whatever. On the other hand this might be a regression in V1.5, it's been too long since I was using V1.3, as previously mentioned. Feel free to file this as you see fit. I'll happily be corrected by y'all on any of this, but from what I've been told I believe this is roughly how the reverse thrust levers work irl: 1. The reverse thrust levers are mechanically "locked out" from being moved while the forward thrust levers are above idle; 2. When the reverse thrust lever is pulled up to the deploy/idle position, the reverser "door" is unlocked and starts translating (not sure the exact lever angle this happens); 3. There's an interlock at around 1/3rd of the reverse thrust lever travel that prevents the lever from being pulled any further (above idle) until the door is translated (I read somewhere that the interlock disengages at 60% translation, but that could well be wrong, I'm sure it's in some technical manual y'all have access to); I did some testing on V1.5 with the basic "toggle reverse" command, which by default is assigned to Shift+/, and from what I can see (without going into datarefs), the current behaviour is as follows: 1. If forward thrust levers are not at idle and reverse is toggled as above, the forward levers quickly move to idle, and it seems the reverse thrust levers move to a position that corresponds to the same relative position in the range of the reverse thrust levers as the forward thrust levers were at the time of activation. For example, if forward thrust levers are at 50% of their range and reverse is toggled then the reverse thrust levers move to 50% of their animation range (ignoring the fact that the lower third or so of their range is "below" the interlock). 2. If reverse is toggled while the forward thrust levers are at idle, the doors translate and the unlocked lights illuminate amber, however the reverse thrust levers do not move. 3. While the doors are still translating, reverse thrust can be increased above idle (for example by moving the throttle axes I have on my hardware throttle), with the corresponding relative movement of the reverse thrust levers in the 3D cockpit. Having said all that (sorry it's a long post!), my suggestion is to enhance the simulation of the reverse thrust system as follows: 1. Inhibit reverse thrust activation, hence movement of reverse thrust levers above "stowed" position, unless forward thrust levers are at idle; 2. Limit reverse thrust to idle, hence movement of reverse thrust levers past the interlock, until doors are sufficiently translated; 3. Animate the reverse thrust levers in the 3D cockpit to reflect the state of the system. Having worked with Toto on the Challenger's throttle behaviour I understand the way X-Plane handles reverse thrust can be a bit wacky under the hood (and there's like at least 4 different ways for the user to control it). And I'm not sure how much of the current behaviour is Laminar default, etc. So I appreciate it might not be the easiest thing to override from an add-on. Thanks a lot for your consideration. -Pils

Hi @tkyler, Thanks for adding the "show_settings_window" command so I can disable the mouse-over popup (yay for user choice!). It would be great if this command also let me close the window when it's open. Alternatively a new "toggle settings window" command would work too. TIA!

Probably one for @Litjan... When doing a selected/assumed temperature derate I see the N1 limit display shows R-TO (and I assume it would also show R-CLB), but I was wondering how come the fixed derate selections (e.g. 18.5K TO-1) aren't reflected on the display? I guess these weren't used often? Also, was there a manual way to set the N1% limit from the FMS? Cheers.

I gotcha. Sorry if I wasn’t clear. Was trying to say my personal MVP for a P2F variant would be windows plugged, cargo door added, and seats removed. Makes sense to me. There’s a lot of work there, no time to waste.

Plugged windows, cargo door, and removal of all the interior (seats, etc.) would work as a “package freighter”. ¯\_(ツ)_/¯

You want the other one at the top

FWIW, we see this a lot with crash reports from Challenger users, it’s always been nothing but a coincidence/red herring. Weather updates happen regularly, so you’ll see this is basically everyone’s log.

This is also a known issue, thanks!

Appreciate that but please keep everything to a single thread per issue, thanks. I think it was also made clear that the belief of the developers that this is a sim problem and should be reported to Laminar Research. https://www.x-plane.com/x-plane-bug-report-form/

Please post Log.txt to this existing thread

Try downloading the installer again. (This has to be done every update, and sometimes multiple times if there’s fixes.)

The manual is outdated. You use the default weight and balance interface for now.

No, it won’t. It’ll be announced loudly if/when that happens.

When putting nav aid TLA (in Scotland) into FIX INFO page the disambiguation page shows negative values for the "West" part of the Lat/Lon, which doesn't seem right. See attached.

sim/flight_controls/rudder_trim_left & _right

A couple of other thoughts for when this thread is referred back to again... I think the manipulator for the landing light gang bar (whatever it's called) should be able to be "held" down with mouse (and command). And it would be nice if the CDU buttons were animated and had a higher texture resolution for the labels. (I've already mentioned the panel texture resolution in another thread.) Also, the TO/GA buttons and A/T disconnect buttons. I know it seems small but for me it's always the little attention to detail things that delight. Thanks!

Hi Tom/Jan/Cam, I noticed this when reinstalling V1.5, but also now when installing V1.5.1, each time after loading into the aircraft for the first time after the update/reinstall all the preferences in the IXEG Main Settings are reset to defaults. It looks like the prefs are being saved to a file called 733_TK_IXEG_prefs.txt, however this file is being removed during the uninstall process, while the (no longer used?) IXEG_user_prefs.txt file is being preserved. (A 733_TK_IXEG_prefs.txt dated September ‎15, ‎2023 is included in the install package.) Thanks.

I'm seeing the same @Cameron (also a couple of extra empty directories).

If you haven’t received a discount code in your email you need to get in touch with support. You’re probably not subscribed to the announcements.

Yes, do the the reinstall. There's no UI for this particular check.

I'm honestly not sure, it's been too long since I was last using the plane in 11, I'm sorry to admit. I'm sure that would be greatly appreciated by the sim hardware-loving community. Quite the undertaking, but it'll be worth it. Another one to add to your list for consideration... sim/annunciator/clear_master_caution. Cheers!

One other quick note: Not really a "bug" per se, but I also think it would be good for consistency's sake to have custom IXEG autopilot commands for the IAS/MACH speed knob.

Log?

Hi Tom/Jan, I was doing some basic hardware integration with V1.5 (specifically using @VirtualCPT's excellent XMidiCtrl), and I noticed some results that may be considered bugs and/or misbehaviours, as follows: 1. Custom autopilot "toggle" commands leave 3D cockpit buttons depressed Current behaviour: After binding custom command, e.g. ixeg/733/autopilot/HDG_mode_toggle for heading select, to keyboard key, when the key is pressed (command phase “begin”) the 3D cockpit button for HDG SEL is depressed and the mode is activated, as shown by the lamps and on the FMA. When key is released (command phase "end"), 3D cockpit button stays depressed, see below: Expected behaviour: Using custom commands should have same effect as using mouse button on 3D cockpit manipulator, i.e. after releasing key, 3D cockpit button is returned to normal "out" position. Also, while key is held (command phase "continue"), 3D cockpit button stays depressed. 2. Using default autopilot "up"/"down" commands does not animate MCP controls and no sound is played Current behaviour: After binding default autopilot command, e.g. sim/autopilot/heading_up (or airspeed_up, etc.), to keyboard key, when the key is pressed the heading value in the "window" is changed, however the corresponding 3D cockpit knob on the MCP does not rotate, and no sound is played. Same applies to course knobs when using default "obs1" or "copilot_obs2" radio commands (there's no custom ones that I could find), and surprisingly the custom "HDG_bug" IXEG autopilot commands. (And possibly others?) Expected behaviour: Using default commands should have the same effect as using mouse on 3D cockpit manipulators, i.e. value changes in "window", knob rotates, sound plays. 3. Default vertical speed commands have no effect Current behaviour: After binding default autopilot commands for vertical speed, e.g. sim/autopilot/vertical_speed_up, to keyboard key, when key is pressed the vertical speed does not change, nor does the 3D cockpit wheel animate or play sounds. Expected behaviour: See #2 above. For context, the default autopilot commands are often the first thing people will try to bind, and are also part of default or hardcoded configurations for some hardware, e.g. Saitek panels. Additionally, they have the advantage (over the custom ones of many add-ons) of "auto-repeating" when "held". Any questions please let me know. Thanks!

I moved the post to the Bug Reports forum. You can post here in the future.