14 minutes ago, tweekz said:

While some complain, others are creative.

Whilst there is a fair bit of truth in that, it is worth bearing in mind that stuff such as the WT and FBW mods are very much a case of enthusiastic labours of love. This is not to say they are not skillful, but these development collectives are not limited by any published product schedules, labour costs, nor the requirement to deliver a product people have rights to because they paid for it. That's a very different proposition to what a commercial developer has to consider.

I'm not about to get my tiny violin out for Robert Randazzo's woes, but I think it's only fair to acknowledge that its a bit more tricky to plan a profitable development of a complex add-on airliner over several working years than it is to gather a bunch of enthusiastic friends on Facebook and say 'Let's see if we can tart up this already existing A320 a bit'.

As I've already pointed out elsewhere, one big problem for quality payware developers is the current fluidity of the sim and its interfaces.  We've seen the complex amateur add-ons stop working whenever Asobo push out an update, and the pressure users put on them to get them fixed.... and this is freeware.  Updates are not optional on MSFS, as they were on P3D. There's no way a top-line company charging top-line prices is going to sell an add-on that they know will stop working every few weeks.

10 minutes ago, lzamm said:

We've seen the complex amateur add-ons stop working whenever Asobo push out an update, and the pressure users put on them to get them fixed...

This is another misconception. FBW/WT etc. mods keep breaking with every update due to their design choices: In order to not have a duplicate aircraft and be non-invasive they override some of the default aircraft files using MSFS VFS and rely on rest of the default aircraft files. When these files get updated by Asobo, it is highly likely that some important functions implemented by FBW/WT etc. will get overriden, or some default functions relied by these mods won't work as expected, causing aircraft to break. This will not happen with an aircraft made from scratch.

Edited February 16, 20215 yr by BiologicalNanobot

31 minutes ago, BiologicalNanobot said:

This is another misconception. FBW/WT etc. mods keep breaking with every update due to their design choices: In order to not have a duplicate aircraft and be non-invasive they override some of the default aircraft files using MSFS VFS and rely on rest of the default aircraft files. When these files get updated by Asobo, it is highly likely that some important functions implemented by FBW/WT etc. will get overriden, or some default functions relied by these mods won't work as expected, causing aircraft to break. This will not happen with an aircraft made from scratch.

We do plan on making it a completely separate aircraft - it's currently in progress. The main thing holding this back is our installer - currently, updating your installation re-downloads the entire mod, leading to long download times and more usage on our CDN services (and therefore, more money being spent on them). Hard-forking from the A320neo means the A32NX package size would greatly increase, making this more noticeable. We plan on implementing functionality to only download new files/changes when updating, then we will finalize our hard fork.

1 hour ago, BiologicalNanobot said:

However, I would not call PMDG/FSLabs etc. "whining". They gain literally nothing by delaying their aircraft - I would not be surprised if they are as eager as we are to see their aircraft in MSFS. Transforming code from one environment to another takes a lot of time and resources, almost as much as making a new aircraft from scratch. It makes a lot more sense for them to wait for Asobo's compatibility layer, which will "convert" legacy API calls to MSFS API calls.

It's tricky, because I think waiting for an "easy" porting solution is an understandable and defensible business decision if you're PMDG or FSLabs -- maybe the only defensible decision. But ultimately they're placing a bet on what's going to happen here. That bet is premised on a few things being true:

1) Asobo will give us a porting solution in relatively short order (i.e. less than a year out).
2) That porting solution will work, will be cost effective for us, and will not create additional headaches.
3) Other developers (especially ones with no legacy code "baggage") will not beat us to market and eat our lunch.

I'd argue that any or all of those propositions could turn out to be mistaken, which is where the risk comes in. (That's what profit is for, remember.)

The basic formula they're balancing here is at what point the lost revenue stream (with their P3D sales having dropped off a cliff and with no new MSFS product offering) exceeds the costs of starting "from scratch" (not really, of course) with the new development environment -- with the key curveball that there's no certainty of when, or even perhaps, if, Asobo is going to drop an easy porting solution into their laps, that would at a stroke completely upend those calculations.

