I'm a fan of the working RTA function B)

First flight occurred without incident (77W syd-mel).

Noticed RTA is operational. 77W accepts RNP to two decimal places. Noticed Oxygen Mask Selectors were set to NORMAL; those bloody mechanics! Love the DATALINK capability.

 

Used ASN to create thunderstorms with low vis, attempted an autoland to no avail, went missed but laptop froze after pressing TOGA. It struggled under an already heavy load and failed. Good to see WXR>PWS.

 

The 'Trip' is a big weirdo to fly, coming from a prolific 738 flyer. Hope to see a PMDG product in X-Plane soon. FSX gives me the sh*ts.

 

Brian Nellis

Brian, strangely enough, the same thing happened to me before before SP1.  I had to go missed @ KSEA while doing an autoland, and the sim locked up.... Weird.

 

 

Jakob Ludwig

Kostas

 

Could you just explain that a bit more? As to why a different wx engine would result in different effects? Isnt it the wx engine that generates the effects and your DLL takes the information out of the sim to then represent it on the Radar. Isnt your DLL just working around the broken simconnect function? which LM are said to be fixing? I only ask as REX appear to be developing a stand alone method also to fetch this data from the sim, which they say will also be independent of any particular WX engine?

Hi James,

 

let me try to illustrate this with an example anyone can try. Say you use default fsx manual weather with no weather engine running. And select to create a single overcast "thunderstorm" cloud with a cloud base of 10000feet (10kft) and a cloud top of 30000 feet (30kft). Set precipitation to heavy and set it to reach the ground.

 

Now, if you load this into an area in fsx, it will create overcast clouds that are about 10kft feet thick (instead of the expected 20kft) with a few rather small thunderheads extending to about 30kft. Moving around with the aircraft around this you'll get the same level of precipitation either above the "visible" cloud (at about 22 kft ), below the clouds (at 5kft), or inside the thunderheads (when you're inside visible cloud at about 22-28kft). Similarly, you'll get the same level of turbulence if you define that the cloud has let's say heavy turbulence. Both in and out of the cloud.  There is no variation based on the actual visible moisture, the actual cloud thickness above the aircraft, or if the cloud moves with the wind. Things become worse if you don't select overcast coverage, but let's say few or scattered (< 5/8). The problem arises from the fact that fsx applies an effect (precipitation, turbulence etc) to a broad "box" that contains the cloud approximately even in areas that there's no drawn cloud. You may recognise this "box" as a green rectangle depicted in an attempted radar implementation by a well known aircraft developer recently (after ASN release).

 

Anyway, this leads to a very well known bug in fsx: "rain out of nowhere". So, the main issue when designing the radar is not the radar itself, but to actually make the radar signals and where the cloud is drawn synchronise with the ambient effect. This is not possible if we leave this to "fsx to decide". Other weather engines (as far as I know) just signal fsx to use some values as is done by setting the manual weather in fsx. This is the "official" way of doing it (either through simconnect or by creating theme files). But in all these cases we just say to fsx what values to use in the specified boxes and we don't avoid the issues I mentioned above. In contrast with ASN, we took full control of ambient precipitation. This is the reason I insist ASN has to be running. It's not only rain (or hail that's an ASN only feature). It's the turbulence and the updrafts/downdrafts creating the whole experience. ASN directly controls the precipitation rate/turbulence intensity and the wind vector and it creates the ambient effects also based on radar signal processing. 

 

For example one thing many users may have missed is that we create a significant updraft inside the "red cells" (resembling the convective activity), while around the cell there is variable downdraft based on the precipitation intensity. This creates vertical shear conditions even at 35kft (as in real life) that will be missed by the PWS of aircrafts like the T7 as they are designed to detect wind shear at lower altitudes. Remember updrafts/downdrafts are something different from turbulence and if strong enough you will lose control of the aircraft. 

 

So, a realistic radar implementation inside a simulation such as fsx requires obviously the image creation based on the drawn clouds/precip areas (as has already been partially done in the past). But even more importantly it requires handling the ambient effects in a much more sophisticated way than fsx does by default, so that the radar image actually becomes meaningful. 

 

These effects may have some meaning for some users and may not for others. Simulating a microburst, or varying rain intensity based on the cloud thickness above you or the cloud movement may mean nothing to you. And the only thing that may matter is a nice looking radar image on the ND. I understand it.

 

Believe me it would only make  business sense for us to sell 2 products (a wx engine and a separate radar) instead of 1. After all,  I have full confidence that ASN is the best wx engine out there even excluding the radar functionality. But above all we are trying to make the radar related experience as realistic as possible. If it was possible to do this in a way that satisfied us without the need for the wx engine to be running, we'd do it. But it's not possible. Others claiming they can do it, have to prove it first. And in the end everything is up to you (the users) to judge, correct?