1 hour ago, Ricardo41 said:

The sdk is ready as soon as an addon developer realizes the huge gap between his aspirations and his (emptying) bank account. 

This.

25 minutes ago, honanhal said:

The obvious answer is that Asobo has been making mistakes. No more, no less. Of course I’m going to criticize the critics if their arguments are incoherent. Seriously, what’s the theory? Complete this sentence: Asobo has been deliberately making performance worse because...

yep, spot on. its clear that MSFS is a behemoth for Asobo, for any studio for that matter. Mistakes were made, and are still being made as we speak. But that just mean they are going forward, they want to keep pushing the sim and then engine, they just want to do it fast, wich is not easy.

28 minutes ago, honanhal said:

The obvious answer is that Asobo has been making mistakes. No more, no less. Of course I’m going to criticize the critics if their arguments are incoherent. Seriously, what’s the theory? Complete this sentence: Asobo has been deliberately making performance worse because...

Tough to tell if its deliberate if this is related to getting ready for Xbox - I am sure they did not intend to mess things up this bad but if its trying to get ready for something down the road and wasn't properly shelved then to me it is sort of deliberate (but not wanted).   I get that studios are hesitant to give much detail on why something occurs.   But because we have been given basically no official information (we are looking into it) Asobo get rampant speculation.....

33 minutes ago, honanhal said:

The obvious answer is that Asobo has been making mistakes. No more, no less. Of course I’m going to criticize the critics if their arguments are incoherent. Seriously, what’s the theory? Complete this sentence: Asobo has been deliberately making performance worse because...

That's a straw man if ever I saw one...who here is suggesting that Asobo is deliberately making mistakes?  There's nothing to be gained by intentionally boogering up the simulator on a weekly basis...nobody is saying that the problems are intentionally caused.

What *is* the case is that they *are* boogering up the platform on a regular and recurring basis--UNintentionally, we can be sure, but it is undeniably happening nonetheless.  Theories on how/why that is the case do abound...haste, distraction with migration to XBox, incompetence, poor testing protocols etc.

Would love to be in the room to hear the key Asobo and Microsoft folks comments and reactions to reading this thread. Just flush out the real facts and get on to making more improvements for the sim or the game (whatever you prefer).

5 minutes ago, w6kd said:

That's a straw man if ever I saw one...who here is suggesting that Asobo is deliberately making mistakes? 

The post above yours literally starts with “Tough to tell if it’s deliberate if this is related to getting ready for Xbox.” But ok.

17 minutes ago, Doering said:

Would love to be in the room to hear the key Asobo and Microsoft folks comments and reactions to reading this thread. Just flush out the real facts and get on to making more improvements for the sim or the game (whatever you prefer).

They know how Avsim is so yeah, maybe they even now reading and eating popcorn as well 😂

35 minutes ago, honanhal said:

The post above yours literally starts with “Tough to tell if it’s deliberate if this is related to getting ready for Xbox.” But ok.

Deliberately making changes, for whatever purpose, is not the same as deliberately making mistakes, deliberately clobbering performance etc.  All changes are intentional...the consequences of those changes are not necessarily intentional.  But those consequences are still the responsibility of those making and fielding those changes.

That's what makes Microsoft's forced update models so pernicious--the user/customer is not afforded any sort of opt-out when the developer repeatedly forces clearly un/poorly-tested, broken platform modifications onto the user base. 

8 hours ago, RXP said:

the only technical reason not supporting DLLs and sandboxing add-ons is only to protect the market place DRM from hacks.

There are a lot more excellent reasons for sandboxed addons:

• Stability: This is probably even the main driver of the approach Asobo has chosen. Sandboxed addons reduce the complexity of the interaction and are much less prone to destabilize the core at runtime.
• Decoupling of components: You need nearly no IT knowledge to understand, that this is paramount in complex systems.
• Interaction over well defined and stable interfaces (rather than spaghetti interaction, I fear people using the word "hack" when talking about interaction between addon and a sim)
• All this results in simplified handling of new versions and enhancements

People who think, that the MSFS is doing badly in the area of NFTs should really not ask for lower level interaction between addons and the sim core...

Besides that, using the much more modern JS stack, the MSFS already supports addons in a very open and much more efficient way (efficient for devs).

@mrueedi I stand corrected, it is not just for DRM then! Thank you.

And I agree 200% with you about the JS stack and its actual implementation, to the point I'll repeat again, in case it was overlooked, I have been advocating early during the alpha/beta they let got the antiquated FSX area concepts infusing into the SDK, up into the JS/HTML layer. We're definitely on the same page I guess about this.

Loading in-process DLLs and offering a low level API is not detrimental to stability, decoupling, or stable interfaces either. The Prepar3D SDK is certainly offering this level of support to 3rd party and this doesn't pose any problem. The same with the XP11 SDK.

As matter of fact, it is even simpler with the UWP PC/Xbox ecosystem because there is a specific provision for this:
|Introduction to App Extensions | Microsoft Docs

Any ways, I'm not debating about the FS2020 SDK not offering the capability to loading DLLs, this is not what I'm talking about at all, really not.

I'll try to rephrase to make it clearer with a simple example:

XP11 Autopilot:

