GTN650/750 updates?

[Howiefly13 30]

I just voted!

[espent 1,397]

2 hours ago, RXP said:

 

I've submitted this very question for the next Q&A and you might want considering voting for this:
https://forums.flightsimulator.com/t/live-dev-q-a-guided-question/370628/14?u=cptlucky8

 

I really appreciate your time and effort on this topic.

For this Q&A format - would it be better to list some concrete questions? It requires some preparations from the host to get to the meat of your posts, and having looked at previous Q&A's it does not always seem to be the case.

[RXP 2,338]

49 minutes ago, espent said:

would it be better to list some concrete questions?

You are right, unfortunately all my posts are locked and can't be edited. They were locked right after being posted. Discussing with another poster he told me his are also locked to him. In other words, each poster is seeing his own posts locked.

These are concrete questions but I don't find how to simply "resume" them to a simple sentence without loosing most of their meaning, because they are not simple questions either. I did try to highlight the exact questions in bold so that they are outstanding the rest, hopefully, so that the rationale behind each question can be reviewed easily thanks to the embedded links where I'm detailing the rationale behind each.

I'm still not sure about their new 4 topics limited Q&A mode. They are definitely trying out and will gauge whether this was beneficial and I'm wondering as well. What I can see is at least the new format is helping preparing questions better and it will help staying focused so that most of the Q&A time should be more valuable than before.

 

Edited March 8, 2021 by RXP

[Rocky 128]

I am happy that you are still there Jean-Luc, it has been a so long time since we didn't talk...

I didn't read everything but I fully agree with you on one point: the sandbox is certainly not a good idea. The fact that our gauges don't share the same space as the sim process is a pain. Why did they do this? For security reasons? I don't think so, how many people complained about security in FS2002, 2004, FSX, P3D? As far as I know, never.

Anyway, whatever we say, they will never change this in MSFS.

Eric

[marsman2020 1,310]

The big reason is likely the need to accommodate the X-Box platform where they need to ensure security.  Bugs in games can be used to break the security of the entire console.  There are likely rules about what games can do on X-Box and allowing random .dlls to run is probably in violation of those rules.

Edited March 8, 2021 by marsman2020

[Rocky 128]

You're certainly right. This Xbox compatibility will kill the spirit of the sim, which consists in giving all freedom to 3rd party developers, I regret this...

[fogboundturtle 2,708]

1 minute ago, Rocky said:

You're certainly right. This Xbox compatibility will kill the spirit of the sim, which consists in giving all freedom to 3rd party developers, I regret this...

No it will not. It will bring a breath of fresh air to the very aging population that still plays flight sims.

Edited March 8, 2021 by fogboundturtle

[Rocky 128]

3 minutes ago, fogboundturtle said:

No it will not. It will bring a breath of fresh air to the very aging population that still plays flight sims.

Don't get me wrong, I love MSFS and I enjoy flying so much that I cannot come back to FSX/P3D. But I clearly see that 3PD don't have the same abilities as before to develop add-ons, this is what I regret. I hope it will change in the future.

[fogboundturtle 2,708]

Well yes Rocky. It was the same when FSX/P3D came out. We need to give Asobo some times. 

[RXP 2,338]

@Rocky Hi Eric, long time no see indeed!

Last time we met it was great sharing a drink with you (10 years ago already 😲). So much has changed in the sim world since that time.

As for the sandbox, the Xbox, etc..

I have quite a personal opinion about all this of course (anyone has one) based on working for nearly 2 decades with systems and gauges with nearly all simulator versions since FS2002. (yes 02, not 20!), and this is best explained here

Quote

I can make the list way longer but the truth of the matter is that XP11, P3D5, FS2020 (to list only the latest) are not much different for many aspects, but XP11 has a clear differentiator in terms of SDK and I believe it is all rooted in a very simple explanation which shows clearly when you’ve been working in this industry for ages like me:

• The FS SDK originate from the internal private headers ACE studio (and maybe even before them) developers were using for developing the stock aircraft. The only need therefore was having access to pre-digested events and variable suitable to binding with a 3D animation or a panel gauge element. The first public SDK was just the same header files “sanitized” from internal private things. The idea most likely was if this was good for us building our own aircraft, it is good for 3rd parties building theirs. And today’s is not different: if this is good for Aerosoft building the CRJ, it is good for all developers (Jorg’s comment 2 Q&As ago).
• The X-Plane SDK originate from the same need to build aircraft but it was thought first and foremost for 3rd party developers, in a way which is not shielding the developer form the internal core simulation. Over time it has grown larger and bigger with an increasing number of simvars but few more API functions because of the simple reason there is no need for more: in giving access to low level API and constructs form the get go, there is no need for XPlane devs to provide add-ons developers with new functions anytime there is a need for something new, because the low level access already in place gives you access to this directly.

 

