Update from PMDG

[ErichB 3,638]

Give it a break people. 

[EGLD 436]

4 hours ago, wthomas33065 said:

Actually legally that is false.

 

I'm sure Chocks doesn't need me to answer for him, but I highly doubt his comments are made in a legal context.

But more in a reputational, customer loyalty, professionalism context - these things are important to software companies, and it's right as consumers that we point out when they have come up short.

[F737MAX 5,507]

Everyone's a lawyer here it seems...

PMDG has decided that the MSFS SDK is in no fit state to spend time (i.e. money) on bringing their current products into the new sim for some time.

What's great (for them) is that on top of the BBJ expansion pack, there's at least one more huge paid upgrade product that they can bring to P3D in the shape of the 777, to bring it to a similar standard to that of the 747 and 737NGXuzwxyz. There will be plenty of interest from those desperate to get their GE90 fix with PBR and EFB added.

Whatever happens, P3D has another year of PMDG jetliner exclusivity.

[HighBypass 2,339]

2 hours ago, EGLD said:

But more in a reputational, customer loyalty, professionalism context - these things should be important to software companies

Fixed it! 🍻

[Nyxx 6,993]

18 pagers.

The op could have just wrote update PMDG NG3 "Coming soon" topic locked...job done. 18 pagers, 🤣

[2reds2whites 827]

On 9/27/2020 at 8:18 PM, Dillon said:

I'll have to say I'm a little ticked scenery for the whole country of Japan is getting released when major issues with the core sim and the SDK still unresolved. Which one is more important?  We still don't have 'fall' scenery going into October yet Japan has to get done.  I hope this won't be FLIGHT all over again with bad decisions leading the way instead of common since winning out. Cart before the horse is what seems to be happening where a major developer is having to pull back.  I fired of P3D today and if I had to go back to that would be a sad day.  There's no comparison to FS2020 but like I said before Microsoft always figures out a way to mess things up in the chase for cash.  I wonder if the port to XBOX is now the new priority because it sure isn't the SDK or fixing the core sim. Very Frustrating...   

That's akin to complaining that a car bodyshop paints the body before the engine shop has finished it's rebuild.

It's irrelevant. The bodyshop can't build the engine because it's not their job and they don't know how, nor could the engine shop paint the car. 

[micstatic 4,299]

On 9/27/2020 at 10:40 AM, Tom_L said:

Wasn't RSR's timeframe very similar until his recent post? Just saying...

Time will tell!

I think original timeline was by end of 1Q 2021 for 737.  

[SierraDelta 1,334]

2 hours ago, F737NG said:

there's at least one more huge paid upgrade product that they can bring to P3D in the shape of the 777,

Before that happens they will give us a free upgrade as stated by RSR:

 This update is a pretty comprehensive update cycle for the 777 Base Package and brings in many of the newer capabilities, performance improvements and features that have debuted in the 747 and 737 product lines subsequent to the 777’s release seven years ago this month. The update is no cost for 777 users and will bring the 777 up-to-par with her sister products in terms of Global Flight Operations capabilities, ground services, animations and the like.

[harrry 322]

3 hours ago, F737NG said:

 

Edited September 29, 2020 by harrry
deleted post as was beaten to it,

[bb010g 3]

Hi, programming nerd here to set the record straight on some MSFS 2020 things.

