Weather & Terrain Radars vs. WASM

On the one hand, Asobo and MS have given the Flightsim community a simulator with a level of detail never before seen on a desktop simulator platform.
The rendering of the world is beyond what I thought would be possible, given that I used the first versions of flight simulator on an IBM PX XT.
Next, we have weather that is so vividly portrayed that it seems, at times, believably real, immersive, and captivating.
So, my quest for working weather and terrain radars is because I’d like these systems to be available within third party WASM coded aircraft.
However, developers including Aerosoft, QualityWings, PMDG, and Fenix are unable to code WXR / TERRAIN functionality, which is rather disappointing given the unparalleled beauty of the in-sim terrain and weather.
I guess that this issue will apply equally to other developers who are considering bringing their products into MSFS, including FSL.
No future third party supposedly study-level aircraft can be considered complete without functional radars.
Please could you, as the platform developers, provide some useful technical insight into why radars are such a problem when it comes to WASM coding, and how you are addressing this issue in order to provide inter modular data support, or whatever the fundamental is?
Thank you.


I second this to the fullest.

To me this is perhaps the biggest scar on MSFS at this point in time. I can work around not so perfect ATC, even try my best at low range VOR’s but missing the radarscreens in the (CRJ) cockpit has been really very disappointing so far. I really hope for a solution soon.


Thank you.
I’d have hoped for more momentum from other users for my post, as well as a response from Asobo.
They may have constructed a fine platform, but they aren’t serious about airliners, not yet anyway.
And to not give the tools to respected developers is but a self inflicted wound.
They must remember that many of their customers are seasoned and capable simmers who know what they want.

1 Like

There are a couple of issues in play. The first is that while the SimConnect API is exposed to WASM, the existing calls that would have enabled getting in-sim weather have been deprecated. If those functions were implemented to support the new weather system, that might be sufficient to enable developing wx radar from within WASM. OTOH, Javascript supports HTTP calls as well as sockets, so I would imagine that existing wx radar implementations rely on obtaining wx information from web services and using whatever they get back to propagate the wx radar screen itself. One could look at an existing implementation to see how it is done. Presumably, Aerosoft could fix the CRJ today if they were willing to build wx radar as an HTML/JS gauge. Not that I’m suggesting that they do this–I’d much rather see them continue to put pressure on Asobo to provide the necessary support to allow wx radar to be implemented from within WASM.

The second problem is that WASM just plain sucks from a development perspective as it is so locked down that very little can be done from within it. Basically, you are limited to SimConnect, a few GDI+ apis and a subset of the language runtimes. The reason for this is that it enables cross-platform support (that is, the same WASM module will run on both PC and X-box without any modification). Also, from a security perspective WASM is very safe, but the reason it is safe is because its functionality is so limited. Presumably, the assumption was, “Why would anybody need anything more than SimConnect and some graphics APIs?” My response is, “Why would anyone ever need more than 1024K of memory?” Anyway, if WASM even had IPC support, developers would be free to implement wx radar using the same techniques that are currently available in JS.

I suspect now that Fenix Simulations has eschewed WASM in favor of running their own stand-alone executable to do the heavy lifting for their upcoming A320 implementation, we may see more developers follow suit. Personally, I’m tickled pink that Fenix just said no to WASM. Hopefully, it sends a strong message back to MS / Asobo that WASM isn’t a sufficient platform for developing the kind of ultra-realistic applications that the flight simulation community has in mind. Ideally, MSFS should go back to allowing support for Win32 DLLs (in addition to WASM) and let the add-on developers choose which platform works best for them.

Thank you for your descriptive insight, it helps us picture the interplay between the many dynamics and factions.
I asked Fenix whether a weather / ground radar was implemented, and someone said that they’d seen a terrain radar but no weather depiction.
I do hope that WASM will, in due course, be radically updated to meet the needs of anything greater than 1024K, which is pretty much everything.
Again, thank you.

Well I’m no prof on software development but am unsure about the external WR-gauge. A WR depicts the bounce back of precipitation/moist inside a cloud. Seems awfully difficult to read that from an external source with regards to the very exact position of the aircraft. Same for turbulence which is a very dynamic type of air behaviour. I really do think this needs to be measured from within the sim itself.

