@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.

Oh, I didn't think I had an event to reset all failures, but I do! It's H:BKSQ_FAILURE_RESET_ALL_FAILURES. I'll check on the rest soon.

I recorded a video showing an anomaly visible even on the stick itself. The movement is performed exactly the same to the left, then to the right (with the same force, angle and speed by my hand). To the left, everything works fine; the plane reacts rather sluggishly at this weight, but to the right, the movement is immediate, abrupt, and overly sensitive. In flight, it looks like the plane rolls correctly to the left, but the roll rate is excessive to the right, which means the plane is even capable of performing a quick roll like a light jet (a Hawk, say). The axes should operate at the same deflection and speed to the left and right, but they don't. To the left, it's fine, but to the right, it behaves completely differently, resulting in a flight model issue. https://www.youtube.com/watch?v=GFbMRp61aKI This is clearly a bug. It may have been fine before, but any update requires tuning for Vulcan as well.

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]

@PAStime Taking a look at the Engine Power Settings section of the manual, you can find power setting and altitude combinations that result in 195-292 KTAS at maximum gross weight, with the maximum cruise speed of 320 KTAS either being achievable at higher than recommended ITT for engine longevity, or minimal loads.

I've emailed Aeroplane Heaven and your selves at Just flight many many times begging for a Super VC 10 in MSFS 2020-2024 infact so many times in the last six years my emails now get ignored.

@Black-Square said in A list of Squawks as a 10+ year TBM Maintainer: This is the only tough one, unfortunately. As I just explained to someone else in another thread, MSFS does not really have any support for beta range, and everything you see here is me fighting with the underlying simulation to get what I want. For whatever reason, the propeller simulation creates a decrease of RPM when reducing the blade pitch into the beta range. I've considered adding yet another patch of my own on top of this simulation to mitigate the problem, but too many patches on top of patches can become a dangerous thing in software, unfortunately. I have no knowledge about the real aircraft behavior, however would like to add one point from a pure flightsim perspective: It is basically impossible to find a power setting that maintains taxi speed at a stable level. If I control the power lever with the keyboard F2 & F3 I can set increments of 1%. If I have a setting that increases speed, reducing by 1% already slows the aircraft down. If this is similar in the real aircraft I would accept this. If not, I would appreciate checking if the a stable speed can be achieved with a broader range of power lever setting, knowing that aircraft weight & weather conditions have an influence as well. Anyway, @Subsonic many thanks for your real maintenance view, if you can also on my comment.

Is there any connection to the surface modeling from the simulator? I've found similar behavior with another popular 737 previously that once at a set taxi speed, it never changes. I see this as well with the Caravan. If I am in Beta at 15kts - It will tend to stay at 15kts. If BETA is ZERO thrust from the prop, I'd expect some friction and other forces to begin reducing the taxi speed where I will eventually need to pop out of beta to maintain forward speed.

The state saving in the 146 is not tied to a specific variant or livery. Whatever state is saved when exiting a flight in the 146 will be the same state that is loaded on the next flight in any 146. The only exception to this rule is the configurable equipment (HF aerials, VH3 aerial, etc.), which is automatically configured on a per-livery basis. Mark - Just Flight

[image: cf01951b-5fe0-4b55-8a65-2577915ea8e5.jpg]

I gave in - should've held off.

Brilliant, thanks Mark!

Just adding feedback for the 'buzzing' prop while in cruise in latest update. This seems to be a regression from V1.0 as you would not hear this in the actual aircraft. Glad to see it will be corrected! I also notice this issue in the TP Bonanza along with other default MSFS aircraft (TBM comes to mind) You do not hear these prop sounds in-flight, it is only something you would hear on the ground or externally...

@Mark Thanks. I will test it again over easter and see if the problem still exists. I‘ve read that there are some people reporting similar issues with other products and even default aircraft here: https://forums.flightsimulator.com/t/unable-to-click-some-items-with-the-mouse-in-vr/758216/32 Seems to be VR related and probably something for Microsoft/Asobo to solve, not you…

Turn the knob on the amm/voltmeter on the left side to the Gen and Alt positions and show screenshots. I mixed up the above screenshots and didn't realize one was saying PWR ON, I thought it was OFF and INOP, so unless the generator is failed, which I doubt given that you've been looking at the failure screen, I'm curious what the generator and alternator power draws are.

@Black-Square the su5 beta also affected the Baron in VR in a similar way, click spots become very small and the tablet was unreachable. The releases notes did mention they were adjusting the interactions in VR so it wasn't a surprise to me. However it seemed to be fixed in the last update they pushed (within the last two weeks) - for me at least.