You can read the preamble and much more here:
Discussion: Live dev Q&A January - Community / General Discussion - Microsoft Flight Simulator Forums

This is why I believe you can't hope for:

"it was the same when FSX/P3D came out. We need to give Asobo some times."

Tthe SDK at its core is not leaving any place to evolve more than adding new simvars or new functions which would again pre-digest a data output to be consumed by a cockpit display or switch. In my opinion it needs a more profound paradigm shift, but the good news is that it doesn't require dropping everything to the trashcan, rather, it requires dropping the conceptual idea that an aircraft is the sole self-contained entity, and provide the necessary infrastructure to support this.

 

---

Here are more of my comments and opinion about the FS SDK:

As for sand-boxing regarding protection:

Quote

 

This is a good reason indeed, however, they’ve unfortunately left open a loophole allowing loading any DLL in the program at runtime, which in turns makes this whole “for security” reason obsolete from the get go.

Having a sandbox SDK allowing running the same code in both PC and Xbox is a good idea in itself. However this shouldn’t preclude offering supplemental means, just for PC, allowing 3rd party building more complex add-ons directly talking to the heart of the simulator and having full access to the OS features and graphics APIs.

 

https://forums.flightsimulator.com/t/aerosoft-comments-on-sdk-progress/305279/94?u=cptlucky8

NB: yes there is a loophole which permits loading any 3rd party DLL in the process space... I won't documented this publicly either.

As for some of the low level idiosyncrasies:

Quote

An example is the effort they are putting in reimplementing GDI+, on top of NanoVG, on top of their own low level blitter & path drawing api. I mean any 3rd party can do its own GDI+ bridge to ease porting his own FSX code so what is the reason behind Asobo allocating dev resources to re-implementing GDI+ if not making it faster for 3rd party devs? The problem is in doing so it is also not thinking outside the box of why is it nearly all 3rd party are using GDI+ to get started with [...]

Is MSFS built on FSX? - Community / General Discussion - Microsoft Flight Simulator Forums

 

As for the product positioning impairing third party creativity:

Quote

 

In effect, in the later case this makes us, PC users, freely offering our time and feedback to the team for them to iron out what is not working so that the title is ready and glitch free when the new XBox hits the market, with a Market Place ready to be preyed upon by thousands of gamers and filled with good looking addons.

This wouldn’t be complete without even asking the following: is there even any specific “target” audience in particular for this product?

• Is it a game first with some extra deeper features necessary to attracting simmers?
• Is it a simulator first with gorgeous eye candy for the gamers (and for the simmer nonetheless) ?
• Is it both from the get go with more emphasis to some of the features attracting one of the audience for now and the other features attracting the other audience will come later?

In any case, the simulator will be attracting a larger gamer base than a simmer base. This is a promise for more revenue opportunities for 3rd party vendors too, but if the product is a game masquerading as a simulator, what about the tools being offered to 3rd party vendors and how deep in system and simulation modeling can they go?

Simmers are a loyal and long term target audience which is attracting highly specialized vendors. They could be contributing to filling the Market Place for a long time even after the 10 years of services planned for fs2020. Gamers are cashing in until the new AAA game but until then they are bragging how great aviators they are (which they certainly are regardless - no judgment) and they are distracting away from PS5 and other competitive threats.

 

https://forums.flightsimulator.com/t/atc-incorrect-phraseology/240630/47?u=cptlucky8

 

Some reflection about aircraft and the SDK for simmers:

Quote

Simmers are accustomed to tweak and mix add-ons and unless the SDK is supporting the very idea of mixing things at the user editable level, you’ll face the same limitations. I’m a little sadden FS2020 didn’t take the opportunity to start anew with these antiquated concepts and monolithic aircraft vision, let’s hope this changes for the better in the future.

https://forums.flightsimulator.com/t/i-wish-there-were-more-steam-gauges-way-less-garmin-screens-all-over-the-place-what-do-you-fly/173902/191?u=cptlucky8

 

[fogboundturtle 2,708]

@RXPI am sure you understand how injecting DLL from an external source can be seen as a security threat.  It is something that is not compatible with the Xbox eco system. So the SDK needs to be improve to allow more complex function but to think we can go back to injecting DLL is not going to happen ever.

[RXP 2,338]

@fogboundturtle Nothing precludes the PC version, and just the PC version, to supporting external DLLs. It is not the Xbox ecosystem which is preventing this, but the voluntary choice of not doing so. Now the reason, be it stability or otherwise related to the user experience is not the main reason behind this decision in my opinion. I believe it is something they are imposing on themselves only because one main central piece of the product is not the simulator but the market place, and any "foreign" DLL may pose a risk for the DRM. XP11 and P3D5 are loading DLLs plugins and this doesn't pose any particular problem of stability or performance otherwise. But the very idea to sandboxing to prevent this is all moot anyhow because they have forgotten a loophole in their implementation which permits loading any 3rd party DLL anyhow (and I'm not talking about system wide hooks, nor WASM security issue).

