skiselkov

While flying on the US west coast I noticed that frequently VNAV constraints on STARs are represented incorrectly in the FMC, necessitating a manual update (which is also kinda buggy, but whatever). For example, KSFO's SERFR2 RNAV STAR should be: SERFR NRRLI, 280/FL200A <- represented correctly on LEGS page WWAVS, 280/19000-15000 <- represented incorrectly as 280/FL190A EPICK, 280/15000-10000 <- represented incorrectly as 280/15000A (remainder of STAR correct) In general, whenever there's a "below" or "above & below" constraint, it gets incorrectly translated to just "above". Moreover, trying to change WWAVS to "/FL190B" just changes it to "/FL190" with no more details (and the FMC attempts to fly through it at exactly FL190). I suspect the FMC is incorrectly decoding the Navigraph database, as it contains these kinds of entries: <Star_Waypoint ID="3"> <Name>WWAVS</Name> <Type>Normal</Type> <Latitude>36.741531</Latitude> <Longitude>-121.894234</Longitude> <Speed>280</Speed> <Altitude>19000</Altitude> <AltitudeCons>15000</AltitudeCons> <AltitudeRestriction>above</AltitudeRestriction> <Flytype>Fly-by</Flytype> <BankLimit>25</BankLimit> <Sp_Turn>Auto</Sp_Turn> </Star_Waypoint> I suspect the FMC is simply interpreting the AltitudeRestriction value as always applying to the Altitude value and ignoring AltitudeCons. The NACO STAR chart for SERFR2 is available here.

I'm hit by this every time I'm instructed by ATC to fly direct to a point, try to execute a step climb or even just modify a VNAV constraint. Any reason why these couldn't be performed in a background thread? It's not like there's a reason why this needs to be performed on the main rendering thread. Most of us have spare CPU cores available, but almost nobody has a CPU fast enough that a one-second computation could all of a sudden be done in an unnoticeable fraction of it.

The IXEG 737 currently has (somewhat) broken handling of the MIC selector on the comm panel, forcing you to use VHF1 for all of your comm needs. To fix that, I've devised a little lua script which follows the selection you make on your audio panel and switches the underlying X-Plane datarefs (sim/cockpit/switches/audio_panel_out). The real audio panel has two rows of controls, the mic selector switching row (only one selected at a time) and the speaker buttons (push-on-push-off). You can listen to multiple COMs simultaneously. This script preserves that behavior. Switching your mic to another VHF radio won't also switch your speaker, so you need to select it by hand. Please note: only the captain's side audio panel is handled. F/O's side is left as-is (i.e. ignored). This script also fixes a number of different aircraft which have a similar bug. The Beech 1900D, Jetstream32, L410 and Bell 407 all feature speaker selection switches, but no (functional) mic selector. There we simply follow the speaker selection. Flip VHF1 off and VHF2 on and your mic will go to VHF2. Flip VHF1 on and VHF2 off and your mic will go to VHF1. The RWDesigns DHC-6 has a mic selector, but it was non-functional. Fixed that as well. mic_fix.lua

Attached is the one I'm using. It's a rather complex setup involving a custom xjoymap script and config, which Xsaitekpanels calls into. This is to provide knob acceleration, so I can spin a knob fast to quickly change its value and then slow down to fine-tune it, just like in the real aircraft. If you don't want to run the custom xjoymap, just replace the xjoymap references in the xsaitekpanels.ini file with the standard commands to change AP settings from X-Plane. Caveats: I've disabled all switchpanel buttons except for the landing gear lever. I find they don't really map that well to the real aircraft. Feel free to reenable them by adding the appropriate lines. Be careful about avionics though, it might mess with the electrics in the aircraft. Also, even if you have the avionics button disabled, you need to keep its knob in the "on" position (and cycle it when you start the sim), otherwise Xsaitekpanels won't turn on any other panel. I've remapped some positions on the multipanel for my convenience. ALT controls right CRS knob and VS controls ALT knob on the MCP. I've changed the TRIM wheel to instead change vertical speed on the MCP, as in the real aircraft. I've changed the REV button on the multipanel to engage LVL CHG, since the 737 classic doesn't have a localizer backcourse roll mode. A/T switch on the multipanel is disabled. The real MCP has this knob on a solenoid that disengages when you press A/T disengage on the throttles. Obviously this can't be done on the multipanel, so I'd rather it doesn't mess with the simulation. ixeg 733 plugins.zip

Wonderful work. I tried it tonight - works, but I'm getting an awful lot of stutter (every 15s, stutters for 1-2s) and the trim going apeshit every 5s (non-stop adjustments by a few degrees of the trim wheel). Any ideas? I'm gonna retest with weather sync turned off.