Flight Sim 2020 uses inNative (source code) to compile WebAssembly (WASM) into native machine code via LLVM. (Check the credits and you'll see inNative listed.) Restated for programmers, inNative is a WASM LLVM frontend, compiling WASM into LLVM IR and then letting LLVM do its normal thing. LLVM is the same backend that Clang, one of the major C++ compilers (alongside GCC & MSVC), uses. WebAssembly code can be compiled to native code completely before execution, and, depending on how you invoke inNative, any native API can be used from WASM modules. With the right configuration, you can compile arbitrary normal Windows C++ programs to WebAssembly and then to native code via inNative and have them execute virtually identically (modulo optimizations). (MSFS 2020 does not allow for this usage, by design.)

Microsoft Flight Simulator 2020 is not interpreting WebAssembly like your browser would, but instead utilizing it as a portable, well-designed, low-level, sandboxed language. Instead, WASM modules can provide native performance to the same code on essentially any platform MSFS wants to run on, without extra development work.

WebAssembly by itself offers no platform-specific APIs (they're considered unnecessary bloat), but it does offer the ability to import functions from the "host". inNative allows arbitrary C ABI (application binary interface) functions to be exposed to WebAssembly modules, which may import them if they please, like how a linker traditionally functions, linking libraries (like SOs or DLLs) together.

MSFS is not constrained in what it exposes by its use of WebAssembly, and as such any missing SimConnect functionality is most likely due to normal difficulties of implemention & integration with the sim.

File system APIs have also been brought up a decent amount here in what I've read, and exposing those is also in MSFS's court. I believe MSFS implements or is implementing WASI, the WebAssembly System Interface, a standard for file-system APIs in WASM? Note that whatever is chosen, it will basically perform as fast as C++ code compiled directly from source to LLVM IR & then native through Clang, given the same interface. The choices of file-system interfaces exposed may effect performance, but this is something you can reasonably bring up to Asobo as an extension to their existing host function set that would really improve your add-on. Any function added there would be accessible with full native performance from your WASM modules.

inNative not only can perform AoT (ahead-of-time) compilation, but also JIT (just-in-time) compilation via LLVM's JIT API. For the JIT, a WASM module is compiled to LLVM IR by inNative and then to native code by LLVM that can then be executed right on the spot, instead of the native code being output to a file or other longer-living storage. This isn't used much AFAIK, and I don't think may be used on the Xbox at all(?), but it can help make development smoother (less time waiting between testing iterations). (The fact that inNative is an AoT compiler is a large part of why it was chosen, AFAIK. Official add-ons can use the same SDK as community add-ons and be compiled before deployment for the Xbox, so that no code has to be compiled (security hazard) or interpreted (performance hazard) on the Xbox.)

Also, on the topic of WebAssembly & graphics APIs (e.g. DirectX), they're really separate issues. WebAssembly doesn't target shader or GPU compute programming in the same way C++ doesn't normally target those. You'll instead have APIs for talking to the operating system & graphics drivers (which can be exposed to WASM no problem & without damaging performance), and then separate languages like HLSL (OpenGL, DirectX) or SPIR-V (Vulkan) that some of those APIs deal with for encoding high-performance GPU programs. MSFS is free to choose graphics backends independent of WebAssembly, and whatever they decide to expose via WASM host functions will cost no performance (compared to the same functions in directly native code).

Thanks for listening, trans rights are human rights, and happy simming everybody!

[Janov 2,383]

Thanks for clearing that up! 😂🤣

[leprechaunlive 1,852]

Dont talk about human rights, we know you'r a robot. 

[BillC 135]

I thought this thread was locked already? Do us a favour and lock it again? 

TIA

[Amon1973 1,421]

4 hours ago, bb010g said:

Hi, programming nerd here to set the record straight on some MSFS 2020 things.

Flight Sim 2020 uses inNative (source code) to compile WebAssembly (WASM) into native machine code via LLVM. (Check the credits and you'll see inNative listed.) Restated for programmers, inNative is a WASM LLVM frontend, compiling WASM into LLVM IR and then letting LLVM do its normal thing. LLVM is the same backend that Clang, one of the major C++ compilers (alongside GCC & MSVC), uses. WebAssembly code can be compiled to native code completely before execution, and, depending on how you invoke inNative, any native API can be used from WASM modules. With the right configuration, you can compile arbitrary normal Windows C++ programs to WebAssembly and then to native code via inNative and have them execute virtually identically (modulo optimizations). (MSFS 2020 does not allow for this usage, by design.)

 

Thanks for listening, trans rights are human rights, and happy simming everybody!

So are there any limitations in using webassembly, I seem to remember some devs claiming that it's limits usage to a single core?

Sorry if it's stupid question as programming wise I'm a bit out of date, I done my A level computer science 35+ years ago.

[virtuali 4,419]

9 minutes ago, eaim said:

So are there any limitations in using webassembly, I seem to remember some devs claiming that it's limits usage to a single core?

According to the latest SDK ( 0.8.0 ), WASM modules have the following limitations:

- The Windows API is not supported

- C++ Exceptions are not supported

- C++ Threads are not supported

- GDI+ Wrapper is incomplete

About multi-core usage, lacking of support of C++ threads means a single WASM module cannot create new threads on its own, so it will run on a single thread. However, when I inquired with Asobo about this, several months ago, they replied they were already looking into parallelizing WASM modules so, at least, each one would run in its separate thread, which would help if there are many of them installed. I don't know this is already in the current version of the sim, the docs are not clear about it. Also, I believe Asobo had plans to allow multi-threading even inside a single module, but in this case the docs specifically say it's not there yet.

From a "port existing C++ code", the lack of C++ Exceptions might be more serious, but of course it depends if the original code used them in the first place and, if you use 3rd party libraries that comes as C++ source code, they might use them a lot, and might be difficult to modify code that is not yours.

Same as the lack of support for Window API, it might be a big problem or no problem at all, depending what the original code did.

And same for the incomplete GDI+ wrapper, it might be a big problem or no problem at all, depending which GDI+ functions were used in the original code.