Any news about this? Having lights visible from a distance in the LOD would really help. Thanks.

@V1RotateAP Thanks for the screenshots. That's exactly what I was looking for. Here is what I have been able to determine from my testing: The standby alternator is energized, and contributing power to the aircraft. The two annunciator lights are behaving correctly, as all conditions appear to be met. Indications on the tablet are confused, because my variable L:var_AlternatorOnline is not true. We can see this with the red line through the ammeter (reading zero), which both rely on this variable. There are two avenues we could pursue from here: Why is L:var_AlternatorOnline not being set correctly, despite all conditions appearing to be met. Why is the alternator energized to begin with. I'm inclined to investigate the first point, since, technically, L:var_AlternatorOnline should have no impact other than the visuals displayed on the tablet, while the electrical system is causing the annunciators to illuminate, and causing unexpected electrical behavior. Again, here is where I would suspect a hardware issue (even though I emulated this in my testing, and it caused L:var_AlternatorOnline to be set correctly. To further test this, I would recommend temporarily binding a key combo to Toggle Alternator 2 in the simulator's controls menu. Then, try toggling the alternator manually and see what happens. Either, it will... Toggle back on by itself. Remain toggled off. If #1, then it's more likely a code-side problem. If #2, then it's more likely a user-side problem. I really appreciate the help, and the testing above would provide exactly the kind of information I need next. Thank you so much!

@Black-Square sorry, is "disable aircraft stress damage"? Thanks. ( https://imgur.com/a/tspRFAI )

Agreed, JF is one of the top-tier development houses we have for the MSFS ecosystem, both in product launch and post-launch support. As a newcomer to the world of flight sim (as an adult, anyway) with 2020, Just Flight quickly established themselves high up on my "no questions asked purchase" list of developers and have done nothing but reinforce that decision at every opportunity. If I had one wish, it would be for a slightly bigger team in order to maybe go just that bit further modeling abormals, or push out updates on a faster cadence, but even at their current size if things are broken by the sim, they never remain so for very long. Also, they still got their entire product line into 2024 from 2020, with updates, for free and far faster than some other development houses who seem to do everything they can to court drama. I'm also very happy that Martyn seems to have hired some help because for a while he wore so many public-facing hats it seemed like they should have been named Just Martyn

We have reported this to Asobo in our existing thread on registration issues, were told to make another thread, and have received no response. I will see that they receive another message about this, because it really is unacceptable that this is still broken after almost two years.

@RealPax Indeed! It always helps me sleep a little better, because I know there is at least one less demon that might be floating around in my code. @scanham Thank you for your response!

@F737MAX Good tip, thanks. I'll add it to my small collection of useful Firefox extensions!

@Mark Mark, I disagree in this case. The video clearly shows different speeds at roll rate and also different stick response in the cockpit. I've described and documented this quite well. I also have absolutely no linearity issues, let's say calibration issues. I've been in simulators for 20 years and am a beta tester for several well-known companies, including Aerosoft, Millviz, Blackbird Simulation, Got Friends, etc. I have a lot of experience in aviation. Unfortunately, there's a bug here, and I'm 110% sure of it. Perhaps someone is questioning some settings in Vulcan itself and certain compatibility with MSFS2024 or one of the updates. It's hard to say. The plane oversteers to the right in terms of aileron deflection. The previous person also noticed this but didn't follow up on the thread.

@Mark Screen was done in VR.

I'll add that this issue has been partially resolved. However, this applies to MSFS2024. There's an option to change the binding. However, the right mouse button is assigned in MSFS2020 (hard coden I suppose). Currently, I only fly in MSFS2024, so I changed the zoom assignment to Num0 and it's fine. It turns out that some of the press and pull buttons use the right mouse button, so it's a more involved operation.

You're both welcome, though I didn't do much beyond a glance at .cfg files and trying out various dev mode debug tools in the menu. Thanks Nick for the corrections. I'll make them just for the warm fuzzy feeling that fixing incorrect data always gives Besides the 'show sim forces' debug option (earlier image), it's very interesting to see the different CFD visualisations at work. With one engine inop there is clearly a sudden loss in thrust, even a loss in the downward deflection on the adjacent air flow from the lack of prop wash over the inop engine's wing, but no yaw tendency or rudder forces/effects show up whatsoever (whether AP is engaged or not, in case of a hidden yaw damper interfering). A roll tendency occurs into the dead engine as you might expect, just no yaw. That's in itself is interesting because it seems to show that MSFS decouples various aspects of the flight model; the forces and moments acting on the aircraft may not be purely a result of all the aerodynamic forces shown (else something else is blocking it from occurring). I know there are legacy and modern flight models, and various settings that are old or new - it must be a nightmare to keep track of which settings actually influence the aircraft and which are deprecated (and catching the undocumented ones) - so I don't envy any developer's job there (well I kind of do, in a different life). I'm sure this one is 'on the list' to be investigated in due course anyway. Regards, Martyn

Sure, thank you Mark. Amazing plane i love it.

@Wothan Got you, sorry that I cannot help. I did move away from the MSFS Contol System already in FS2020. For that reason I don't have any experience with the internal control bindings of MS2024. Hopefully someone else with more knowledge can help you.

Missing textures would typically indicate an installation issue, or possibly another mod/product causing a conflict. As a first step, we would recommend reinstalling the latest version of the Vulcan (MSFS 2020: v0.1.3, MSFS 2024: v0.1.4) and then checking if any change is observed with the missing textures and the aileron trim. If either behaviour persists after a reinstall, could I kindly ask you to raise a ticket with Just Flight Support via the following link: https://www.justflight.com/support Our support team will be best positioned to be able to further assist with this. Mark - Just Flight

The Vulcan was the second aircraft we developed into an MSFS 2024 native product, and therefore, it was developed around the time when we were still learning how to develop products for the new simulator. For that reason, it doesn't make use of as many MSFS 2024 features as our more recent MSFS 2024 native products. All of the MSFS 2024 elements that we have intentionally included with the product are working as intended, and additional items, such as MSFS 2024 walkaround mode, are items we would like to include in a future update, but due to the development time involved in adding those, we wouldn't be able to commit to a timeframe for when those may be added. Mark - Just Flight

I hope you guys don't think I've been ignoring you. Unfortunately, I wish I had better advice to offer. The code in the Caravan that might have anything remotely capable of producing a CTD is identical to my other aircraft, and the Caravan has even less in the way of avionics than most of my other aircraft. I know several of you are seeing symptoms that appear limited to the Caravan, but I have also seen similarly limited behavior with my other aircraft in the past that resolved themselves in various different ways. Luckily, I haven't had any consistent and persistent CTD reports (other than v1.0 Starship) with my aircraft over the years, largely in part to their architecture, which avoids WASM, where CTD's are most likely to happen. I would encourage you to keep looking for outside applications or system-level issues that might be causing this, but in the meantime, I will be watching this thread closed to see if there is anything I can learn, or anything I can suggest for testing. Sorry that you're dealing with this right now. I just wish I had more to offer.

Left over from the Duke manual. I've fixed it. Thanks.

Thanks for the comment. Indeed, I've already done the work for all my other aircraft. There is actually yet another step I could take to make the flares really bright (hyper-realistic, shall we call it) during the day, but this would take much more work, so I wanted to see what my users thought of this change first. I think the results are definitely acceptable now, and anymore would be (probably less realistic) eye-candy.

Hey Nick, same as the guy above me, I'm using the WT GNS 530/430 combo and I'm seeing the KAP140 baro setting having no effect and the main altimeter setting controlling the AP. Currently flying the Cargomaster in MSFS 2024, Caravan v1.1. Edit: removing the ping, as based on the comment re: WT update cycle I suspect you're aware of this. I thought it worked in the Analog Caravan in 2020 though? I was using WT avionics back then, as well.

The best plane in X-Plane is the AFL King Air 350. It would be nice to have a competitor in MSFS2024.