True, I’ve been a navigraph subscriber for years though, some of the best money I spend in Flight Sim IMHO.

3 hours ago, ryanbatcund said:

As long as Asobo includes more data I agree.  They're missing tons of smaller airport approach procedures.  You can get it from Navigraph for now for a fee.

But again isn't what Navblue was there for, they boast as having the "world’s largest and still growing aeronautical database". But we have to goto Navigraph to complete the data. I still can't understand it.

33 minutes ago, FPStewy said:

But we have to goto Navigraph to complete the data.

And that is not as complete as what I have with Garmin Trainer databases with RXP GNS and GTN.

On 3/13/2021 at 1:51 PM, JeffChrisope said:

and other developers who are not waiting for the platform to come (back) to them and instead forging ahead with the new tools and techniques are showing significant successes.  

On 3/13/2021 at 11:32 AM, jabloomf1230 said:

ut that's not what RXP is saying about the GTN. What they are saying is that it is presently not possible to utilize the official Garmin trainer app as a basis for a GTN gauge in MSFS.

I'm not singly you out in quoting you, it is just representative of a misconception.

I've described the problem in various posts, but maybe some of the most illustrative ones which I recommend everyone reading first:

https://www.avsim.com/forums/topic/582275-rxp-gtn-750650-and-gns-530430-for-fs2020/?do=findComment&comment=4323291

Quote

 

The problem is not about running the trainer process nor in displaying the GTN screen in a FS2020 gauge.

The problem is rooted deeper and is the same as with any FltSim version from FS9 to P3D5 and now to FS2020: unlike X-Plane, there is no overriding capability for the autopilot and the simvars... This is all done today in hacking and injecting code at run time into the Fltsim runtime. This is the technology which makes it possible to integrate the GTN in any aircraft and get any 3rd party gauge displaying correct needle deviation and any 3rd party autopilot (implemented on the internal Fltsim autopilot system) to guide the aircraft from our GTN navigation data.

 

https://www.avsim.com/forums/topic/587090-are-all-the-g1000-community-mods-rolled-into-one/?do=findComment&comment=4493980

Quote

 

Our products are almost unique in the flight simulation world, not because they are based on the trainer, but because they must integrate with any aircraft so that the navigation data they're providing is working with the aircraft instrumentation. They are also unique because they must be retrofitted in any panel not just for the look, but for the user interaction. And this is not just clicking a knob with a mouse, but making any form of user input (mouse, keyboard, programmatically) seamlessly integrated in the user experience. This is also a unique position, compared to other 3rd party vendors building whole-aircraft, because it makes you thinking out the box and finding novel ways which seamlessly work for our customers.