The fear is that this may never be addressed, or prioritised to suit the needs of the savvy few.

At the end of the day, dysfunctional radars are a no-go item, so we categorically need them in the sim where they will help us enjoy (read avoid) the weather even more so than we do,

If the platform is to mature, and it absolutely deserves to, it needs study level machines delivered by the big guns.

I’d rather something than nothing, so if at the end of the day we need a laggy work around, then so be it.

Ideally of course, Asobo will rise to meet the challenge, but therein lies a plethora of other issues.

I just had a look to see what Asobo is doing. They are using Bing Maps to provide their weather radar. Doubtless isn’t isn’t accurate with respect to in-sim weather. In fact, the initial implementation was just showing clouds, rather than precipitation. Anyway, the core implementation is internal to the simulator, but they expose a BingMapElement class in JavaScript that makes a Coherent GT call back into MSFS to SHOW_MAP_WEATHER which presumably does the heavy lifting to update the weather radar display. Further details could probably be gleaned by sniffing packets.

Whether we will ever have wx radar that accurately represents in-sim weather is an open question. Presumably, it should be possible, but it will require some work from Asobo. In general, lack of in-sim weather information is (IMO) one of the biggest pain points in the simulator right now. Hopefully, they will address that sooner rather than later…

1 Like

Please keep posts on the topic and not on each other.

WX data is not coming from Bing and you can test it by using e.g. Rain weather preset and radar shows in-game rain.

The original point I made was that WASM doesn’t yet fully allow inter modular data exchange, which makes it impossible for serious developers to write code for WX and terrain radars.
The list of serious developers who are affected by this is like the who’s who of the flight sim world, including PDMG, QW, JF, Aerosoft, and so on.
Developers choosing to use the pre-existing default avionics systems, such as CS and Virtualcol, can continue to use the default built in weather and terrain functions (which I don’t believe are coded in WASM).

Doesn’t SimConnect have a point-to-point data transfer system that allows data transfer between modules? This is used for instance for a separate .exe to talk to a .wasm module in systems (like FSUIPC or with the beta LVARS plugin) that allow you to modify LVARS.

If you can get the data you want from JS or a separate executable you should be able to inject it into the wasm module.

(Also note there is no 1024K limit in Wasm, I think that was meant to be some kind of humorous comparison to 1980s computers?)

Is there a survey on this topic? This is not mentioned in the weekly development plan. I don’t understand why such a big deficiency is overlooked.


Yes, there is. Technically, you could roll your own protocol on top of that, but it is unclear how performant it would be without understanding the underlying channel.

1 Like

Carenado has had weather radar in the Seneca since it came out. If they don’t use WASM, then what do they use, and why can’t Aerosoft and the others use that too?

Likely, it will be based upon default systems, as GA types do not require extensive coding as do, for example, multi layered/function displays such as MFDs.
The free GNS530/430 upgrade by PMS50 includes (an optional) WXR, so as long as the systems are largely default, then radar functionality can be provided.
This radar / data / WASM problem still seems to be an issue even though things have gone quiet.
I don’t know if the next serious aircraft release will feature this functionality, but I’ll be looking to see if PMDG have managed to squeeze in this functionality.

1 Like

Radars are an indispensable part of the simulator. However, I cannot use it on the only plane I fly.

FENIX has it working, but it is „outside“ of the sim. Means, they use an external terrain database. Not sure how they do it with the weather tho… probably also an external source, problem will be it does not match the sim weather then, but we will see with what they come up with.

1 Like

That is such a relief to know, thank you for sharing.
It means that where there’s a will, there’s a way, so other serious developers will manage this as well.
Again, thank you.

1 Like

Yes, there are ways. But the best and most accurate would be if the data is taken from the sim instead of an external source that is not matching the sim 100%. But as for the terrain, that should work pretty okey, i guess.

One of the downsides of using external sources would wean, it will not work on Xbox/Marketplace. But we know for now that neither FENIX nor FBW aims for the Xbox/Marketplace due to such reasons.

1 Like