The SDK allows arming individually any of the 4 controllers, the simulator is managing the ARM->ENGAGE logic based on different inputs. The SDK also permits overriding some, if not most of the inputs values, so that you can trigger the logic to ARM->ENGAGE (say you arm HNAV, and you override NAV signal with a valid value, the logic ENGAGES HNAV). With this in mind, any 3rd party vendor can just use the strong implementation of the AP controllers using PIDs value you configure, and 3rd party vendors can build their own custom autopilot logic modes on top. For example, with the A320 Managed mode, you'd selectively disarm/arm the necessary controllers so that the autopilot is behaving logically as expected. The simulator is running the autopilot update and PIDs at the simulator rate/speed (which can be higher than the display rate).

Flight Simulator Autopilot:

The SDK is offering a logical view of an autopilot inspired from a Bendix King model. You can only ARM logical modes based on the autopilot bezel buttons available. If you ARM a lateral mode, it might disarm another mode because both are not meant to be armed together by the internal definition and implementation of the ideal BK autopilot system. For example with the A320 Managed mode, you have no other recourse than not using the stock autopilot, and you have to code direct activation of the control surfaces instead, with your own PIDs, your own logic. The gauge is running the autopilot update and PIDs at the gauge rate/speed, which is much lower than the display and the simulation rate, causing most control surface deflections and activation lagging behind, and therefore, making fine tuning PIDs even harder.

These are maybe NFTs but they are warrant to me for asking providing low level interaction with the simulator core:

- The XP11 example is low level access to low level simulator internal and functional simulation components, which you can interact with direct changes of its operating modes.

- The Flight Simulator example is user facing view of the autopilot component you can interact with, only with events which where meant only to bind a button on a cockpit gauge to the internal autopilot system.

 

These are not a question of programming language, of sandboxing, of not being able to inject the Garmin trainer whatsoever. These are just radically different concepts impairing, or favoring, 3rd party creativity.

 

PS: and to make it clear, from FS9 to P3D5 at least, the internal ideal BK autopilot system is exactly built on top of the 4 typical autopilot controllers. The SDK is shielding 3rd parties from directly accessing it (it is in sim1.dll if you're wondering)

Edited March 25, 20215 yr by RXP

Unless people stop insulting one another this topic will be locked. Treat others with respect. If you don’t the guilty ones will be taking an enforced holiday.

I think this thread has run its course! Hopefully the good, the bad and the ugly have sparked some positive momentum for future directions! 

3 hours ago, mrueedi said:

There are a lot more excellent reasons for sandboxed addons:

• Decoupling of components: You need nearly no IT knowledge to understand, that this is paramount in complex systems.

People who think, that the MSFS is doing badly in the area of NFTs should really not ask for lower level interaction between addons and the sim core...

Besides that, using the much more modern JS stack, the MSFS already supports addons in a very open and much more efficient way (efficient for devs).

I agree about decoupling, the problem is the way a lot of programmers use interfaces and OO in general, they are taught tight integrated OO at all costs because if it fits a design pattern in a book, then it must be better than any alternative. Since all programmers have different levels of organizational skills, naming convention ability, structural neatness, and on and on... The OO often ends up in a mess. For instance, #1 at my own work, no documentation. I am the only one that voluntarily creates documentation for anything I do that I consider complex, because what is quicker, deciphering someone's code without documentation and writing "test code" or just having a summary at your fingertips. Developers are hard headed, and there is a lot of bad advice online that re-enforces certain beliefs, they tend to overcomplicate things unnecessarily.

Someone earlier said what does "things working have to do with this being a game or not"
Everything, of course. The fewer things that work, the more of a "game" it is, the more things that work, the more of a SIM it becomes. It has potential to be a serious simulation, still regardless of the issues.

Edited March 26, 20215 yr by Alpine Scenery

10 hours ago, honanhal said:

The obvious answer is that Asobo has been making mistakes. No more, no less. Of course I’m going to criticize the critics if their arguments are incoherent. Seriously, what’s the theory? Complete this sentence: Asobo has been deliberately making performance worse because...

...they put too many irons in the fire.

12 hours ago, honanhal said:

The obvious answer is that Asobo has been making mistakes. No more, no less. Of course I’m going to criticize the critics if their arguments are incoherent. Seriously, what’s the theory? Complete this sentence: Asobo has been deliberately making performance worse because...

Hi James

I will not go back to what I have said before in this thread. Just one thing, the  word « obvious »that you use needs to  be backed up by facts 😉. I do not see facts backing it up.

The facts I do observe  :  Neuman in a Q&A said that they were full steam on the console, they have delayed the rewriting of the pitiful turboprop and garmin simulations for about 6 months (if we are lucky), the LOD has been reduced without any explanation and if I remember well (not sure here) refused to be acknowledged by Asobo in a Q&A, LW weather is still highly dysfunctional, and so on and so forth

There are « mistakes » all right. and there are « decisions » not to correct them as soon as they can. And the « obvious » reason is the Xbox rewriting. I will not be nice, sorry, but I do not care a bit about bringing a new audience to the sim (a sale goal dressed up as sentimental fluff) . I care about having my MFS in working order. I am entitled. And elitist.😆

 

Edited March 26, 20215 yr by Dominique_K