XR1 Feature/bug with FCS and APU?!

[xlns]

Hello!

Last night, I noticed that while flying XR1, you can adjust elevator trim without APU running in different cockpit setups. Since I don't know how each cockpit view setup is called, allow me to describe. Basically, pressing F9 will cycle through 3 cockpits setups, first being where you see HUD as "physical" object, second would be "virtual" setup where you see HUD content and both MFDs and last being where you see HUD content, MFDs and all other instruments inside cockpit, I'll call it "complete" view. I quoted their names because those are my designation. If you got time to type down, I'd like to know how these are really called, but the point is: from "virtual" view, you can change elevator trim by clicking controls in upper left corner with APU running or not, while in "complete" view, clicking trim control will not work and will give you warning if APU is off. If this is feature, IMNSHO it sux, if it's a bug - it also sux

 

[dbeachy1]

It's a bug. In technical terms the Orbiter core is moving the elevator trim in response to a mouse click in the glass cockpit, so the XR vessel is not informed (i.e., the XR's DLL is not involved). XR vessels do prevent the default Orbiter elevator trim keys (insert/delete) from moving trim if the APU is off by intercepting the keypresses, but I don't see a way offhand to hook the default glass cockpit mouse clicks for the trim. I suppose I could "brute-force it" by adding code to track the elevator trim's state each frame and revert it to its previous state (position) whenever the APU is offline, but TBH that's a pain for such a minor issue.

However, I'll add a note to look into this further for the next XR releases. In the meantime, the workaround is to use the insert/delete keys to move the trim in the glass cockpit instead of clicking with the mouse: the default insert/delete keystrokes are intercepted by the XRs for an APU check. :tiphat: