@rlaycock Hi Bob! This post is just for my curiosity and for friendly conversation I don't intend to further frustrate Nick with conflicting feedback. You see, I was definitely one of the "complainers" about the 1.1 sounds. The quality of sound design that we are now able to achieve in MSFS is unbelievable, so much better than any flightsim before. But as a result, users are becoming more particular, and I see wars of opinion about sound playing out in the community that are more vigorous than before. I've become very curious about how different people perceive airplane sounds in MSFS, and how they develop their preferences. With that said, how would you characterize the "rumbling" sound you're talking about? To my ear, Boris really amped up the bass, the overall drama in the sound update that came with 1.1, so I would say there is even more rumbling than before. The problem that myself and others complained about was a new prop sound playing in the cockpit that seemed like an external sound...a buzzing of the prop, that was playing inside. And that's just not something you hear in a single-engine turboprop, for various reasons that I could explain (but will hold off for now). As a point of comparison, how do you like the sounds of the default MSFS Caravan?

Yeah I agree. VR. I went digging in the textures to see if there was an obvious way I could tweak something but it's a bit beyond me. I'd switch it out for white on grey or black in a heartbeat.

@Black-Square Sorry Nick, I had to crop the screenshots because 1440 is apparently too big for the forums to handle, and I thought I did a better job describing. And yes, I am in MSFS 2024, which I'm sure I missed saying in the OP. Yes, I have been starting with the propeller feathered, only for the last screenshot with the battery charging and positive instrument air had the propeller out of feather and in the high pitch position. Incidentally, I noticed with the propeller feathered that instrument air and fuel pressure reached nominal levels during startup, and then fell off again. I thought I had been keeping abreast of the propeller RPM issue, but apparently I missed how pervasive it is. Sorry about that. This is the same issue as the generator not being tied to the Ng, and therefore not putting out enough power at lower RPMs?

Hey guys, I don't know exactly how the throttle axis is configured on your TQ6s, but I had good results with my Velocity One quadrant using the MSFS 2024 sensitivity settings. I posted the results here if anyone would be interested in taking a look. This gives me the entire range of forward and reverse travel on one axis and roughly matches the virtual detents with the proper positions on my physical axis, though I don't have physical detents. If you guys have physical detents, this same method should, if I'm understanding it right, allow you to tweak it such that you can match the physical detents to the virtual ones, it might just require a different neutral and Sensitivity+/- settings.

I know this is not what you guys are looking for, but I highly recommend leaving the internal settings behind and switch to something like Axis-and-Ohs, spad.next, Mobiflight etc. This does not only solve the mysterious loosing of controls sometimes it also opens up a lot more options in terms of what you can control. Just as an example I can even manage my sunshades via hardware, every air intake,aso. Initial setup takes a bit longer for every new plane but it is worth it. Only limitation is the number of buttons and axis available as hardware.

@Mark Appreciate it as always.

@jmarkows Looks like you are 100% correct. This is f-ing awesome that even someting like this is modled. This level of detail is beyond amazing. Thanks to Nick.

@Mark Is there a chance this issue could be verified and fixed? The Vulcan is an amazing model and I've been thinking about it for a long time, but it's a pretty serious immersion-breaking issue. If you need more examples, I'd be happy to help. The basic problem is that the stick's deflection isn't symmetrical, so theoretically, it's enough to correct it so that the deflection to the left is identical to the deflection to the right.

