I don’t think it is related to the way the unit is displayed. What i have understand is concerning a way to override some vars and taking control on the autopilot.
if it is really only that (perhaps, i’m wrong, i’m not in sim gods’ secrets 
) , i’m confidente about a smart solution will be found (new var possibility and finding a safe way of process communications) without any security issue for the product and will be benefit to everyone. For customers at first, and for product to have such perfect 1:1 unit simulation inside, like it’s predecessors, a nice publicity.
When smart and talented people meet and talk (like you are all), only good things can come out of it.
1 Like
The way I understood it, @CptLucky8 may have other things in the pipeline. Besides, his experience doesn’t cover only the Garmin trainers 
I believe it would be a benefit to everyone if Asobo reaches out to him. Until such time, everyone is pretty much speculating about what he has to say and what he wants to do. As others have said, Marketplace access has been granted to… well… let’s say, to “questionable” developers, but not to an established developer like Reality-XP, with a long history of development. There is little reason to not sit down and have a chat with Reality-XP based just on assumptions of what he might have to say.
It’s all about giving him a chance, nothing more.
7 Likes
Thanks for this thread.
I can only join the MSFS users who are eagerly waiting for a study level GTN (750/650), G600 (and other avionics) solutions within the sim.
RealityXP has been providing constant support for its products and they’re largely used by profesionnal pilots for instrument training and simulation enthusiasts alike.
The instruments database also provide very useful VFR layers/symbology and features (SafeTaxi, Obstacles, etc.) that are currently lacking in MSFS (e.g. the “VFR” map). Flights become more interesting, close to reality, and are an opportunity to learn about aviation and modern navigation.
I must admit I’ve been spoiled by using these instruments in X-Plane and they’re one of the reasons I’m far less interested in MSFS at the moment.
That also impacts my interest in purchasing third party aircraft that are known to offer compatible avionics (Just Flight PA-28s, etc.).
So, I really hope progress can be made to facilitate communication and implementation of RXP products but also other third party devs who might offer similar solutions (Dynon Avionics, Aspen EFD1000, etc.).
6 Likes
I absolutely agree 100%! My goal is to enable as many developers as possible. As I mentioned before, there are of course limitations that prohibit some specific technical solutions, but it is totally possible to create extremely detailed GPS instruments inside the sim today in other ways. And obviously there is a wealth of other knowledge available there as well. I couldn’t be more excited to get to speak.
We’ve reached out to @CptLucky8 in the Avsim thread as well, and I would just like to say that I would absolutely welcome a DM from him here and we can get him started immediately on working towards getting him set up towards being productive in MSFS.
Let’s get all the great minds together!
-Matt | Working Title
12 Likes
So, as a RXP/F1 user in P3D, I do have to point out one big disadvantage of using the Garmin trainer software - that software ships with a fairly outdated AIRAC (at least a couple of years old) and there is currently no way to update it even if you have things like Navigraph subscription… So that is potentially a decent reason not to use Garmin trainers in MSFS… Otherwise you will end up with a somewhat disjointed patchwork of AIRAC versions that is currently an issue with P3D. For example, Navigraph doesn’t update P3D’s built in data - only those of specific aircraft - PMDG, Aerosoft, etc… So we have a P3D flight planner which uses one AIRAC, and a Garmin trainer which uses a completely different AIRAC. And if you don’t use the default flight planner and use SimBrief, you will be going through yet one more version of AIRAC that doesn’t correspond.
1 Like
Every user has its own needs (and not better or worse than the other).
Some like you prefer a more recent database and less fidelity, others (like me) prefer a 1:1 fidelity to real unit and have an older database (trainer is sometime updated and database with it, and i can’t speak about other way to update them, but there is, for example, i have discovered by myself how to do, it is very easy and take minimal time with a little skill).
Anyway, that’s why such products must exist, even if it is not what some want, it is for some others. There is place (and a market) for every product and every customer.
1 Like
Thank you very much Matt for opening the door to discussion. With the skill of both of you, great things for our prefered sim can be done for shure 
3 Likes
Well, two things to say on that:
- Like i said before, i think RXP might be looking into potential fixes for that, not entirely sure. So if and when these addons hit the market, there is a chance they might be using Navigraph data. Fingers crossed.
- Some users might prefer to have the addon even with the outdated database, which has been the case in P3D and X-Plane. And ultimately, everyone has the choice to simply not buy it if they don’t like it, and this is what this is all about: creating more choice for the community.
But yes, all fair points. Ultimately, as i’m sure you will agree, even ignoring the Garmin units, simply having @CptLucky8 assisting Asobo in any way will prove beneficial to the community.
3 Likes
The problem is, we voted and we have no idea what does @CptLucky8 want from Asobo apart from (open communication). The thing is, I would appreciate if RXP can list here the open points that he needs from Asobo.
Hi,
First, let me thank all of you in this thread and others for voicing so much support for Reality XP. This means a lot to me.
Matt, I also thank you for coming forward and for offering your spontaneous help in establishing a more productive communication channel between Microsoft, Asobo and Reality XP. You and I have been sharing some of our general point of view about the SDK online, and I’ll take this opportunity to say again I believe we’re two individuals looking well beyond the mistakes of the past and looking toward contributing to the franchise renewal for the benefit of all users.
When we started contributing to the nascent ecosystem nearly 20 years ago with the first standalone gauge offering at this time, you could probably count payware aircraft with a few hands only. We’ve never stopped ever since contributing to building this industry with the help, and for the benefit, of our customers. Creative thinking outside the box has always been a primary driving force in this industry and I could cite A2A, MilViz, Orbx, PMDG and many others I personally know and worked with over the years, who are wanting nothing less than offering simmers a ride which the platform creators will never envision and the SDK won’t deliver.
The trust and respect we’ve built over many decades between us, the 3rd party vendors, are also a virtue and a primary value to our successes. It might look like we’re all competing against each other and we do, but we’re also helping each other behind the scene much more than what it looks like. This, in my opinion, is a founding reason why this franchise is where it is today, thanks to the 3rd party vendors making it alive and thriving. These highly specialized and technical islands of knowledge are what makes this hobby not only strong, but unlike any other game genre to me. And I must say I’m dully impressed by the engagement, knowledge and openness the simmers are sharing with us everyday with their support. Without them and their higher level of standards, neither we nor the platforms would even exist anymore.
Like you’ve said in another post, there are indeed lots of assumptions which doesn’t track, and some of your posts are showing this can go both sides. Your novel ideas for the JS/HTML layer and our experience and novel ideas for the C++/WASM layer can be nothing less than good to Microsoft and the entire community.
I can’t wait to start discussing all of this soon with you!
17 Likes
Very nice post JL.
This is what FS is since decade.
Now, i hope words will be followed by concrete actions.
1 Like
“…are approved while RealityXP is not?”
At least, RXP have Garmin Agreement, it is not so bad 
2 Likes
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?
Not sure why I got “quoted” here — other than in my example, it’s difficult to determine exactly what went wrong, as nowhere in the SDK does it state which, of Multiple Baros in a plane, the Kernal AP code is using for Altitude.
So a Lacking of Information in the SDK, which probably lead to the Bug by Asobo.
From examination of how the AP is working, it seems to be hard Coded to be #3, or the highest, which in the case of the c172, is #3 (so difficult to tell).
Re-indexing the Baros, so the AP’s baro is #3, corrects the issue.
Making the Transponder display FL instead of Altitude (so pressing B has no effect on the Transponder’s FL display) also corrects the Transpoinder FL display which then will not change when B is pressed.
1 Like
Is it that the gauges don’t get access to the PIDs? And instead of saying “I need 30 degrees of bank”, all they can say is “i need to be on a heading of 175”?
1 Like
Autopilot override (well, more like using the sim autopilot modes but “displaying” a different mode than you’re using by having the simvars be writable) is something I’m actively working on, including adding bank and non-rounded hdg, vs, and alt bugs simvar access. This would allow you to drive the autopilot using any existing mode (or pure pitch/bank) while allowing writing what the overrider considers to be the active mode (so, driving the avionics NAV mode by using the sim HDG mode, for example). This gets people out of the business of rewriting perfectly good AP control loops all the time.
So, for example, you could turn on HDG mode but write AUTOPILOT NAV1 LOCK to true, etc.
We hope to have a solution for this soon.
-Matt | Working Title
Would this improvement also cater for the 20ft Increment requirements for say, the KAP-140 ? This would save developers having to write their own custom AP control loops to achieve sub 100ft increments.
- VERTICAL TRIM (UP/DN) BUTTONS -
The action of these buttons is dependent upon the vertical mode present when pressed. If VS mode is active, the initial button stroke will bring up the commanded vertical speed in the display.
.
Subsequent immediate button strokes will increment the vertical speed commanded either up or down at the rate of 100ft/min per button press, or at the rate of approximately 300 ft/min per second if held continuously.
.
If ALT mode is active, incremental button strokes will move the altitude hold reference altitude either up or down at 20 feet per press, or if held continuously will command the airplane up or down at the rate of 500 ft/min,synchronizing the altitude hold reference to the actual airplane altitude upon button release.
(Note that the altitude hold reference is not displayed. The display will continue to show the altitude alerter reference.
The sim AP alt capture mode doesn’t really operate this way, but it would be indeed possible to model all of this behavior with a combination of custom alt capture using this proposed override + the sim VS or pitch hold mode and writing to simvars that indicate AUTOPILOT ALTITUDE LOCK as active. You would still need one simple control loop for the VS or pitch control, but that’s lots better than writing a whole set of inner control surface loops just for that one function.
-Matt | Working Title
1 Like
If the AP code is basically the same as in FSX, why then do small movements of the flight controls affect the autopilot? As best I recall, in FSX, the flight controls are not effective if the autopilot is engaged. But in MSFS, I find that my yoke needs to be carefully calibrated to keep it from interfering with AP operation…
1 Like
Maybe my memory is rusty, but i seem to remember being able to fight the autopilot a bit. Not like in real life, where an autopilot system has to either allow the pilot to overpower it (true for GA autopilots, i think), or in some cases even become completely disconnected if forced (the 737 has some pins that sheer off if the pilot exerts enough force countering the autopilot, permanently disconnecting the autopilot form the controls - no, this has nothing to do with MCAS). But i do remember that if you moved your joystick around, you could rock the plane a bit before the autopilot would bring it back in. Again, maybe i’m not remembering correctly. It’s been a long time since i used FSX.
2 Likes