I just deleted the 500/700 and reinstalled the new package, which took just a few minutes. I never noticed the "Aerosoft One" app until last night so I am not certain as to how if works, but I did install it in any event. What I am curious about is to how the Aerosoft One app is used vs. the Aerosoft Updater. Are these two apps redundant, and will one replace the other?

Cheers, Pete

Edited November 11, 20214 yr by PilotPete99

1 minute ago, PilotPete99 said:

I just deleted the 500/700 and reinstalled the new package, which took just a few minutes. I never noticed the "Aerosoft One" app until last night so I am not certain as to how if works, but I did install it in any event. What I am curious is to how the Aerosoft One app is used for vs. the Aerosoft Updater. Are these redundant?

Cheers, Pete

Its a good question Pete.

As when i read about the "one app" I deleted the Aerosoft Updater as I thought it was replaced by the "new" "one app".

I installed the "one app" to hopfully just do an update, but it then re installed Aerosoft Updater!!! so i now have 2 apps and have no idea what each is for, nor to I care a monkey what each is for. I just closed both after the new install. I thought "AS" 🙂 Its just best to delete what ever i have of them and DL new version from my account.

Moving on ....🙂

2 minutes ago, Nyxx said:

Its a good question Pete.

As when i read about the "one app" I deleted the Aerosoft Updater as I thought it was replaced by the "new" "one app".

I installed the "one app" to hopfully just do an update, but it then re installed Aerosoft Updater!!! so i now have 2 apps and have no idea what each is for, nor to I care a monkey what each is for. I just closed both after the new install. I thought "AS" 🙂 Its just best to delete what ever i have of them and DL new version from my account.

Moving on ....🙂

You know what is funny too is that every time I re-download a new installer from Aerosoft I get a new Aerosoft Updater, so I just delete the old version. Hopefully they provide some additional clarification, as I found the interface of the Aerosoft One App a bit confusing. Lol. Aerosoft likes to make us think......

Cheer, Pete

8 hours ago, JRBarrett said:

It is written in JavaScript/HTML That is the native programming language used for all the default MSFS aircraft. (Along with a good deal of XML). The FBW Airbus is a derivative of the default A320 in MSFS. There is an API to extract precipitation information for use by a simulated weather radar in a JavaScript/HTML aircraft.

The CRJ is written totally in C++ and uses WASM to compile the code into a form the sim can use. A WASM-compatible API for weather radar does not yet exist, and only Asobo can create such an API because doing so would require full access to the source code and full knowledge of the proprietary internal data structures of the simulator itself. I’m sure such an API will be coming eventually for WASM, but until it does, there will be no weather radar for exclusive WASM aircraft. 
 

 

I know some code languages. but what is the difference between Java/HTML and WASM? Why choose one or the other.

Again, no offence, just wanna learn 😉

(okay, it is fast.. that the web makes clear)

Edited November 11, 20214 yr by Victoroos
some googeling later.. ;)

9 hours ago, JRBarrett said:

There is no possible way to extract the location and intensity of clouds and precipitation  from within the MSFS weather system without a documented API. Such an API exists for gauges and displays written in JavaScript/HTML (which is the case with all of the default MSFS aircraft) but there is (as yet) no corresponding API for gauges and displays written in WASM. The entire CRJ is a WASM project. It is not a case of “laziness” or not trying hard enough.

The internal workings of the MSFS weather system are completely undocumented. Aerosoft cannot simply “hack into” the running MSFS process to try to extract cloud and precip information. For one thing, they would have no idea where to look, or how the data is structured even if they knew where to find it.

There is also no way to mix JavaScript/HTML displays with WASM displays. It has to be one or the other. If Aerosoft were to re-code all the CRJ displays and system logic from the current C++/WASM to JavaScript/HTML, they would basically have to scrap the entire CRJ project and start over from scratch.

An API has to come from Asobo to provide documented system calls to extract the required weather information. That has not yet been implemented for WASM.  I am quite sure that Asobo is very aware that Aerosoft (and any other developer which will be creating WASM-based aircraft add-ons) wants and needs such an API, but it has not yet been provided. This may have to wait for the “major” overhaul of the Live Weather system that is supposed to happen sometime in 2022. This is entirely speculation on my part - I have no definite information on that one way or the other.