What most customers are ignoring though, is achieving the high level of sophistication from a SDK gauge standpoint only (I'm not talking about the GPS simulation) is not something any FS SDK is providing the means to. We can build our products on X-Plane in using the X-Plane SDK as-is, whereas there is no other way to do them in any flight simulator product without augmenting and patching the internal code, because the SDK is exactly reflecting the very idea an add-on product is a self-contained entity, regardless of the other add-ons, and regardless many simmers are mixing add-ons together with overlapping functionality sometimes, and the very questions surfacing with inter-mods conflicts in this topic are also exposing the same mindset prevails among 3rd party developers, and why I feel compelled to explain why I believe it is not representing some of the challenges 3rd party developers are dealing with the SDK, and how this has nothing to do with embracing new technologies like JS/HTML.

One such example of how much the FS mindset is strong is in assuming any RXP GPS product in FS2020 would require the aircraft having a spot to place it. Thinking outside the box I'd say please consider this instead: make the SDK providing the means to instantiate a 3D model + texture + clickspots at runtime.

[...]

I can assure you I'm not waiting for anything, quite the contrary. I've been proactive as much as possible raising awareness to these questions and forward thinking vision, helping my peer simmers in the FS2020 forum as much as I could, contacting MS and Asobo people to build a relationship and raising fundamental and practical questions but offering at the same time the directions they could follow to solve these, which most of the time are easy to implement on the existing infrastructure, and I'm still open pursuing the opportunity to sharing my knowledge and ideas to whomever is listening but willing to act.

 

I'll give you a concrete example of the SDK limitation which has nothing to do with JS/HTML vs WASM vs DLL:

The CJ4 autopilot is a client-facing only gauge which buttons and modes are not directly linked to the underlying FS2020 Autopilot system. Instead, it is controlling the FS2020 autopilot system in enforcing the HDG mode and in changing the HDG bug underneath (or something close to this). Similarly, the vertical mode is using the VS mode. But the user don't see this because the gauge is presenting a different view than reality. The reason WT is implemented the CJ4 autopilot in this fashion is because there is no flight director overriding capability in the simulator (unlike X-Plane), and WT CJ4 is confronted to the very same limitations preventing the Reality XP GTN or GNS V2 to be implemented in FS2020. It is possible to make it this way for the CJ4 because it is a self-contained aircraft with its own gauges but it is not possible doing this with a GPS gauge you could retrofit any aircraft with. Instead, it requires just adding the support to overriding the flight director.

And this is where it gets tricky: if they were providing a flight director overriding event/command, it would mean the autopilot would need to feed its controllers (the "black box" computing the difference from the desired and the actual angle and outputting a command to the control surfaces - using PIDs) with the flight director values as input. But here is the catch (and most likely why some are reporting the "bug" you need to arm an A/P mode to get the F/D bars, still in FS2020): the code handling the autopilot and the flight director is doing it in reverse from FS9 to P3D5, and I'm nearly certain it is the same code feeding FS2020. I know it is because we need to change this for the GTN and the GNS V2...

Now of course there are other ways, like overriding the default flight plan and let the autopilot following it. In fact, this is no different than what we're already doing with our GTN and GNS V2 when you enable "Auto-Update Simulator GPS Waypoints" setting. However this poses a problem because in doing so, you'd get the autopilot following the course in the FS2020 way, not in the Garmin way. Our GPS are authentic navigators and the autopilot coupling is working exactly like they are working with the real one (and this is one of the reason professional pilots are training with professional simulators running with our GPS, among other things).

Please, you have to understand I've been reverse engineering all versions of flight simulator products, I know how they are coded internally, I can see some of code compiled over and over without any change whatsoever from FS9 to P3D5, and there are strong indications some of the same code is nearly the same in FS2020. The entire autopilot system low level implementation is exactly coded the same, with the same C functions, the same code logic and the same connections internally from FS9 to P3D5 (this is why it takes us only a few hour to build our update whenever a new P3D version is released!). And this is just 1 example. Please also understand this kind of knowledge I have about the implementation and the internal code is out of reach of most my peers which are not confronted to these questions when making self-contained aircraft, and this is a unique expertise I've build upon working exclusively for a living for the last 20 years in this industry. I've build this by necessity to workaround the SDK limitations with all Flight simulator versions, whereas we don't need any hack whatsoever with the X-Plane SDK.

I'm very glad they are partnering with WT which is pushing the envelop on the JS/HTML layer which I've kept telling this should be the only supported and documented layer, because I completely share WT vision and I'm advocating the same about the SDK: 3rd party vendors must adapt to the new technologies (and Asobo would free resources in not trying to please older 3rd parties porting their existing code as-is via the "FSX SDK look alike" bridge they are building). For example, I still don't get what is the need to invest in re-building a WASM GDI+ interface, on top of a NanoVG interface, itself build upon Asobo's low level path tracing and bitmap bliting API, expect helping existing 3rd party vendors porting their existing gauges "as-is". But the truth of the matter is that there is no product today which is ported and taking advantage of this that I know of.

Having said this, I'm also advocating the JS/HTML layer shouldn't be reproducing the same errors found in the legacy FSX SDK and unfortunately I believe there are still some of the legacy mindset and constructs strongly infused in the modern layer. I'm also advocating MSFT/Asobo working with 3rd party developers knowing the X-Plane SDK because there are good ideas and concepts which would benefit the FS2020 SDK at large.

I've been dealing with these questions, both the SDK and third party gauges integration with any aircraft, over the last 20 years on 2 different simulator ecosystems and 14 different simulator versions. I've also been trying to share with Microsoft and Asobo for more than a year now. I find a little bit unfortunate I can only share this knowledge with you, whereas I believe it would be more valuable I could share this directly with them and if this could be helping them better the SDK for third parties, not just RXP. I've been trying for more than 12 months but nobody at the other end is answering back, not even by courtesy or at least to be polite and show a minimum of respect to a renown and established 3rd party vendor like Reality XP. I'd tend to think they are too busy and this is probably why they didn't find the time to answer my calls (and I'm both fluent in French and English which is helping). This is a reality you can't ignore either.

This is why again I'm quite excited they're partnering with WT because they might not know it yet, I'm entirely in phase with their way of thinking for the SDK and how the modern technologies implemented in the JS/HTML layer are game changer, both in terms of capabilities and in lowering the entry barrier. This partnership is also showing Microsoft is opening the door to 3rd party assistance, and I'm certain there is much more to do once we can address the underlying legacy construct which I find are impairing creativity and preventing a whole category of features simmers are looking for, if not expecting in their simulator. I'm quite open helping with these questions and ready to work with whomever is in charge and capable of addressing these, not just for RXP, but for any 3rd party vendor benefit.

