Update on Complex Airliners

yes, always had by default, and it only got better with version 11.40 (and with active sky xp it gets better) iirc, and so do p3d (with active sky) and DCS (by default). msfs 2020 doesn’t have it most probably because it’s a console video-game built from the ground up for gamers and targeted towards the entertainment video-gaming crowd. things like wake turbulence could startle and confuse the gamers and prevent them from taking screenshots properly as they fly in close formation and do barrel rolls and all sorts of video-gamish stuff they usually do.

1 Like

hmmph. i can imagine its gonna cost even more fps when/if ever they do implement it.
but i get your point. it seems they care more about compatiblity with console controllers and vr headsets.

nah I dont think so. Other “flight” simulators do that and then a lot more without any impact on fps performance.

Exactly. Imagine you are playing COD or CSGO shooter games. As you use your mouse or a controller to aim your gun at the enemy, the crosshair shakes, making your aiming difficult. Will you still play that game? No. That’s exactly what happened with this entertainment console video game MSFS 2020. They heavily dumbed down a lot of things to make it easy for the upcoming console video gamers. This is probably also why there’s no option to heavily reduce the visibility and create a difficult IFR scenario in this video game.

Just treat MSFS as a scenery browser video game and take screenshots or live-stream etc. As long as you keep in mind that MSFS has got nothing to do with actual “flight” simulation, you will have way more fun and a lot less worry.

I think that is just a very negative look on things. FSX wasn’t an in-depth sim out of the box either, it was very bad compared to MSFS. The flight model was terrible too, just switch back to legacy. The mods made it what it was.

X-plane is very good systems wise out of the box, but people used to call it a VFR sim too in the beginning because there were no in-depth aircraft addons. It has been terrible literally for decades.

I am not defending the sim and its shortcomings. I don’t understand the people that come to the defence of multi billion dollar companies that don’t deliver a product they promised, but,…

I’ve had to go around on three of my flights with low weather, since the visibility or ceiling was below the minima. I can remember them cuz of how challenging it was lol.

Best was Manilla on final a squall caused a heavy downpour and lowered the visibility.

Wondering if there is a setting you could change on yours?

@CptLucky8 The things you bring up make sense. Wouldn’t you still be able to able to import external libraries if their source was available to you though (not .dll or .lib) via static linking? In the future, availablity through Wasm modules that inNative could link for you could work with the Module Linking proposal?

Your point on SIMD is really interesting; could that be solvable going forward with the Fixed-Width SIMD proposal, the Flexible Vectors proposal, and/or the Relaxed SIMD proposal?

1 Like

Sorry, but, just cause something was a certain way doesn’t make it acceptable or right, we have to grow and develop at some point. Remember everything that was accepted by society in the past???

Let’s not forget access to technology that these devs had vs what the Ace team or Laminar did when they launched their sims. Hell, they even had fully working complex airliners of the past to work with as a starting point, if only to learn from.

Lastly and personally not that important, but, I paid double if not triple for this base sim than I did for any sim in the past.

1 Like

yes in my XP 11 “flight” simulator ( a simulator based on its FAA approved version) I have the following setting I can use to reduce visibility as much as I want:

This functionality is completely missing from MSFS 2020 video game. Do you suggest that I email Jorg and ask him to implement it for the umpteenth time?

I’m assuming you were referring to me. No I wasn’t being negative. I was just calling a spade a spade and helping @ztemplepilot have some fun with this entertainment ESRB “E” rated console video game.

1 Like

i’m just hoping the SDK will develop and mature enough to the point where 3rd party devs are able to implement the functionality more traditional simmers need and want.
had it not been for the a32nx, i wouldn’t even have the courage to go ifr on vatsim.


You should definitely try the CRJ.

I’ve commented about this in a prior Q&A. My understanding behind such request is:

X-Plane 11 is perfectly simulating this specific aspect of weather influencing piloting decisions in my opinion.

1 Like

@bb010g These are promising libs/extensions indeed, but nowhere near having direct access to the metal.

