I’ll probably try answering some of this, not all, because I don’t think this is the proper place and this might become too technical anyhow. Nevertheless, I fell it is important to remind there are two different sides to it: porting RXP GTN and RXP GNS to FS2020, and contributing to better the SDK. One goes with the other to some extent, but not just.
To illustrate, I’ve picked up a discussion a few minutes ago where a few things are striking to me. It might be because I’ve been dealing with this for 20 years from the simulator entrails and this gives me a different perspective on those things, especially when I know how the simulator is coded internally (literally, not just by general knowledge of C++ and standard algorithm).
Here is:
IIRC this dates back to FSX as well and to me this illustrates a form of legacy SDK heritage, which was only meant first for ACE studio building the stock aircraft, not for 3rd parties. In effect, the need was for displaying values and reacting to mouse actions, and these were hard coded in the core and exposed through the SDK as pre-computed digested values to directly drive the display (no scripting capability therefore the value must be read as it would be displayed directly), and also exposed through the SDK as simple mouse events doing macro-like actions internally (pressing the A/P ALT button disconnects VS mode + disconnects X + arms Y…).
This really illustrates to me a certain mindset behind the SDK which might seems fine but is really more troublesome for 3rd parties than necessary. I’ll give you a practical example of this affecting ALL 3rd party vendors doing C++ gauges and using the C++ SDK: The Autopilot
The FSX (and by extension the FS2020 one as seen through the SDK) is like any other autopilot implementation, basically 4 controllers using PIDs and affecting BANK, PITCH, YAW, THRUST.
Depending on the ARMED/ENGAGED modes, the simulator is updating these PIDs and is actuating the control surfaces. So far, nothing special. Moreover, the FSX PIDs are just like any other PIDs and can be fine tuned in the aircraft config files, and they are well implemented code wise, pretty much like any 3rd party would code its own PID controller logic.
So here is the question: considering nearly all autopilot systems boil down in the end to just the same 4 controllers I’ve listed above, why is it 3rd party vendors have to rewrite their own autopilot system?
Before telling what I do think about some of the probable limits to 3rd parties in how the SDK is exposing the autopilot system, therefore what could be done differently to help better the SDK, I’d wonder what some of you are thinking about this one?