And of course, that's all from the developer's perspective. As a customer, if someone who's not PMDG or FSLabs puts out a high-fidelity Boeing or Airbus in June 2021, I'm most likely going to buy the one that comes out first. And if PMDG or FSLabs thinks there are no developers out there who can pull that off, they're a lot more confident than I would be.

James

36 minutes ago, BiologicalNanobot said:

This will not happen with an aircraft made from scratch.

I partly agree with your post, but I think current evidence does not support your conclusion. Updates have regularly broken basic aspects of MSFS as often as they have broken add on developments.

Interesting discussion. I don’t see the logic in Aerosoft making their bus for this sim anymore. Fsl is a different story of course.

13 minutes ago, Ilari Kousa said:

Interesting discussion. I don’t see the logic in Aerosoft making their bus for this sim anymore. Fsl is a different story of course.

Tempted to agree but Aerosoft offers the full A318-A321 (CEO) package for P3D. FBW is 320 Neo only. Nonetheless, FBW's growing functionality removes an awful lot of the reasons for buying the Aerosoft bus.

2 hours ago, BiologicalNanobot said:

I don't think MSFS SDK has any limitations that prevents complex airliners except weather radar.

This is a huge misconception I see everywhere: "Aerosoft CRJ and QualityWings 787 are coming sooner than PMDG/FSLabs etc. aircraft because they are not as complex", which is not exactly right.

If you look at FSX/P3D/X-Plane SDK, you'll see that default systems are quite simple and do not allow creating complex airliners. All of the complex aircraft you see in those simulators do not use default systems at all. This means all of the complex behavior should be simulated by the aircraft developer, not the simulator itself, which means what determines the aircraft complexity is the code aircraft developer writes, not the SDK. In order to accomplish this, simulators provide aircraft developers an environment where they can run their custom code, which has no limitations. MSFS provides that in the form of WebAssembly and HTML/CSS/JS, so developers can code any behavior to make their aircraft true-to-life.

I guess many people think that these SDKs have an interface where you configure all sorts of complex systems, failures etc. and when PMDG/FSLabs etc. say that MSFS SDK does not support complex aircraft they assume MSFS lacks those interfaces, which is not the case - FSX/P3D/X-Plane SDKs do not have such interfaces and all of the complex aircraft behavior is determined by code, which is unrestricted by the simulator.

However, I would not call PMDG/FSLabs etc. "whining". They gain literally nothing by delaying their aircraft - I would not be surprised if they are as eager as we are to see their aircraft in MSFS. Transforming code from one environment to another takes a lot of time and resources, almost as much as making a new aircraft from scratch. It makes a lot more sense for them to wait for Asobo's compatibility layer, which will "convert" legacy API calls to MSFS API calls.

Just wanted to add a bit more detail to my post, and clarify why as long as there's a coding environment there wouldn't be any restrictions. A coding environment consists of a programming language with support for arithmetic and logic operations. As long as these operations are there, any functionality can be built upon them.

For instance, let's take a look at custom system implementations for determining control surface deflection. (Disclaimer: This is really simplified to make the point, this is not necessarily the way aircraft calculate control surface deflection)

An aircraft which is simpler on the systems would:

• Read control input from the simulator
• Scale it by a factor
• Write control surface deflection to the simulator

While a more complex aircraft would:

• Read control input from the simulator
• Calculate the force transmitted through hydraulic lines
• Calculate the force transmitted to the actuators
• Calculate how much control surface deflection would that force cause
• Write control surface deflection to the simulator

Here's the thing - only interactions between the simulator in both cases are the first and last items - reading/writing from/to the simulator. Rest (intermediate calculations) are up to the developer, and they are what makes an aircraft add-on simple or complex. As discussed before, MSFS provides a coding environment which supports arithmetic and logic operations, so there's nothing preventing developers from performing these intermediate calculations.

