Steam Gauge Overhaul

No worries. The upgrade is otherwise brilliant and much appreciated!

All that note means is that the new default state when the transponder is powered on is "ON", instead of standby, as I believe it was before. This is how most transponders in the United States are programmed, after the FAA's guidance changed some number of years ago to recommend conducting ground operations with the transponder activated. I forget who recommended that change in the Baron specifically, but I recall making the change so that the startup state would be consistent across all my aircraft. As for why yours boots into altitude reporting mode, I'm not sure, because I just checked the code, and it's definitely set to "on". If you want to check this on your end, make your own changes, or revert to how the aircraft behaved previously, you can located the "apron.flt" flight configuration file for the Baron and edit the line that reads, "TransponderState=2". 0=Off, 1=STBY, 2=ON, 3=ALT. I hope that answers some of your questions.

There are exactly two things causing what you guys are seeing with community modifications. Some mods supply their own instrument textures, which don't have my new extended fuel flow card for the turbocharged Bonanza. The Enhanced Cockpit Mod overwrites some of my avionics which now include a solar brightness calculator for the screens, without which, they appear too dark. Only modifications in your community folder that relate to the Baron or Bonanza will have an effect on this new version, and I believe the two issues I mentioned above are the only likely conflicts.

This is indicative of some other piece of avionics on your system interfering with the others. We commonly see this issue with out-of-date or no longer required GPS packages in the community folder. Start by emptying your community folder of everything except the Bonanza, and see if it works as expected. The Just Flight support team has gotten exceptionally good at finding these interfering packages, so please send them a message for expert help. Otherwise, I am always here to help you troubleshoot more, if you would prefer that too.

Are the Yaw Damper and Rudder Boost actually fictional in the sim? I haven’t noticed any differences in the flight model with them enabled or disabled.

I'm having a similar issue. The first engine starts without much issue (either left or right), but the 2nd one takes forever and I have to tinker with boost pumps, throttle, even mixture before I can eventually get it to start. I'll try leaving it on low boost, see if that helps.

I Do, never even thought. Thanks very much

@jcimhoff4680 spad.next

In the King Air, the condition levers use the native bindings, so any of the following should work: >K:AXIS_CONDITION_LEVER_1_SET >K:CONDITION_LEVER_1_SET >K:CONDITION_LEVER_1_INC >K:CONDITION_LEVER_1_DEC

This is still an issue for me, did you ever find a solution?

@Black-Square Thank's for the update. I wasn't aware of this article. Happy programming and I'm excited about the updates for my nearly complete Blacksquare fleet.

@Black-Square Please help me to set up the ignition switch and prop deice. What actions should there be? Thanks

Sorry, I mis-spoke. I didn't end up using the pitot heat toggle, I used pitot heat on and off events. That probably accounts for the difference.

Hi... No, it's not what you expect from overflying a ground based Navaid.. It's literally an angle offset error. First time I noticed it I was tracking a VOR radial outbound and I realized I needed a very large track correction to keep the HSI needle centered. It was acting as if I had a 100 knot crosswind. Then I did a few tests flying direct to a VOR inbound with the RMI 1&2 VOR needle, the HSI and the #2 OBS all set to the VOR. I noticed that any needles on the #2 nav would track the VOR correctly, but the needles on the #1 Nav were pointing roughly 10 degrees to the left and the closer I got to the VOR the bigger the error. It's almost like if the #1Nav radio was tuned to a phantom VOR that was always left of the one that it was tuned to. I was backing this test up by using the default MSFS VFR map. Also, the NAV 1 DME was intermittent past 11 miles.. I could listen to the DME on the audio panel as a strong morse signal, but the DME indicator was blank. This was while tracking a back course localizer where the fixes had DME references out to 30ish miles from the localizer. But the good news is, I just reinstalled everything associated with the King Air, including FSUIPC, TDS GTN, The Caravan and the 850 which I just bought last night, making sure to install the King Air and the TDS last and it appears whatever it was is now squashed. I kinda wish I had reinstalled things one at a time so I could at least find the culprit, but this beats any longer process off troubleshooting.

Turned off McAfee and switched on Microsoft Defender. Downloaded and scanned without issue. Now up and running with McAfee switched back on

@DrZGard said in King Air, KNS-80 RNAV, AP NAV mode does not work!: In the Duke the RNAV will drive the autopilot but only if no GPS is selected on the panel, a workaround discovered during the Duke's development. BlackSquare does plan to implement this functionality at least in the Baron and Bonanza and hopefully the King Air and Caravan as well. I am really hoping for a King Air panel with the CTL radio heads flanking the center radar and below that the KNS81 and KLN90B replacing the KNS80. I'd even ante up a C note to help make that happen! [image: e16a4efa-7b98-4cf2-b47c-749cceebd1e5.png]

Thanks, I got it. There are some nuances - but everything works adequately!

That's fine and makes sense in such a complex aircraft, but perhaps when you do the rework it might be worth mentioning in manual somewhere just in case anyone else gets confused!