PS: the 2 most voted topics for the last Q&A where both asking Microsoft/Asobo to get in contact with Reality XP. I won't judge why they still aren't, there is no need to judging this, but I sincerely thank everyone who is supporting us, this means a lot:

https://forums.flightsimulator.com/t/live-dev-q-a-guided-question/370628/14?u=cptlucky8
https://forums.flightsimulator.com/t/live-dev-q-a-guided-question/370628/59?u=cptlucky8

 

Edited April 16, 20215 yr by RXP

That's some "from the heart writing" if I've ever read any!

2 hours ago, RXP said:

I'm not singly you out in quoting you, it is just representative of a misconception.

Where did I say that the problem was running the Garmin Trainer or displaying it in the sim? I said that interfacing the Trainer app with the sim is the problem. I appreciate your lengthy explanation but what @JeffChrisope said is true. It is possible to write gauges from scratch for MSFS using the SDK. The G1000 and G3000 work more or less and the WT mods get them closer to RL. Eventually someone might even develop a GTN from scratch for MSFS.

I understand your frustrations about the MSFS SDK. There are many P3d5 and XP11 developers in the same leaky MSFS SDK boat. But MSFS is not like either of these sims nor is it some glorified version of FSX.  There's some pieces of the MSFS SDK that either don't work correctly, don't work at all or are officially deprecated. Asobo has been fixing things in order of priority and if the problems you underscored are such a high priority they may eventually address them.

2 hours ago, RXP said:

The reason WT is implemented the CJ4 autopilot in this fashion is because there is no flight director overriding capability in the simulator (unlike X-Plane), and WT CJ4 is confronted to the very same limitations

Just to say it out loud, this is very much on our radar because it is part of the reason we have not yet ported the flight plan management from the PL21 over to the Garmins. As the sim exists today, the flight plan manager must be accompanied by an autopilot. We have debated doing just this for the G1000 or G3000, but feel that addressing this challenge you have outlined extensively here and elsewhere would be better addressed at a macro, sim-wide level.

It is worth saying that there's more than one way to skin this cat, though, so I can't speculate on where this will land, but it is a high priority for us.

On 3/13/2021 at 9:34 PM, RXP said:

I'm not singly you out in quoting you, it is just representative of a misconception.

I've described the problem in various posts, but maybe some of the most illustrative ones which I recommend everyone reading first:

https://www.avsim.com/forums/topic/582275-rxp-gtn-750650-and-gns-530430-for-fs2020/?do=findComment&comment=4323291

https://www.avsim.com/forums/topic/587090-are-all-the-g1000-community-mods-rolled-into-one/?do=findComment&comment=4493980

 

I'll give you a concrete example of the SDK limitation which has nothing to do with JS/HTML vs WASM vs DLL:

The CJ4 autopilot is a client-facing only gauge which buttons and modes are not directly linked to the underlying FS2020 Autopilot system. Instead, it is controlling the FS2020 autopilot system in enforcing the HDG mode and in changing the HDG bug underneath (or something close to this). Similarly, the vertical mode is using the VS mode. But the user don't see this because the gauge is presenting a different view than reality. The reason WT is implemented the CJ4 autopilot in this fashion is because there is no flight director overriding capability in the simulator (unlike X-Plane), and WT CJ4 is confronted to the very same limitations preventing the Reality XP GTN or GNS V2 to be implemented in FS2020. It is possible to make it this way for the CJ4 because it is a self-contained aircraft with its own gauges but it is not possible doing this with a GPS gauge you could retrofit any aircraft with. Instead, it requires just adding the support to overriding the flight director.

And this is where it gets tricky: if they were providing a flight director overriding event/command, it would mean the autopilot would need to feed its controllers (the "black box" computing the difference from the desired and the actual angle and outputting a command to the control surfaces - using PIDs) with the flight director values as input. But here is the catch (and most likely why some are reporting the "bug" you need to arm an A/P mode to get the F/D bars, still in FS2020): the code handling the autopilot and the flight director is doing it in reverse from FS9 to P3D5, and I'm nearly certain it is the same code feeding FS2020. I know it is because we need to change this for the GTN and the GNS V2...