You are correct that the SDK is not needed for “everything” an add-on does. As it happens, the entire CRJ FMS, much of the navigation logic and most of the aircraft systems are completely custom, and operate outside of the current SDK. But weather radar is a completely different animal. It is 100 percent dependent on MSFS exposing its internal data to the add-on in a documented way, and (at the moment) that simply does not exist for WASM.

Guess I should of waited until they had all this figured out before I bought this unfinished(in my opinion) airplane. Weather, terrain and traffic radar is a major part of any airliner, without it it really cuts down on the immersion and realness of this otherwise pretty good plane. Almost sounds like we'll probably never see it implemented in this plane. Aerosoft has already made a ton of money off this plane so their enthusiasm has probably dimmed a little on giving us these things(if they come available), would be nice to have someday. Gotta get that Twin Otter out to grab some more cash. Hopefully this good CRJ will someday become a REALLY good CRJ. It has the potential!

8 hours ago, abrams_tank said:

I am just wondering about whether Javascript/HTML can be mixed with the C++ WASM displays or not.  If you are a 3rd party dev that works with the MSFS SDK every day, I'm sure you would know if it's possible or not possible.

I’m not an 3rd party commercial aircraft developer, though I have created some freeware airport mods for MSFS, and have worked with XML gauges in P3D and MSFS.  

I am a tester for the CRJ and communicate with Hans and other developers on a regular basis. The original CRJ on FSX and P3D used GDI+ to render displays. GDI+ is not available in MSFS, instead it uses NanoVG to handle graphics calls for C++ coded projects compiled under WASM. A display would have to be written totally in JS/HTML to use any of the overlay features you mentioned. Converting the existing CRJ displays to JS/HTML would take months of work. It would require a complete re-write of the entire project.

It is definitely possible to use both JS/HTML and WASM in the same aircraft project - but not for graphics. Working Title uses WASM elements in their mod of the default CJ4 for some of the more complex functions of the autopilot and FMS which are more easily and efficiently coded in C++, but the WASM is part of the “behind the scenes” logic - it is not used for display rendering.

MSFS uses simconnect as one of the primary interface APIs between the aircraft and the sim, just as in FSX and P3D. In the older platforms, it was possible to read the locations and heights of clouds via simconnect but those particular functions are deprecated and do not exist in the MSFS version. Other simconnect variables related to weather do work in MSFS as they did in the older versions, such as air temperature, pressure, wind speed and direction, etc and the CRJ does make use of those.

AFAIK, the weather radar function currently available to JS/HTML displays might simply be a “black box” from a developer’s standpoint - an object added to the display code if radar functionality is desired. No such functionality is yet available for displays coded in C++ using NanoVG.

I am assuming (but do not know for sure) that PMDG will be leveraging their extensive existing C++ codebase from previous versions of their 737 for the upcoming MSFS version of the 737NG - i.e. it is likely to be 100 percent WASM. If so, that aircraft will probably also not have weather radar on initial release.

The new Fenix A320 may be different in that regard. Since that is a brand new aircraft built from scratch, the developers may have chosen to use JS/HTML for the displays from the very beginning. I guess we will not know for sure until it releases. Perhaps the Fenix developers can answer that question on their Discord.

Edited November 11, 20214 yr by JRBarrett

9 hours ago, Richard Jacks said:

How is it that fbw can have an excellent wx radar?

The stable and development versions are using the default WX radar that Asobo A320 uses IIRC, or at least a modified version.

The current prototype builds have no WX radar (or ground radar), because like Aerosoft, FBW are waiting for Asobo to allow access to the weather and terrain data so they can create their own.

Edited November 11, 20214 yr by Tuskin38

8 hours ago, abrams_tank said:

Hi.  I am curious about this myself. May I ask if you are you a 3rd party dev that is developing products for MSFS and you work with the MSFS SDK daily?

I am just wondering about whether Javascript/HTML can be mixed with the C++ WASM displays or not.  If you are a 3rd party dev that works with the MSFS SDK every day, I'm sure you would know if it's possible or not possible.

I am not a 3rd party dev and I don't know much about the details of the MSFS SDK.  Having said that, I am a software developer that works with Javascript & HTML.  Javscript & HTML do support a property called "Z-index": https://www.w3schools.com/jsref/prop_style_zindex.asp

