Nils

The color codings etc should be per-spec but obviously subject to simulator limitations. For instance, X-plane does not give us any information on the vertical distribution of water in clouds, so here we have developed a simple model of our own to avoid showing bright red (= wet) clouds at 25k.

FYI we have a fix for this coming in 1.1 @blackkat002 @djm149

Obviously, the entire knob is rotating the same direction. What you are seeing is a case of stroboscopic effect It will take some experimenting with the knob detent spacing to reduce the effect.

Many thanks. The pitch control regulator needs some fine tuning when tracking Mach number. Some pitch up is to be expected when making the cut over from IAS to Mach since you are effectively starting to climb at lower airspeed, but the regulator was overshooting, particularly in gusty conditions. Will tune and include in future update. @daemotron

Hi, is the IAS to Mach conversion working as intended for you, i.e. does the magenta speed bug stay at your current speed with the click the C/O button? As always, a short video is very useful for us to analyze the problem.

Eyebrow windows as seen from the inside. Some effort was spent at making the shades cast a greenish glow when hit by sunlight.

Hi. What is likely going in is that by removing the reflection texture file, you are causing Gizmo to partially soft-crash, thus preventing an unknown amount of code to be executed and likely also reducing memory use, which in turn gives the Lua garbage collector less work.

Ah what do you know. Note to self: don't answer questions from memory.

Hi Tom, from memory we don't publish any datarefs for those but handle them entirely within our code for the time being.

Please re-read my post above, "_act" means the dataref is used for input. The one's you wish to use for the gear down annunciators are: ixeg/733/gear/gear_left_green_ann ixeg/733/gear/gear_left_red_ann ixeg/733/gear/gear_nose_green_ann ixeg/733/gear/gear_nose_red_ann ixeg/733/gear/gear_right_green_ann ixeg/733/gear/gear_right_red_ann

A mixture if forgotten suffixes, user preferences, integration with other plugins etc.

The dataref names are generally suffixed "_act" for input actuators, "_ann" for annunciator lights and "_ind" for indications like mechanical needles.

The master caution dataref was miscategorized under bleedair datarefs so I appreciate it was hard to find: ixeg/733/bleedair/caution_master_ann Master fire warning dataref is ixeg/733/firewarning/fire_warning_ann We have a lot of output datarefs really - any needle you see move mechanically in the cockpit is driven by a dataref. The same goes for all 'bulb' annuciators. If there's anything you are still missing, I'd like to suggest that interested cockpit builders cooperate on a wish list of things they would like datarefs for and we will see if it can be accomodated in future patches.

The stab trim cut-out switches are working for me. Could you have another try and perhaps give some hints on how to reproduce if they are still not working for you?

To add to Jan's comments, we lowered some of the A/T gains in 1.0.5 after observing some over enthusiastic behaviour in some modes. We probably overdid it a now it is too docile in some regimes. It's a complex regulator to tweak, with different gains depending on AP pitch modes and such so we'll want to be more thorough in testing these adjustments before we make another patch for it.

Thanks @lanmancz@tull@TDPlane for the warming words. Given the geographical dispersion of our team, I think I dare say that there's someone, somewhere in the world working hard on improving the 737 at any given time of the day. 24/7. Seven days of the week. And that is of course not counting the contributions of users supplying bug reports and feature suggestions. Anyway, comments like yours make that work even more motivating and rewarding.

As Jan explained, the X-plane generic instrument toolbox which we used for the fuel gauges certainly can be a handfull to work with. But more importantly the hotfix functionality does not handle artwork updates so this one has to wait for an 'installer patch'.

The real 737 FMC does not have world wide database coverage. To my understanding, any airline will only have data loaded for the relevant region of operations. Loading new or changing database contents apparently involves a pack of floppy disks(!).

Hi, I'd say part bug, part design. Pressing SPEED in this situation shouldn't do anything so that's a glitch (we never thought of trying it). We'll patch that up right away. Regarding your speed situation, the engines are at idle so the only thing you can do to slow down is to 1) extend speedbrakes and 2) level off by selecting LVL CHG and dialing in a lower speed which will make the aircraft pitch up.

Correct. The 737-300 autopilot localizer capture is a two-stage process. When the deviation pointer starts moving and the FMA goes from VOR/LOC ARM to VORLOC, the autopilot will initially command a 30 degree bank towards the dialed in CRS heading. As the localizer deviation pointer comes closer to center, the autopilot switches to commanding the heading that is required to keep the localizer centered, based on deviation error and deviation error rate of change signals.

Short answer: you can't, yet. The current cabin is mostly a placeholder that will get updated both in terms of visuals and functionality in the first "installer patch" sometime in the not too distant future.

Thanks for the report. This bug one creaped into the code that saves the user preferences (which we do when the Tips window is closed, in case the user changed the on-sim start option). It's been sorted for the next hotfix.

Hey all, There's a reason for us messing with the XP sound sliders: 99% of all the 737 sounds are custom and played by our code, but a handful of sounds (like radio alt call-outs) are still in v. 1.0.x using the X-Plane sound engine. If the user would lower the 737 sound settings and then turn up their speaker real loud, they would potentially bust their ears (or soil their shorts) when a default sound (e.g. "four hundred") would play. To avoid this, we make sure the XP sound sliders follow the 737 sound sliders. We plan to move the remaining sounds over to our own code and with that, we won't need to mess with the default sliders anymore. Can't say exactly when this happens but it's a priority item.

Thanks for the report, will see if I can reproduce this based on the gizmo message.

Totally with you on that. We try to strike a balance between getting critical fixes out quick and not introducing new issues in the process but we have tripped a couple of times. If stability is a top priority then you might wanna considering not installing the hotfixes, but I hope we will do a much better job in QA:in those in the future. V 1.0.5 seems to have been well received so far fwiw. The radio alt call-outs issue is not new but appears to be transient on some hardware configs.