Now of course there are other ways, like overriding the default flight plan and let the autopilot following it. In fact, this is no different than what we're already doing with our GTN and GNS V2 when you enable "Auto-Update Simulator GPS Waypoints" setting. However this poses a problem because in doing so, you'd get the autopilot following the course in the FS2020 way, not in the Garmin way. Our GPS are authentic navigators and the autopilot coupling is working exactly like they are working with the real one (and this is one of the reason professional pilots are training with professional simulators running with our GPS, among other things).

Please, you have to understand I've been reverse engineering all versions of flight simulator products, I know how they are coded internally, I can see some of code compiled over and over without any change whatsoever from FS9 to P3D5, and there are strong indications some of the same code is nearly the same in FS2020. The entire autopilot system low level implementation is exactly coded the same, with the same C functions, the same code logic and the same connections internally from FS9 to P3D5 (this is why it takes us only a few hour to build our update whenever a new P3D version is released!). And this is just 1 example. Please also understand this kind of knowledge I have about the implementation and the internal code is out of reach of most my peers which are not confronted to these questions when making self-contained aircraft, and this is a unique expertise I've build upon working exclusively for a living for the last 20 years in this industry. I've build this by necessity to workaround the SDK limitations with all Flight simulator versions, whereas we don't need any hack whatsoever with the X-Plane SDK.

I'm very glad they are partnering with WT which is pushing the envelop on the JS/HTML layer which I've kept telling this should be the only supported and documented layer, because I completely share WT vision and I'm advocating the same about the SDK: 3rd party vendors must adapt to the new technologies (and Asobo would free resources in not trying to please older 3rd parties porting their existing code as-is via the "FSX SDK look alike" bridge they are building). For example, I still don't get what is the need to invest in re-building a WASM GDI+ interface, on top of a NanoVG interface, itself build upon Asobo's low level path tracing and bitmap bliting API, expect helping existing 3rd party vendors porting their existing gauges "as-is". But the truth of the matter is that there is no product today which is ported and taking advantage of this that I know of.

Having said this, I'm also advocating the JS/HTML layer shouldn't be reproducing the same errors found in the legacy FSX SDK and unfortunately I believe there are still some of the legacy mindset and constructs strongly infused in the modern layer. I'm also advocating MSFT/Asobo working with 3rd party developers knowing the X-Plane SDK because there are good ideas and concepts which would benefit the FS2020 SDK at large.

I've been dealing with these questions, both the SDK and third party gauges integration with any aircraft, over the last 20 years on 2 different simulator ecosystems and 14 different simulator versions. I've also been trying to share with Microsoft and Asobo for more than a year now. I find a little bit unfortunate I can only share this knowledge with you, whereas I believe it would be more valuable I could share this directly with them and if this could be helping them better the SDK for third parties, not just RXP. I've been trying for more than 12 months but nobody at the other end is answering back, not even by courtesy or at least to be polite and show a minimum of respect to a renown and established 3rd party vendor like Reality XP. I'd tend to think they are too busy and this is probably why they didn't find the time to answer my calls (and I'm both fluent in French and English which is helping). This is a reality you can't ignore either.

This is why again I'm quite excited they're partnering with WT because they might not know it yet, I'm entirely in phase with their way of thinking for the SDK and how the modern technologies implemented in the JS/HTML layer are game changer, both in terms of capabilities and in lowering the entry barrier. This partnership is also showing Microsoft is opening the door to 3rd party assistance, and I'm certain there is much more to do once we can address the underlying legacy construct which I find are impairing creativity and preventing a whole category of features simmers are looking for, if not expecting in their simulator. I'm quite open helping with these questions and ready to work with whomever is in charge and capable of addressing these, not just for RXP, but for any 3rd party vendor benefit.

PS: the 2 most voted topics for the last Q&A where both asking Microsoft/Asobo to get in contact with Reality XP. I won't judge why they still aren't, there is no need to judging this, but I sincerely thank everyone who is supporting us, this means a lot:

https://forums.flightsimulator.com/t/live-dev-q-a-guided-question/370628/14?u=cptlucky8
https://forums.flightsimulator.com/t/live-dev-q-a-guided-question/370628/59?u=cptlucky8

 

Yeah, I think perhaps you are running into Asobo's contract with Microsoft.  This was alluded to in some of my posts about the flight model, that Microsoft was INSISTENT that their new flight model MUST work with/ devolve to FSX flight model per se for the sake of compatibility.  I imagine with a grand vision of being able to immediately use all the 3rd party resources out there.  Obviously, that failed mightily.  Granted, this is a gross simplification, but, the way I read it, Asobo's hands are somewhat tied, hence they are writing the horrible WASM interface you discussed.  They've now cleansed the flight model contract discussion supporting the basis of this thought from the latest SDK, and I don't know if they've deleted my verabatim posts on the forum.  But, I imagine this interface, which I agree is a mistake, is required by contract.  I could be totally wrong, but, that is the impression I got from reading the text in their SDK about how Asobo convinced Microsoft to move forward with Flight Sim.

