WebAssembly

[mSparks 2,086]

30 minutes ago, GlideBy said:

I don't see any evidence that what I said was wrong.

In the links:

The main thread of the browser cannot execute the atomic.wait instruction, it will unconditionally throw an exception if this is executed. This means that, by default, mutexes will not work when contended on the main thread!

In English. Multithreading works, as long as you don't actually use it for anything.

This is "by design", have to protect the system from untrusted code DDS'ing the system.

30 minutes ago, GlideBy said:

After that you talk about unrelated things

SDK stands for "Software Developers Kit"

You know that right?

So why on earth do you think software and developers are unrelated to the SDK?

30 minutes ago, GlideBy said:

Keep it to MSFS 2020 and WebAssembly

vs

30 minutes ago, GlideBy said:

not javascript,

WebAssembly IS javascript (in its binary format)

https://en.wikipedia.org/wiki/WebAssembly

Quote

In order to use Wasm in browsers, users may use Emscripten SDK to compile C++ (or any other LLVM-supported language such as D or Rust) source code into a binary file which runs in the same sandbox as regular JavaScript code.

V8 is the name of the sandbox used by Chromium

dot net 5  is the new name of the sandbox used by Microsoft

And while its speculation that the two will not be compatible with each other since dot net 5 isn't due until Nov 2021, based on previous MSFT adherance to standardisation, there is basically no chance they will be.

Edited March 22, 2020 by mSparks

[MatthewS 761]

8 hours ago, mSparks said:

As a finger in the wind guess, even assuming it was possible (its not) compiling my AutoATC plugin to WASM would create a binary that is >5 gigabytes in size, require >20 gigabytes of ram, and run at one frame a minute instead of 200 frames a second.

I doubt it... but serve me up some of your spaghetti code and word salad.

[mSparks 2,086]

2 hours ago, MatthewS said:

but serve me up some of your spaghetti code and word salad.

 

[MatthewS 761]

@mSparksIt looks great.

Hopefully the FS2020 SDK ("Sim-Connect" ?) will give you all the control your program needs for the AI aircraft, I can't imagine you want to implement all that inside FS2020 natively as a WASM "add-in". 

Do the AI aircraft follow appropriate SIDS/STARS, that would be very nice!

 

Edited March 23, 2020 by MatthewS

[mSparks 2,086]

7 hours ago, MatthewS said:

Hopefully the FS2020 SDK ("Sim-Connect" ?) will give you all the control your program needs for the AI aircraft

plus weather, sound, graphics and the networking to tie it all together, the backend is a fully simulated persistent world capable of supporting about 1000-2000 simultaneous users with the ability to scale that up by adding extra nodes (currently serving about 10 people at any one time 24/7).

7 hours ago, MatthewS said:

Do the AI aircraft follow appropriate SIDS/STARS, that would be very nice!

Just out of the other side of "flight testing", so most of the important things in that thread for being able to conduct a flight now finished or nearly finished. VFR about perfect.

Next is procedure testing,

I was quite looking forward to the IFR feature discovery for some good ideas, delayed.

Currently AI and ATC vectoring is standard 5 or 10 mile (depending on weight class and nothing stopping you using sids/stars when not being vectored) approach patterns, switching that over to SIDS and STARS (when they exist, most of the worlds airports are not rated for IMC) is easy enough during this phase. ACARS and TCAS also a work in progress.

stuff like this:

https://github.com/mSparks43/XPlane-11-AutoATC-plugin/issues/43

To contend with first. Airport operations a lot more complicated than "just" the pattern to follow.

Throw in the plethora of WASM bugs into that - off putting to say the least.

I did actually look at WASM as an option back when I first started the project, but even simple tasks were so slow, memory heavy, unstable and difficult to debug that I gave up on that idea very quickly (straight after building hello world).

On the topic of multithreading, its worth noting that microsoft only implemented the C++11 multithread standard (which Ive been using in production as pthreads decades before they became a standard) last year or so in the visual studio toolkit - basically 25 years late.... But at least it now works well and isn't terrible.

Maybe I am just to used to MSFT promising high and delivering low. I will believe that has changed when I see it.

Edited March 23, 2020 by mSparks

[MatthewS 761]

7 hours ago, mSparks said:

I did actually look at WASM as an option back when I first started the project

C++ (not WASM) is the way to go because your system runs external to FS2020, I think WASM is mainly for aircraft makers so their "gauge" code can run in the FS2020 address space.

Me personally, I'd be using C# (.net core) because of the cross platform support (windows,mac,linux), but I guess you prefer C++.   I suspect cross platform support for C++ is probably a lot harder than C# (.net core).