This is why "Aerosoft CRJ and QualityWings 787 are coming sooner than PMDG/FSLabs etc. aircraft because they are not as complex" rumors are misleading. As MSFS SDK provides developers a coding environment which supports arithmetic and logic operations, the only roadblock would be the first and last items (reading/writing from/to the simulator), which are shared by both simple and complex aircraft. This means such a roadblock would prevent all add-on aircraft with custom systems (including FBW/WT mods, Aerosoft CRJ and QualityWings 787) from being released, not only the complex ones. Given that FBW mod has a custom FBW and autopilot, this is not the case either.

Edited February 16, 20215 yr by BiologicalNanobot

Let me say it clearly: I didn't read the whole thread (3 pages) so please excuse me if I say here things that were already said.

I am a developer and I worked on several products that were released mainly by Wilco, the most famous being the Wilco Airbus Series, so I know what I am talking about when it is about SDK and Flight Sim realted development.

IMHO, the problem with MSFS2020 is not the SDK. I remember the old days of FS2002/2004 when I started add-on development, the SDK was poor and needed to be deciphered to be understood. For me, the MAIN problem is that Microsoft and Asobo decided MSFS must run on PC and Xbox, so you don't develop in Windows anymore. This is a HUGE difference. Previously with fs9/FSX/P3D, advanced aircraft (esp. liners) were developed by coding DLLs in the Windows environment. An panel gauge is a DLL, nothing else. It means that we could use all the Windows API: GDI+ for displays, read/write files, read navigation database, interact with external application/external devices, interact with the sim itself through Windows-based machanisms, ... In addition, the way add-ons were defined provided a full independance between the 3D model and the panel, you could have a PMDG 737 aircraft to fly a Cessna if you wish. This was very convenient from a developer standpoint.

In FS, what makes the difference between a basic steam-gauge aircraft such as Cessna and an advanced liner such as 737?
The difference is in the systems, all the advanced systems, FMC, trajectory calculation and prediction and usage of an AIRAC navigation database that is always up-to-date. With MSFS and the new Web Assembly (WASM) logic, you can NOT do this anymore: no possibility to read an external database, no use of registry, no use of socket or other IPC mechanism, no possibility of "modules" (DLLs that are loaded when the sim starts, not related to a specific aircraft), strong link between model and panel, ... I certainly forget many things that we could do with the Windows API and we can't do anymore. Not to talk about the stability of the sim, at each update we have add-ons or mods that don't work and need to be re-adapted, not good for software developers.

Why do you think PMDG says they will release their first product in 1 year? Do you think it is because they are happy to stop making money for 1 year? No, this is just because they CANNOT do things that were easy to do with FSX/P3D, especially with the expertise they have. Things that were possible are not anymore, for me it is clear that Microsoft/Asobo decided to "close doors" that were opened before, certainly because they were scared that add-on developers mess up their sim.

They are wrong, definitively wrong, opening more doors to add-on developers will give more power and more success to their sim, the history of Flight Simulator since FS5.0 with Flight Simulator Flight Shop showed this. 

25 minutes ago, Rocky said:

Previously with fs9/FSX/P3D, advanced aircraft (esp. liners) were developed by coding DLLs in the Windows environment. An panel gauge is a DLL, nothing else. It means that we could use all the Windows API: GDI+ for displays, read/write files, read navigation database, interact with external application/external devices, interact with the sim itself through Windows-based machanisms, ... In addition, the way add-ons were defined provided a full independance between the 3D model and the panel, you could have a PMDG 737 aircraft to fly a Cessna if you wish. This was very convenient from a developer standpoint.

In FS, what makes the difference between a basic steam-gauge aircraft such as Cessna and an advanced liner such as 737?
The difference is in the systems, all the advanced systems, FMC, trajectory calculation and prediction and usage of an AIRAC navigation database that is always up-to-date. With MSFS and the new Web Assembly (WASM) logic, you can NOT do this anymore: no possibility to read an external database, no use of registry, no use of socket or other IPC mechanism, no possibility of "modules" (DLLs that are loaded when the sim starts, not related to a specific aircraft), strong link between model and panel, ... I certainly forget many things that we could do with the Windows API and we can't do anymore. Not to talk about the stability of the sim, at each update we have add-ons or mods that don't work and need to be re-adapted, not good for software developers.