In choosing a sandbox approach, I believe it is mandatory getting rid of the antiquated SDK constructs which are limiting and more often than not workaround with in-process hacks, but I also believe they are focusing with a select few partners which are not at all expressing nor dealing with such questions for now, due to the nature of their products and their own understanding and use of the FS SDK. I'm certain I also have a rather unique point of view to these questions due to the unique nature of my products (not that they are based on the trainer, but the fact they are interfacing with any 3rd party aircraft and are controlling the FS entrails like overriding the autopilot for example). Besides, I also have a deep knowledge about how the FS SDK and the FS code is implemented because I've been doing this for ages by necessity. For example, I'm not surprised you can't display the F/D bars in FS2020 unless you also engage an A/P mode... This is a flaw which I attribute to the very way they have designed the A/P <-> F/D code architecture which causes this, and I can tell you the same C source code is used as-is from FS9 to P3D5, and given how it is behaving in FS2020, I believe this is the same code running as-is too, like the 10 deg increment bug known since FS9 (and documented at avsim - see https://forums.flightsimulator.com/t/is-msfs-built-on-fsx/332959/9 ).

However I'm not saying all this is bad in itself, I'm just raising a few questions, which I've posted at the FS2020 forums (links above) but for the sake of making this very clear in one place:

Quote

Having said this, it is also important to note Asobo did a marvelous job with the gauge and system “interface” in the form of the JS/HTML layer. I still don’t understand why they are not just documenting and solely focusing on this layer* instead of trying to build the legacy SDK bridges to WASM, with a pseudo GDI+ on top of NanoVG on top of their own bare bone (but sufficient) path tracing API. [...] Although the points I’m listing above are conceptual, it doesn’t diminish at all the great work done with the JS/HTML implementation and I want to make it clear: the FS2020 Gauges and Systems SDK is just the same as in FSX with less possibilities for 3rd party developers because of sandboxing. But the FS2020 Gauges and Systems JS/HTML Interface is the modern foundation I’d expect they document and I’d like they focus on with the 3rd party vendors. This new foundation is still however based on a certain vision of the 3rd party developer needs and methods which is still strongly infused by old FSX standards and there is not much to do to open this to more capabilities. There are notably a few core concepts needing slight changes, not hard to implement nor disruptive to the whole, which would radically help breaking some of the hard-limits 3rd parties are struggling with since FS9 at least. I’ve no doubt they are actively working everyday with a select few developers but the lack of transparency is in my opinion really hurting a lot of other 3rd party developers eager to help contributing to the franchise success.

 

Edited March 9, 2021 by RXP

[fogboundturtle 2,708]

I agree with you and you raise some valid concern but I do believe that external injecting is a thing of the past and we have to adapt to the reality of today's SDK. Now in return Asobo has to provide the proper functionality to let dev perform the same function as before.

[RXP 2,338]

1 minute ago, fogboundturtle said:

I do believe that external injecting is a thing of the past and we have to adapt to the reality of today's SDK. Now in return Asobo has to provide the proper functionality to let dev perform the same function as before.

I beg to differ "slightly", it might just be semantics, yet: we need to detour code, not inject DLLs, in all FS versions, because there are bugs we are correcting (the RXP products are for example patching FS9 so that one of its SDK function works, otherwise it won't), because there are features not available in the SDK (like overriding the XML vars and the autopilot). Gauges are DLLs and are loaded by the simulator, not injected.

Therefore, "providing the proper functionality to let dev perform the same function as before" poses a problem, because if before you couldn't override the XML variables, tomorrow you won't either, because no other 3rd party vendor than RXP has a need for this, and as long as they are considering the only need is the one a select few vendors they are working daily with, they won't know more either.

And this is where I'm not thinking of augmenting the FS2020 with features for RXP only, I'm thinking of deeper architectural concepts which would not only benefit RXP of course, but any other 3rd party vendor. And I can tell you most of these idea come from my intimate knowledge of both the FS and the XP SDKs. Because there remain 1 essential question you might be wondering in terms of SDK architecture and capabilities for 3rd parties:

Why is it the implementation of the RXP products in any Flight Simulator version requires augmenting the SDK with missing functionality, whereas the RXP products are implemented on X-Plane with the same level of functionality, and even more, in just using the X-Plane SDK without any hack whatsoever?

This is where I'm getting at too: as long as Asobo is working daily with 3rd party vendors from the FS world and imposing their view on how to develop an aircraft, it will never let them think outside the FS box and understanding the greater needs of all other 3rd party vendors.

 

[fogboundturtle 2,708]

I get your point RXP. I get these type of discussion everyday. I work as an Integration solution architect. There is always a tug of war between what the dev wants to do and the standard you want to maintain. There is a balance to be strike and MSFS has not reach that balance yet.