1 hour ago, eaim said:

we just don't yet fully understand how or what we can do with MSFS going forward

And those who fully understand first-hand would most likely also be bound to an NDA and can't discuss it either...

Frankly, I think developers who have not worked with WASM underestimate it. WebGL is available inside WASM, which is more than sufficient for even extremely detailed gauges. Canvas would be just fine for a lot of uses, even.

You can make DirectX surfaces available to GL via sharing mechanisms, so the fact that MSFS is a DX engine isn't even a deal breaker there.

Do I think this will land on day one? Not necessarily. But there's no real technical limitation I can think of. Just that of time.

10 hours ago, kaha said:

Not only because they cannot do it outside but also because they would have to use an interpreted language versus a compiled one.

Karl

You can write entire game engines that run inside WASM. The whole bogeyman about compiled vs interpreted is just no longer relevant today. And, in any case, WASM is compiled to universal bytecode, which is then compiled just in time to machine code when first executed. If the full WASM experience is supported, I could write a G1000 that plays the entirety of DOOM at 60fps inside MSFS and not have the machine break a sweat.

For the types of operations most likely used by aircraft designers: hashmaps, array lookups, float and vector math, systems sim type stuff, it's really no different in performance to C or C++, not in any practical way that will matter to an experienced developer.

Edited July 23, 20205 yr by MattNischan

5 minutes ago, MattNischan said:

You can write entire game engines that run inside WASM. The whole bogeyman about compiled vs interpreted is just no longer relevant today. And, in any case, WASM is compiled to universal bytecode, which is then compiled just in time to machine code when first executed. If the full WASM experience is supported, I could write a G1000 that plays the entirety of DOOM at 60fps inside MSFS and not have the machine break a sweat.

For the types of operations most likely used by aircraft designers: hashmaps, array lookups, float and vector math, systems sim type stuff, it's really no different in performance to C or C++, not in any practical way that will matter to an experienced developer.

Its interesting. I know a few flightsim programming types who (very quietly!) also say the same thing, but are not interested in drama, and having the wrath of God come down on them for expressing that opinion.

 

17 minutes ago, MattNischan said:

I could write a G1000 that plays the entirety of DOOM at 60fps inside MSFS and not have the machine break a sweat.

Ummm, have you submitted your resumé?  Your help may be needed. 🙈🙉🙊

31 minutes ago, MattNischan said:

If the full WASM experience is supported, I could write a G1000 that plays the entirety of DOOM at 60fps inside MSFS and not have the machine break a sweat.

I hope you apply for the partner program. That would make cruising along at FL300 much more fun. 🙂 

To me it seems as though the shortcomings of FSX / P3D are now represented as a feature by some.

To my understanding the reason why high quality aircraft like the Majestic Q400 or the FSL Airbus are working outside the sim is not because the developers chose so for their convenience and FSX / P3D generously provided them with this option. In contrary the developers were forced to create their models outside the sim as a workaround because FSX / P3D's own means regarding systems and aerodynamics are so limited that it's not possible to create a high quality aircraft within FSX / P3D's own means.

And these external workarounds are also the reason why many addons break with every incremental update of P3D and need to be updated each time.

At least this is how the developers always advertised their products.

 

In contrast to that I haven't seen any aircraft developer complain yet about restricted possibilities in MSFS. On the contrary those who already gave statements sounded quite enthusiastic and said they won't just port over their aircraft but want to take their time to take full advantage of the possibilities of the new sim.

So just maybe the means that come with MSFS now provide everything the developers need to create a high quality aircraft, without the need to workaround limitations of the sim by creating own external systems that should have been included in the sim itself in the first place.

And just maybe the lack of external workarounds will lead to a more stable and better performing sim and to addons remaining compatible after updates of the main sim.

 

Of course addon developers now have to adapt to the new means and that will probably take them some time. But that doesn't necessarily mean that this change is a bad thing - at least not for those who are ready to leave their comfort zone for something new and not see every change as a threat.

 

33 minutes ago, RALF9636 said:

In contrast to that I haven't seen any aircraft developer complain yet about restricted possibilities in MSFS.

While I generally agree with what you've said, no developer has praised the SDK in its current state.  It has been quite the opposite.

I'm not sure how this could happen, as there has to be an internal SDK in order to make anything for the sim.  Otherwise, how would the internal developers know how to make it?

Hook

Interesting to hear arguments that go against the grain of what we have heard so far that I would sum up in « Impossible to build high end aircraft in FS20 as the programming environment is made for a console game » .  

 

6 hours ago, MattNischan said:

Frankly, I think developers who have not worked with WASM underestimate it. WebGL is available inside WASM, which is more than sufficient for even extremely detailed gauges. Canvas would be just fine for a lot of uses, even.

You can make DirectX surfaces available to GL via sharing mechanisms, so the fact that MSFS is a DX engine isn't even a deal breaker there.

Do I think this will land on day one? Not necessarily. But there's no real technical limitation I can think of. Just that of time.

You are missing a key point. None of those features will be available in MSFS WASM unless MS decides to give access to them. And unlike P3D and FSX, where we can resort to low level code injection and hooks to get what we want if we need to, WASM explicitly prevents circumventing the SDK features.

3 hours ago, JB3DG said:

You are missing a key point. None of those features will be available in MSFS WASM unless MS decides to give access to them. And unlike P3D and FSX, where we can resort to low level code injection and hooks to get what we want if we need to, WASM explicitly prevents circumventing the SDK features.

It would make zero sense for MS and Asobo to limit this functionality. Can individual add-ons go around overwriting process memory anymore? No, they can't. That's, honestly, a feature and not a bug.

However, what I'm describing isn't even far fetched. Google's ANGLE, which is entirely open source, already translates WebGL2 to DirectX 11, and does it every day in Chrome for millions and millions of users. If you load an WebGL Unity game in Chrome, guess what, that's getting translated right to DX. And that's more graphical and processing complexity by far than any aircraft gauge I've ever seen in FS. ANGLE is even a whole separate project that could be dropped anywhere that needed this functionality.

I just don't think it's realistic to think that they're not thinking of these things, especially when proven solutions already exist in the wild. I think the issue has been time, and that the SDK hasn't been the primary focus. It seems MS is OK with letting the SDK grow after release, which makes sense to me, honestly. The entire build chain and interfaces are totally different, so any aircraft will be a full port; meaning there's time to add functionality over the next year as developers slowly get up to speed, all the while getting the sim in the hands of future add-on customers early and cementing a good customer base.

I’m confident MS/ASOBO will do a good job on that matter. If current developers can’t cope with those standards, others will. Life finds a way. 😂

Only time will tell.

7 hours ago, LHookins said:

I'm not sure how this could happen, as there has to be an internal SDK in order to make anything for the sim.  Otherwise, how would the internal developers know how to make it?

Larry, it's not so much the tools but rather the documentation that's incomplete. Obviously the people who created the tools already know how to use them, and additionally it wouldn't take too long to teach a few others to use them for that matter.

But, they need to write comprehensive and comprehensible instructions on usage of those tools for everyone else to learn from!

6 hours ago, JB3DG said:

... WASM explicitly prevents circumventing the SDK features.

I don't know to what extent this goes but from my user's perspective that seems to be a good thing because it hopefully prevents the complete mess of addon installations I have now in P3D, where every addon installs - and updates - in a different way, into a dozen different locations and configuration files all over the place.

I would appreciate very much if MSFS forced 3PD into a standardized method. Might cause some inconvenience for 3PD but would save users from a lot of troubles.

 

I would love to see a MSFS2020 C-17 from Milviz!

 

Come on guys!!!!