It is better than nothing of course, but I wouldn’t be any time frame for having these, I’ve been waiting more than 12 months for less… and I’m still waiting.

What is this for kind of comment? Incredible childish, if you don’t like MSFS, that’s fair enough, but please stick to your preferred products and don’t poison this community.


I’m sorry to say but these are Sebastian own words: “We have dumbed down up drafts otherwise people wouldn’t understand what is happening with their aircraft”. This tells it all about the subject matter to me, but I might be understanding it wrongly too.

1 Like

whoa, he said this really? even adding these as a user parameter would’ve been greatly appreciated. but i guess they gets to decide their target audience. i feel so dirty now. lol.


inNative’s tracking issue for implementing the Fixed-Width SIMD proposal is Implement Proposal: Fixed-width SIMD · Issue #43 · innative-sdk/innative · GitHub if you want to keep an eye on it or contribute (inNative is licensed under Apache-2.0). Asobo will still have to update their vendored inNative & enable the proposal’s flag once it’s implemented, but I’d expect that to happen soon after the functionality is stable.

Thanks for the link!

Do I understand correctly they intend to break some of the SIMD speed advantage in floating point operations:

The floating-point operations in this specification aim to be compatible with WebAssembly’s scalar floating-point operations. In particular, the rules about NaN propagation and default NaN values are the same, and all operations use the default roundTiesToEven rounding mode.

AFAIK, one particularity of floating point operations in SSE is that they are not abiding by the IEEE rules. This permits some operations (with NaN and/or other specific cases) to fall through and still returning “sensible” results (better suited for multi-media) instead of error results (better suited for maths).

I’m not saying it isn’t going in a good direction as a standard, because in effect this will help leveraging more than 80% of the actual silicon in our CPUs (the transistors in there handling the SSE opcodes). It would be much more simple and immediate, and risk free for the Market Place and the Flight Simulator.exe process and its address space, let alone for its WASM stack and JS/HTML layer, to actually just adding a few new APIs in the SDK to supporting shared memory and sockets.

Actually there is a loophole in their implementation which I won’t document yet, which allows loading any 3rd party DLL and hacking the process (this is not a system wide hook). This is a higher security risk than the gauges.

1 Like

I’d recommend looking around for answers to this question at Issues · WebAssembly/simd · GitHub , or opening an issue with your question there if you can’t find an answer. You’ll get better answers (and chances for improvement) out of the people actively working on the spec than me. :slight_smile:

1 Like

If you know this to be a vulnerability in inNative and not MSFS2020’s embedding, there are invite links to its Discord guild on its site or in its README, and you can PM Erik McClure about the vulnerability from there. Thank you for your responsible disclosure.

1 Like

I’m talking about a FS2020 loophole, defeating the whole point of sandboxing 3rd party devs for security.

In other words as of today, and most likely during the lifespan of FS2020 given the nature of the loophole, you can inject a virus in FS2020 and stole customer credentials via the loophole, but 3rd party devs can’t even access the bare bone metal for faster and better add-ons.

I understand the reasons behind WASM and this is a good technology for what it is good at, but it shouldn’t be used in my opinion to make customers fearing 3rd party vendors are going to stole their personal information if they are not sandboxed thanks to Microsoft and Asobo… Otherwise in my opinion this is a fallacious argument, telling the 3rd party vendors are thieves and customers must be protected from them.


NB: the official transcript and the live Q&A video are pretty much similar, except for this specific question: “Can we talk about DLL?”

Live comment:

  • DLLs can carry unsafe code and they can’t have unsafe code in add-ons in the Market Place. Sandboxing is good for having safe add-ons in the Microsoft store.
  • Sandboxing is also a good way to port legacy addons in C++

Official transcript:

Eric – When you ship a DLL, you never know what it is going to do! It has access to personal informal information and result in having security issues. Using WASM, we are sure that 3rd party content only accesses designated files!

NB: you’ll find my other comments about this and the SDK from the link above.

1 Like