Hey, @Lorby_SI @SteveW a little refreshing course for your fellow simmers would be welcome here 😃 !

We also made lots of progress on WebAssembly support, which is the technology that will allow the porting of native code to our platform.

2 hours ago, domkle said:

Hey, @Lorby_SI @SteveW a little refreshing course for your fellow simmers would be welcome here 😃 !

We also made lots of progress on WebAssembly support, which is the technology that will allow the porting of native code to our platform.

Hello Dominique,

Sorry, can't really comment on this. As the snippet says, the WASM integration is not there yet. So there is no way of knowing what the actual implications will be.

https://webassembly.org/

This is pure programmers stuff. Speculating now: it will probably affect (replace?) all programmatic content (gauges, systems simulations, tools) that previously ran as a DLL inside of the simulator. Or something equivalent to the P3D PDK (=low level access to certain internals of the sim). But I really don't know.

Best regards

Edited March 13, 20206 yr by Lorby_SI

Interesting to note the reference to the new aircraft editor. Presumably this will be along the lines, if not better, than the one already available in another flight sim?

Normally we might program a web page with java script to do something, maybe run a game. That web page code can be run in a browser with the html or on the browser core with COM manipulated by a third party program. So that we see it in the browser or we see a window with perhaps a game run from a third party program, the same web browser core is in use. Very simply WebAssembly is a way to use the web browser core to run software written in regular languages rather than web code like javascript. This will be using the hardware available in the same way a desktop program will use it so as to be capable of best performance possible. Being on the web, the process already has good access to client server functions, for example being connected to Azure or some multi-user back end.

6 hours ago, domkle said:

Hey, @Lorby_SI @SteveW a little refreshing course for your fellow simmers would be welcome here 😃 !

We also made lots of progress on WebAssembly support, which is the technology that will allow the porting of native code to our platform.

Thanks Domkle for creating the new thread, I asked this question in the main update thread last night, but no one answered my question.

1 hour ago, SteveW said:

Normally we might program a web page with java script to do something, maybe run a game. That web page code can be run in a browser with the html or on the browser core with COM manipulated by a third party program. So that we see it in the browser or we see a window with perhaps a game run from a third party program, the same web browser core is in use. Very simply WebAssembly is a way to use the web browser core to run software written in regular languages rather than web code like javascript. This will be using the hardware available in the same way a desktop program will use it so as to be capable of best performance possible. Being on the web, the process already has good access to client server functions, for example being connected to Azure or some multi-user back end.

Thank you,  Steve and Oliver. So far I am with you (or I rather presumptuously think so). Lets suppose we have an avionics gauge written in C++ . Why would you use WASM to port it into a web environment ? Where would be the web environment in the future FS20 ?

Don't laugh at me if these questions don't make sense (don't laugh too hard anyway) and feel free not to answer if you would breach a NDA.

Edited March 13, 20206 yr by domkle

6 hours ago, domkle said:

We also made lots of progress on WebAssembly support, which is the technology that will allow the porting of native code to our platform.

From that I believe we can deduce:

The new MSFS SDK will mainly support custom code in high level, interpreted or JiT compiled languages. Maybe C# like Unity? Maybe Typescript?
That was probably done to increase system stability, so that a bad add-on wont crash the entire sim
However, the companies wanting to do a quick-ish port probably pushed back on that decision, leading to Asobo having to figure out a way to run legacy code in a sandbox
WebAssembly is one way to do that. Ignore the "web" part; it supports non browser embeddings.

1 minute ago, nickhod said:

From that I believe we can deduce:

The new MSFS SDK will mainly support custom code in high level, interpreted or JiT compiled languages. Maybe C# like Unity? Maybe Typescript?
That was probably done to increase system stability, so that a bad add-on wont crash the entire sim
However, the companies wanting to do a quick-ish port probably pushed back on that decision, leading to Asobo having to figure out a way to run legacy code in a sandbox
WebAssembly is one way to do that. Ignore the "web" part; it supports non browser embeddings.

Thanks Nick, the pieces of the puzzle come together now.

The regular browser is just a facility to use the same functionality.

A third party program can use the core in its own window.

In this case below an application is giving access to the VATSIM prefile page without the user having to run their browser and navigate. The form is pre loaded with instructions because the full web functionality is available without a browser running:

These techniques are evolving so that complex systems become easier to program. The same window could show a complicated gauge with or without connection to internet resources with full access to the hardware 3D graphics, sound and so on.

50 minutes ago, nickhod said:

From that I believe we can deduce:

The new MSFS SDK will mainly support custom code in high level, interpreted or JiT compiled languages. Maybe C# like Unity? Maybe Typescript?
That was probably done to increase system stability, so that a bad add-on wont crash the entire sim
However, the companies wanting to do a quick-ish port probably pushed back on that decision, leading to Asobo having to figure out a way to run legacy code in a sandbox
WebAssembly is one way to do that. Ignore the "web" part; it supports non browser embeddings.

That makes a lot of sense I think. Historically, allowing addons to run as unchecked code in the FSX process has been a source of stability problems - and when there's a crash, it can be hard to say what caused it.

Another reason could be future proofing. The code for FSX addons is tied to a particular processor architecture - Intel x86. WebAssembly runs on other processor architectures too, so it would allow an MSFS addon to run on a new architecture without having to recompile it.

From what I've been reading, and depending on how you look at it, there is a bit of a downside to WebAssembly. In the past, most devs who have made any even remotely complex aircraft have needed to write hooks to read values that the game does not expose. As WebAssembly modules run in a sandbox environment, I believe this significantly limits what a programmer can do outside of the API. This is great, as it prevents malicious activity. It's also bad, as it could limit innovation and really specific types of add-ons from being possible.

That said, if Asobo provides a proper API for all of the stuff devs have had to hook in the past (ex. weather and terrain data to create weather radar and terrain radar), it shouldn't be much of an issue.

6 hours ago, eaim said:

Thanks Domkle for creating the new thread, I asked this question in the main update thread last night, but no one answered my question.

Well, I answered you just a few hours ago, but you haven't read it yet... I basically same the same things that nickhod and Steve W wrote.

1 hour ago, n4gix said:

Well, I answered you just a few hours ago, but you haven't read it yet... I basically same the same things that nickhod and Steve W wrote.

I did read it, I then had to go out, thanks anyhow for answering.

33 minutes ago, Rob_Ainscough said:

That is false unless it's very simple processing or one interprets "porting" very very loosely.  I thought we're not supposed to talk about this level of detail here per NDA?

Cheers, Rob.

He's quoting the latest update from Asobo, so the statement itself isn't covered by the NDA.

16 hours ago, martinboehme said:

 

Another reason could be future proofing. The code for FSX addons is tied to a particular processor architecture - Intel x86. WebAssembly runs on other processor architectures too, so it would allow an MSFS addon to run on a new architecture without having to recompile it.

What kind of new architecture are you thinking of ?