I see you have a XP plugin, that's where I think for FS2020 you'd be using a WASM "plugin" (maybe write that in C# and compile it to "WASM"), so that FS2020 can connect to your AutoATC program.

 

7 hours ago, mSparks said:

Currently AI and ATC vectoring is standard 5 or 10 mile (depending on weight class and nothing stopping you using sids/stars when not being vectored) approach patterns, switching that over to SIDS and STARS (when they exist, most of the worlds airports are not rated for IMC) is easy enough during this phase

I think having (AI) aircraft fly appropriate SIDS/STARS would be a "killer feature" of AutoATC.

AutoATC looks great! I don't think Asobo are going into such detail.

Edited March 23, 2020 by MatthewS

[mSparks 2,086]

8 hours ago, MatthewS said:

that's where I think for FS2020 you'd be using a WASM "plugin"

pretty sure they are going the android route for the sdk only webassembly/javascript rather than C/C++/java.

i.e. the sandbox you get to run an addon in has no system or file permissions. (because xbox)

This is at least a step in the right direction of the sdk having no system, file or run permissions - which is what it was looking like before. But its taken google 14 years of intensive development to get that balanced to the point that every other developer isnt rooting their device.

8 hours ago, MatthewS said:

I think having (AI) aircraft fly appropriate SIDS/STARS would be a "killer feature" of AutoATC.

Good to know, I'll bump it up the priority list, was going to do it during the language overhaul anyway, but no reason "cleared for [SID] departure" and "cleared for [STAR] approach" with [SID] and [STAR] being required readbacks can't be first thing to do in that overhaul.

Edited March 24, 2020 by mSparks

[WarpD 824]

WebAssembly is not a viable approach.  It's restrictions actually makes doing complex avionics and aircraft almost completely impossible.  As example, you know that updated nav data that everyone relies on for their favorite aircraft/avionics?  WebAssembly won't be able to access any local file systems.  None.  Cancel the Navigraph subs.

There is a great deal of important data inside the real world ARINC navigational data format that is critical for complex FMS systems.  Even the Navigraph data content doesn't have enough information contained in it to support a Pro Line 21 FMS fully (as example).

I could go on and on... but honest... WebAssembly is probably a disastrous approach for anything more complex than the basic airspeed/altitude/VS type data.

[MatthewS 761]

On 3/28/2020 at 12:40 AM, WarpD said:

WebAssembly won't be able to access any local file systems

WASM does support a virtual file system so you will get access to whatever files you include in your VFS.

 

On 3/28/2020 at 12:40 AM, WarpD said:

Cancel the Navigraph subs

Presumably Asobo will provide access, via a SDK, to similar data that Navigraph supplies.  Now all addons could have a free source of up-to-date, cloud based nav data.

Edited March 28, 2020 by MatthewS

[WarpD 824]

You think obtaining the raw data from Jeppesen and LIDO is free as well?  That's where Microsoft/Asobo is getting it from... just like Aerosoft, Navigraph, RealNav... etc.  It's NOT free data.

[mSparks 2,086]

1 hour ago, MatthewS said:

Presumably Asobo will provide access, via a SDK, to similar data that Navigraph supplies.

Sounds plausible, only problem is the WASM spec/standard does not support this.

The current field leaders in breaking the isolation boundaries is GraalVM, and even they list WASM support as experimental/not fit for production

https://www.graalvm.org/

(they got Nashorn depreciated)

Would be quite the world changing event if MS adopted that, but they are more likely to try and do it all themselves with the inevitable consequences.

[MatthewS 761]

9 hours ago, WarpD said:

You think obtaining the raw data from Jeppesen and LIDO is free as well?  That's where Microsoft/Asobo is getting it from... just like Aerosoft, Navigraph, RealNav... etc.  It's NOT free data.

Who knows what the licence terms are, and if Asobo is allowed to make the data available via a SDK for use by FS2020 add-ins then it's basically free for the 3rd party devs.

[MatthewS 761]

13 minutes ago, Rob_Ainscough said:

Agree, lets hope MS/Asobo come back from COVID-19 safe and sound and thinking straight and make good on their word they are "working WITH thousands of developers" rather than just dictating what's going to happen ... because we already know what will happen if they persist with WASM.

Cheers, Rob.

Maybe WASM is just an alternative (and more tightly integrated option) to writing your add-on in C++ (or whatever) and using the "sim-connect" SDK.

They say legacy add-ons will still work, so they must still be supporting "sim-connect".

[mSparks 2,086]

3 hours ago, MatthewS said:

Maybe WASM is just an alternative (and more tightly integrated option) to writing your add-on in C++

WASM is compiled from C++ (or other languages), no one writes WASM directly.

Its an alternative to running native applications, where either the application writer or the user does not have permission to install on or even access the system (or all of the above such as with MSFS2020 on Xbox series X and Xbox PC Beta).

This is what makes it great for webpages (Web ASseMbly) where you don't want any old website installing anything they want on your computer or sending a copy of your "My Documents" out into the wild, but you do still want to be able to play games in your browser.

Edited March 30, 2020 by mSparks

[MatthewS 761]

4 hours ago, mSparks said:

WASM is compiled from C++ (or other languages), no one writes WASM directly.

Yes, sorry that's what I meant....  deploying your C++ logic as a WASM "add-in" might be more performant (same address space as FS2020) than when it's external code and using "sim-connect".

Presumably all the default Asobo aircraft logic is deployed as WASM (from C++ I imagine, but who knows, maybe they're using C# for that logic).

So if Asobo is using WASM then they must be very happy with it's performance.

Also, if your compiling to WASM there's no underlying speed advantage to C++ (since everything is compiled to WASM "byte code") so I guess that leaves developers free to use whatever language they prefer (eg C#) based on usability/familiarity considerations and not performance.