There are a couple of sync issues with the sync of the display when H:Event are used to toggle failures. Here are 2 use cases specifically: USE CASE 1, "show only active failures ENABLED" Here are two failures being toggled remotely in the TBM (causing them to enter FAIL state, as expected) [image: 9a391b9a-8c67-4df3-a5e1-a8b0578c6dd6.png] The tablet shows the state correctly. I then toggle the R BRAKE, causing it to be fixed... [image: b76352b7-3647-40d7-ba69-be4a4920caf5.png] ALL GOOD SO FAR. Lastly, I toggle the GEAR CONTROLLER, which was the only remaining failure. This fixes it as expected however the LAST item isn't cleared from the list and remains in red. Notice ACTIVE FAILURES is 0, which is correct: [image: 8e75aa2f-3fbe-4192-8182-a19683b57ac6.png] if I click RESET on the tablet....it actually triggers the failure... (photo taken after clicking RESET) [image: e2967322-6e50-406a-994c-ba007689069b.png] if I click RESET on the tablet AGAIN...it works as expected, 0 failures and clear panel: [image: 49f4250e-91f3-41a8-8fef-df73233689c1.png] USE CASE #2: "Show only active failures DISABLED" I click R BRAKE and toggle remotely (triggers a fail, as expected) [image: e10d7888-76d7-4915-b10e-b52282113426.png] I click R BRAKE and toggle (triggers a fix, as expected). Notice the tablet remains RED for that item, despite Active Failures correctly updating to 0. [image: 59046a3f-2713-426e-9c3f-3bf671606995.png] The same behavior from use case #1 also happens here where if I click RESET on the tablet, it things it's resetting but it's actually toggling to fail mode...it then takes ANOTHER reset to clear. Keith Smith PilotEdge

For Axis And Ohs I managed it, changing the Interior.xml a bit. At the component ELECTRICAL_Switch_Alternator_1 I added this code: <OVERRIDE_ANIM_CODE> (L:var_GeneratorSwitch, number) 1 == if{ 0 } (L:var_GeneratorSwitch, number) 0 == if{ 100 } (L:var_GeneratorSwitch, number) 2 == if{ 200 } </OVERRIDE_ANIM_CODE> Afterwards I used the "Layout Generator" from fs.to to recalculate the layout.json. Now I'm able to control the Switch using something like 1 (>L:var_GeneratorSwitch, number). @Black-Square It would be great if you could add this to one of the next updates. This was already missing in the 2020 version and drove me nuts.

Thank-you both for the replies. You are right! Although I understand the difference between TAS and IAS, I didn't realize two things until now: how high an altitude the Turbine Duke can fly and how much of a difference there is between the two speeds at that ceiling altitude and temperature. I just used an online calculator to illustrate it to myself. 200 KIAS at 28,000 feet and -40 C is 308 KTAS! I'll see if I can use the temp/altitude calibration dial on the airspeed indicator to confirm this next time I'm in the virtual cockpit. [image: 442b95cd-17ea-49e9-acc3-81b35ddc7238.png]

Thank you very much for your advice - greatly appreciated.

Agreed and the OAT gauge top left. The deg C does not match. Dunno about F.

@MarkS Yes, it would be nice if one could quickly determine reasonable PID values ​​without constant testing. Strangely, this only occurs with the autopilot activated in the Cessna 152 when tracking VORs; everything is fine when tracking the GPS flight path. Therefore, I wondered if MSFS had artificially degraded the signal using a random number generator. But that can't be the case, since the C172 doesn't have this problem. What always works is the cone of confusion and, of course, the maximum range. To avoid triggering an error due to the missing line of sight, I also tested this at higher altitudes in flat terrain. Sometimes the autopilot tracks 50 NM without interruption, and then it cuts out for no apparent reason. There's also a peculiarity with the C152 that I only discovered by constantly monitoring the bus voltage variable. For a few milliseconds, the bus voltage drops to zero. You can't see it on the instruments. But since a missing bus voltage triggers a restart of my autopilot in my LUA script, it keeps restarting. The autopilot in the Cessna remains switched on. In summary, this means to me that clean tracking can only be achieved with correct PID values ​​for navigation, roll, etc.

The easy workaround would be to create an NTFS junction point, that has a very short path, but points to the deeper one. I’ll explain further when I get to my computer. But I also notice in the path in that image you have “Community2024/Community” which isn’t going to work anyway. “Community” and “Community2024” are in the same folder, at the same level, not one beneath the other.

Additionally, while 80% of the tooltips are displayed from the ceiling, some are displayed in the correct places, but it's obvious that something is wrong. The tooltips seem to be cut off. Perhaps MSFS2024 has a standard that needs to be updated. However, I haven't encountered an MSFS2020 model where tooltips are displayed incorrectly in MSFS2024. Here's an example. Model MSFS2020 in MSFS2024: [image: 1.jpg] Volcan in MSFS2024 (part is cut off): [image: 2.jpg]