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?
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.
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.
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.
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…
This post was flagged by the community and is temporarily hidden.
This post was flagged by the community and is temporarily hidden.
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 spad.next 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.