Effectively it’s as they stated. almost everything because even aircraft purchased outside the MP like so many like to do are the same aircraft as the ones sold on the MP. If that’s the case the only risk comes for those that are exclusively not MP and there are not many of those in the grand scheme of things. I expect the number of aircraft with issues going straight into 24’ will be low.
Ever the optimist.
Logically, one of two things is going to happen:
(1) MSFS24 will be as backwards compatible with MSFS addons as is technically possible, or;
(2) It’s not technically possible or feasable to make MSFS addons compatible with MSFS24.
There is absolutely no rational business decision in which Microsoft would not make 24 as easy to upgrade to as possible for the end user. If you tell the sim community “you’re going to have to rebuy everything,” your key customers, i.e. the people who spend thousands of dollars on addons - “whales” if you prefer - just aren’t going to upgrade, period, likely until MSFS is completely unsupported and unusable. And those people are your best and most vocal evangelists for the product. All you’re doing is reducing your sales and your user uptake numbers if you take that route. It’s stupid business, and MSFT is anything but stupid.
To put it another way - have you ever had to rebuy all your software when you upgraded to a new version of Windows? Of course not - nobody would buy the new Windows in that case unless they absolutely had to.
So I 100% take Microsobo at their word that 24 will be as compatible as they can make it.
I’d just point out that there there are separate XP12 versions of planes. You may find your XP11 version works, but it looks like it requires a new version to make the most of it, and developers appear to have opted for the “buy it again” model, including increasing the price.
No intention to give any pressure! We understand it will be done when it is done. I was just curious because I wasn’t playing MSFS for about a year and catching up wonderful things that happened in that period. Purely worried I was missing something.
Besides when it’s done, I wonder to what MSFS command the CWS button on the yoke will be assigned. I hope one of default command could do that because I’m not using any external software like AAO or SPAD. I feel I should be using one of those someday but I don’t want to if I don’t have to.
SO let me get this straight, you are working on both the 350 Malibu AND 700 Fury version? Or did I miss something? 
I haven’t say anything about those, but M700 is too new to even be able to get IRL data to build the engine model as i did with fsr500, makes zero sense for me to work on it unless you wish it to be a quick cash grab, with just a pretty 3D 
Is not how I like to build things… 
My full current road map was posted on my discord, also did an interview with twotonmurphy few weeks back, is online on his channel.
Best,
R.
Right i pushed like 5 or 6 updates since… another comin soon to fix some bugs.
It has been a lot, for version revision use the msfs content manager fsr500 version and there you can see also the change logs, the user manual version doesnt necessarily matches the product version.
Best,
Raul
If a suitable MSFS command doesn’t exist for a particular function, then it’s possible to code the function to another unused command - e.g. the FSW Learjet 35 has a form of CWS and uses SMOKE ON / OFF commands. There are plenty of other examples. It’s up to the Dev how they choose to do it
By “CWS” I assume you mean “Control Wheel Steering” mode on the autopilot?
Yes, as per the original question.
I was just messing with you Raul. I know you have a ton on the schedule, I’m just waiting patiently for the awesome aircraft.
Forgive me, I do not see the original question or any mention that CWS = “Control Wheel Steering” in this context. But then again, this message board format is so WEIRD that I might be missing it.
Anyway thanks for clarifying
I got another question.
The FSR500 manual says that the “Autopilot Disconnect / Trim Interrupt” button on the yoke would disconnect the autopilot AND yaw damper. (CABIN & COCKPIT LAYOUT 5-9; page 58 in .pdf)
But then, according to “ANNEX 3: Table of Events and Variables” (page 148 in .pdf), the AP disconnect button is linked to the sim-native “AUTOPILOT_OFF” event, which doesn’t seem to disconnect yaw damper. I assigned it to a button on my joystick and I have to disconnect the YD via GMC710 AP panel.
If the description in the manual is correct, shouldn’t the native “AUTOPILOT_OFF” command disconnect the YD at the same time? That would be more simple solution than assigning double event to one hardware button stroke or making dedicated local event variable.
I’m making this not a bug report or feature request because I’m not sure if I observed it right. I didn’t test clicking the AP disconnect button on the virtual yoke with my mouse. I’m asking other people’s experience and opinion while I suspect my bad landing is due to not disconnecting YD on time. 
What the manual describes at pg 58 is what the IRL behaviour of that button would be.
But yes, the standard MSFS AP events won’t replicate that, so bind the YD OFF event as well. Remember - the yoke buttons is only to turn them off, not back on as well.
The downside of a custom event is that is then no longer available to folks who don’t run Spad, AAO etc and also not available to Xbox users.
As for your landing…well I’m not personally convinced a yaw damper does much of anything one way or the other in MSFS…but procedurally you should definitely have it off.
I’m pretty sure the YD disconnects itself on the FSR500 in landing configuration at roughly 500’ agl. If I don’t do it before hand, I get a flashing YD on the AP mode section of the PFD and the YD is disconnected. This is the only plane I have that does that.
Correct, but it is below 100ft AGL. As per in real life:
Best,
Raul
Thanks for the all the infos.
Given that the standard MSFS “AUTOPILOT_OFF” event won’t replicate the IRL behavior of the yoke button, wouldn’t it be better the FSR500 to behave internally to disconnect YD as well when the “AUTOPILOT_OFF” is commanded from the outside?
Of course binding YD_OFF and AP_OFF together to one button will work for FSR500 but there are some other planes that leave YD on when AP is disconnected. I want my controller scheme as generic as possible unless I see unavoidable necessity.
This is of course just a trivial thing.
I’ll be happily landing with YD on because automatic disengage with flashing annunciation are so cool. 
I’ve never been too sure how much YD works at all in 2020. I never even tried to see if it auto disengaged, I always click it off before as the last couple minutes wind down as I ‘de-automate’ just before disengaging AP.
Heh, I nudged him about a 700 fury and/or a 350 Malibu…