This is not exactly true. A gauge still works the same way it works in FSX/P3D, just in an isolated/sandboxed environment. While Windows APIs, GDI+ etc. are not available anymore, Asobo supplied alternatives with same functionality. GDI+ is replaced with NanoVG, file IO works if you use MSFS VFS and you can still interact with the simulator, SimConnect still works the same way as before, ...

You can still read an external database. As said, file IO works if you properly load required files to MSFS VFS inside a module. I don't think an add-on has to mess up with Windows registry. Independent modules are also supported, you can load WASM modules separately from the aircraft, check the SDK documentation. While networking is not possible, an external program can still signal a WASM module using SimConnect.

So it is possible to create a complex aircraft, just not the same way as before.

Edited February 16, 20215 yr by BiologicalNanobot

1 minute ago, BiologicalNanobot said:

This is not exactly true. A gauge still works the same way it works in FSX/P3D, just in an isolated/sandboxed environment. While Windows APIs, GDI+ etc. are not available anymore, Asobo has supplied alternatives. GDI+ is replaced with NanoVG, file IO works if you use MSFS VFS and you can still interact with the simulator, SimConnect still works, ...

You can still read an external database. As said, file IO works if you load required files to the MSFS VFS as another module. External modules are also supported, you can load WASM modules separately from the aircraft, check SDK.

I am glad to read this. Then I need to read the SDK more deeply because I couldn't find the way to do this. I really think the SDK is not clear enough, this is a personal point of view.

But if I push a bit further, I developed drivers for hardware devices from CPFlight and CockpitSonic, they use sockets, and I still didn't find a way to develop the same for MSFS.

30 minutes ago, Rocky said:

With MSFS and the new Web Assembly (WASM) logic, you can NOT do this anymore: no possibility to read an external database, no use of registry, no use of socket or other IPC mechanism, no possibility of "modules" (DLLs that are loaded when the sim starts, not related to a specific aircraft), strong link between model and panel... for me it is clear that Microsoft/Asobo decided to "close doors" that were opened before, certainly because they were scared that add-on developers mess up their sim.

They are wrong, definitively wrong, opening more doors to add-on developers will give more power and more success to their sim, the history of Flight Simulator since FS5.0 with Flight Simulator Flight Shop showed this. 

I appreciate you taking the time to explain the problems a little more thoroughly; so essentially most things are possible but they have to be self-contained within the aircraft which could mean major code changes for existing products. And moving to new techniques to achieve the same results, e.g. NavoVG replacing GDI+.

I think it was security concerns as much as compatibility across platforms that drove the decision to stop use of Windows API for third party dlls and replace with WASM; there can't be many (any?) games these days that would let you execute code without restriction to modify the system registry! I also believe that with the sim evolving so much over time, it is better these things run within the sim rather than trying to externally hook-in as it makes core updates less likely to break addons.

Edited February 16, 20215 yr by ckyliu

8 minutes ago, Rocky said:

I am glad to read this. Then I need to read the SDK more deeply because I couldn't find the way to do this. I really think the SDK is not clear enough, this is a personal point of view.

But if I push a bit further, I developed drivers for hardware devices from CPFlight and CockpitSonic, they use sockets, and I still didn't find a way to develop the same for MSFS.

SDK documentation is still rather bad, so sometimes you need trial-and-error. The WebAssembly part explains it slightly:

(https://msfs-sdk-docs.netlify.app/04-developer_tools/webassembly/)

And yes, lack of networking is kind of a bummer. In your case, I think it is possible to use an external software which can send commands using SimConnect to a WASM module to get it to work.

Edited February 16, 20215 yr by BiologicalNanobot

8 minutes ago, BiologicalNanobot said:

SDK documentation is still rather bad, so sometimes you need trial-and-error. The WebAssembly part explains it slightly:

(https://msfs-sdk-docs.netlify.app/04-developer_tools/webassembly/)

And yes, lack of networking is kind of a bummer. In your case, I think it is possible to use an external software which can send commands using SimConnect to a WASM module to get it to work.

Indeed, SimConnect might be the right solution here.