Granted, as you point out, it would be in Asobo's best interest, now with 7 months of public use of the software out there, and reams and reams of discussion, to renegotiate that contract for the best interests of all involved.  Microsoft is paying for development, possibly in the millions of dollars, that is unnecessary, and holding development of the game back severely with resources that could be much better used elsewhere.  Maybe they are already discussing that renegotiation now?  Maybe I'm wrong?

On 3/13/2021 at 8:03 PM, ryanbatcund said:

You can get it from Navigraph for now for a fee.

Where?

 

edit : Sorry, I am tired, I was reading "for free"

Edited March 23, 20215 yr by bendead

Not gonna lie, reading the posts from @RXP is a bit depressing. Don't get me wrong, i believe all those things must be said, and i find them very valuable knowledge. What i mean is that it's a bit sad that Asobo doesn't seem open to these ideas, either because they don't want to or because they don't know about this.

In terms of user experience (well, at least, the intended user experience), FS2020 is better than FSX and P3D in my opinion. So i do believe that it is a step forwards. But it is a bitter sweet experience. It's going fairly well for now, with progress being made with each update, new features coming in... But one has to wonder how long will this keep going for. How long will the casual gamers stick around for? FSX and P3D have survived for so long because when the casual gamers got bored, the sim fans kept at it (not entirely true for P3D i imagine - not sure how much they depend on private sales). But the reason why sim fans could keep at it and milk the platforms for every last drop of capability was because developers were given sufficient access to keep the sim on life support with a constant supply of addons.

But what happens when you look at FSX and P3D and you think to yourself: "Those people are still playing this over a decade after release... There's money to be made here." but instead of catering to that loyal base you decide to make even more money by appealing to the casual gamer masses? What happens when those gamers get bored? Will you find that all the people you hoped would stick around have left because you didn't provide the very thing that got them staying in the first place: realism and an open platform? Or are you hoping you can ride both waves, and predict the leaving of the gamers and pivot to realism before that happens? What if you don't get the timing right? What if it's too little, too late? Who knows.

So reading all of these posts, it seems to me like MSFS is slowly turning into a missed opportunity, if it's not become one already. Credit where credit's due, Asobo have done a pretty stellar job considering their background. But they had so much potential to make this so much better. Talk to developers and actually listen to them. Talk to the people that have kept FSX and P3D going for so long, against all odds. The people that know what the community needs and what they're asking for. I believe they did this, but they haven't really learnt the correct lessons. Maybe Microsoft had them with one hand tied behind their back. Who knows.

Either way, i remain hopeful that we can turn this around somehow. Progress is being made, albeit slowly. Asobo have taken on the WorkingTitle guys, which is brilliant. PMDG have been in talks with them for quite a while now and they sound happy with the relationship so far, so hopefully that means we can get some actual study level addons. The community has managed to get Asobo to open channels with AIG, hopefully that proves productive. There is a non-trivial need in the community for realism, as evidenced by the success of improvement mods for default airplanes or for the default GPS units, as well as the excitement generated by JustFlight's Arrow III (although i am worried this might turn into regret as the community finds out that what they consider to be "study level" is anything but, and that actual study level addons are not toys). So there are some positives. Are they enough to outweigh the downsides? I suppose time will tell.

My two cents, anyways, not that anyone was asking for them.

Edited April 16, 20215 yr by Cristi_Neagu

6 hours ago, Cristi_Neagu said:

Talk to developers and actually listen to them.

Asobo have taken on the WorkingTitle guys,

Where is Waldo? Lol. 

Edited April 16, 20215 yr by Ricardo41

4 hours ago, Ricardo41 said:

Where is Waldo? Lol. 

Not sure what you mean by that. If you're referring to the fact that the pool of developers Asobo is in contact with is small, then that is a fair observation. Still, better than nothing. And listening to developers is not the same as accepting advice from developers. Despite the open channels, Asobo can still ignore them and do whatever they want, but i don't think that's the case.

3 minutes ago, Cristi_Neagu said:

 Asobo can still ignore them and do whatever they want, but i don't think that's the case.

Considering Asobos ability to ignore everything testers have told them in the past I would be far from confident of this.