Z-index allows you to overlay a div on top of another element.  I don't know what capabilities MSFS has for Javascript & HTML, but if has enough capabilities and supports Z-Index, then using the Z-index would allow a developer for MSFS to overlay a Javscript/HTML gauge on top of another gauge, etc.  Z-Index more or less allows you to overlay an object (most likely a div in HTML) on top of another object, so theoretically, by using the Z-Index (if it's supported across the entire screen in MSFS), a developer could overlay a Javascript & HTML gauge on top of a C++ & WASM gauge.

  Great question!

  Next time I buy a plane(especially an expensive one)I'm going to definitely look at what software it is made with. If WASM doesn't work with MSFS I will surely avoid it. To me it doesn't make any sense to buy a product that is not compatible with the sim. What it comes down to is this, I don't care what language the developer uses, I just want it to work, I am not a programmer or a person who knows a lot about software languages, I just want it to work. Aerosoft may have a real winner with this plane, give us radar(I don't care how) and this has the potential to one of the best planes for years to come, don't give us the radar and next month when one of the other big name air liner developer comes out with their plane and, it will have radar, this plane will fade really fast. I know mine will be parked in the hanger(waiting for avionics) when this plane comes out, with radar.

Just now, Daytona125 said:

  Great question!

  Next time I buy a plane(especially an expensive one)I'm going to definitely look at what software it is made with. If WASM doesn't work with MSFS I will surely avoid it. To me it doesn't make any sense to buy a product that is not compatible with the sim. What it comes down to is this, I don't care what language the developer uses, I just want it to work, I am not a programmer or a person who knows a lot about software languages, I just want it to work. Aerosoft may have a real winner with this plane, give us radar(I don't care how) and this has the potential to one of the best planes for years to come, don't give us the radar and next month when one of the other big name air liner developer comes out with their plane and, it will have radar, this plane will fade really fast. I know mine will be parked in the hanger(waiting for avionics) when this plane comes out, with radar.

I'm pretty sure WASM works with MSFS.  From my understanding, the MSFS SDK uses WASM extensively.

19 minutes ago, Daytona125 said:

Guess I should of waited until they had all this figured out before I bought this unfinished(in my opinion) airplane. Weather, terrain and traffic radar is a major part of any airliner, without it it really cuts down on the immersion and realness of this otherwise pretty good plane. Almost sounds like we'll probably never see it implemented in this plane. Aerosoft has already made a ton of money off this plane so their enthusiasm has probably dimmed a little on giving us these things(if they come available), would be nice to have someday. Gotta get that Twin Otter out to grab some more cash. Hopefully this good CRJ will someday become a REALLY good CRJ. It has the potential!

If by “traffic radar” you mean TCAS - that already does exist in the CRJ and it works.

Weather radar and terrain are totally dependent on Asobo adding API functionality to the SDK so that C++/WASM displays can access those elements of the sim as JS/HTML displays currently can. The moment that happens, I am sure these features will be added to the CRJ. 

19 hours ago, liamp51 said:

😑😑 thanks Aerosoft I guess I'll plow into CBs left and right at night lol 

For once this is not Aerosoft's fault. There is no technical way to read weather data from the sim, which is necessary to put it on a radar. It's the same for Fenix and PMDG on release, unless Asobo works on it.

10 minutes ago, JRBarrett said:

I’m not an 3rd party commercial aircraft developer, though I have created some freeware airport mods for MSFS, and have worked with XML gauges in P3D and MSFS.  

I am a tester for the CRJ and communicate with Hans and other developers on a regular basis. The original CRJ on FSX and P3D used GDI+ to render displays. GDI+ is not available in MSFS, instead it uses NanoVG to handle graphics calls for C++ coded projects compiled under WASM. A display would have to be written totally in JS/HTML to use any of the overlay features you mentioned. Converting the existing CRJ displays to JS/HTML would take months of work. It would require a complete re-write of the entire project.

It is definitely possible to use both JS/HTML and WASM in the same aircraft project - but not for graphics. Working Title uses WASM elements in their mod of the default CJ4 for some of the more complex functions of the autopilot and FMS which are more easily and efficiently coded in C++, but the WASM is part of the “behind the scenes” logic - it is not used for display rendering.

MSFS uses simconnect as one of the primary interface APIs between the aircraft and the sim, just as in FSX and P3D. In the older platforms, it was possible to read the locations and heights of clouds via simconnect but those particular functions are deprecated and do not exist in the MSFS version. Other simconnect variables related to weather do work in MSFS as they did in the older versions, such as air temperature, pressure, wind speed and direction, etc and the CRJ does make use of those.

AFAIK, the weather radar function currently available to JS/HTML displays might simply be a “black box” from a developer’s standpoint - an object added to the display code if radar functionality is desired. No such functionality is yet available for displays coded in C++ using NanoVG.

I am assuming (but do not know for sure) that PMDG will be leveraging their extensive existing C++ codebase from previous versions of their 737 for the upcoming MSFS version of the 737NG - i.e. it is likely to be 100 percent WASM. If so, that aircraft will probably also not have weather radar on initial release.

The new Fenix A320 may be different in that regard. Since that is a brand new aircraft built from scratch, the developers may have chosen to use JS/HTML for the displays from the very beginning. I guess we will not know for sure until it releases. Perhaps the Fenix developers can answer that question on their Discord.

If this is the case my next purchase will definitely be the Fenix A-320. I just want a plane that works as it should. I would love my beloved 737 but if it doesn't have radar I'm not spending(probably a lot of money) on something that doesn't fit(for me).

4 minutes ago, JRBarrett said:

If by “traffic radar” you mean TCAS - that already does exist in the CRJ and it works.

Weather radar and terrain are totally dependent on Asobo adding API functionality to the SDK so that C++/WASM displays can access those elements of the sim as JS/HTML displays currently can. The moment that happens, I am sure these features will be added to the CRJ. 

Yea that is what I meant. Traffic radar=TCAS, sorry I couldn't remember TCAS at that moment, heck, I'm not even a pilot. Thanks though for pointing this out. I'm going to have to figure out how to get that TCAS working, I've made sure it was on and stuff, thought I was doing everything right but I still see no planes on my screen. And yes, I will read the appropriate pages in the manual(or POH, or whatever the right term it is for that book with lots of pages). If I figure this out I will stand corrected in my miss-step.

33 minutes ago, JRBarrett said:

 A display would have to be written totally in JS/HTML to use any of the overlay features you mentioned. Converting the existing CRJ displays to JS/HTML would take months of work. It would require a complete re-write of the entire project.

...
...

It is definitely possible to use both JS/HTML and WASM in the same aircraft project - but not for graphics.

For sure, converting the CRJ displays to Javascript & HTML would take a lot of time.  I think Aerosoft doesn't want to waste time on something that is temporary, and is waiting for Microsoft/Asobo to add support for terrain/weather radar in the SDK.

So it seems like you have created some freeware airport mods with MSFS and you have also worked with the XML gauges in MSFS, so you know far more about the MSFS SDK than I do.  What you are saying though about Javascript & HTML - you seem to be implying that Javascript & HTML cannot be used for rendering graphics in MSFS, even 2D graphics?

I ask this because Javascript does support the rendering of graphics in browsers: https://www.creativebloq.com/features/amazing-graphical-javascript-frameworks

Of course, the MSFS screen is not a browser, so I am wondering about the capabilities of Javascript & HTML in MSFS.  Conceivably, if the MSFS screen has support for Javascript graphics, and the MSFS screen supports the z-index function throughout the entire screen, it should be possible to overlay a Javascript & HTML gauge that supports the rendering of graphics on top of a C++/WASM gauge.  

BTW, even if this is technically possible, it still wouldn't make sense for Aerosoft to do the weather/terrain radar in Javascript & HTML.  It's just too time consuming, difficult to manage the code, and when Asobo/Microsoft officially support weather/terrain radar in the SDK, Aerosoft would probably have to do it again with WASM & C++ (so it's easier to maintain and easier for them to extend in the future).

Edited November 11, 20214 yr by abrams_tank

11 minutes ago, Daytona125 said:

If this is the case my next purchase will definitely be the Fenix A-320. I just want a plane that works as it should. I would love my beloved 737 but if it doesn't have radar I'm not spending(probably a lot of money) on something that doesn't fit(for me).

I believe Fenix said their A320 won't have terrain & weather radar either, for the same reasons that PMDG and Aerosoft won't.  I don't have the link but you can search for it - I think it's something Aamir from Fenix said before.