kterz

Why hundreds? Hundreds of areas 1000nm each? May I ask why is this so important?

You do know you can copy/paste custom weather on the map if needed?

Hi, the original post was referring to ASN not AS16 and you never clarified you were talking about AS16. In AS16 it's not possible to set it above 1000nm at the moment (a restriction related to the way it's drawn on the map). If more interest exists on this, we'll consider adding this back somehow. Edit: And to respond to the request the OP had, just set it to manual mode and don't do anything else. This way each airport/area will have its own weather, but ASN will not download more data, so they will stay the same.

Hi, here it is: Are you sure you both use ASN SP5?

Hi Ken, Our wxr radar (airborne mode, not to be confused with the NexRad functionality) is designed around the Collins WXR 2100 model with a beam width of 3.5 degrees and multi scan support if needed (but I think Roland is not using it). I think there was a misunderstanding (blame me for that). I really like the comparisons you made between the airborne and the NexRad images. I was specifically making a comment about this phrase: "I agree lots more testing is needed and I think there are some limitations to either ASN or even FS. Mostly with very large thunderstorms fail to represent as large columns filled with precipitation" This just gave me the impression that you didn't really understand specifically how our external api works (the one feeding e.g. Roland's gauge with data), But now re-reading it, I think you're correct. The basic limitation is that the thunderstorms in the default fsx/p3d cloud models are just too small. This has been improved with the new t-storm cloud structures included in ASCA, but still needs improvement and we're working towards this goal. The main compromise in these cases is always performance. One of the most performance intensive depictions in FSX/P3D is hurricanes. I don't know if you had any chance to fly through a hurricane with ASN. The radar image you'll get will be nice, but It certainly is tough for performance. In any case, there are still things we can do to improve it and we're working hard to get there. I know what you've been through, I've been there too Many times... Believe me it was not technical reasons that made us select this path. I don't think the community needs any proof as to what we are able to achieve as far as overcoming technical limits and raising the bar higher (the latest one being enabling dynamic cloud texture and sky color changing). And we could actually release a gauge that could work with any weather engine within 15 days. The code is in there, it's just disabled. Yes, working with the weather AFTER it has been generated. It's just a different business approach (and philosophy) we're talking about. And while I respect the approach you took (and the effort you made to get there), the final judge is always the community that has to answer a very simple question: Do they consider the experience they get from your simulation but without ASN/AS16 installed and running adequate? The key here is the term "adequate". If just varying the precipitation intensity is enough, then I am sure it will be perfect for them. If they want however an actual simulation of a weather related aviation hazard (which is the single reason they bother to install these units in real life), then I am not sure how this can be achieved without proper synchronization with the weather engine itself.

Hi Ken, you obviously have misunderstood how ASN/AS16 api works and it seems that your knowledge of the exact way ASN/AS16 works is limited, so you run into false assumptions when you talk about "ASN limitations". You shouldn't directly compare it with the NexRad image we show on our XGauge and main map. Roland's gauge, our own new gauge in AS16 (in airborne mode), the PMDG, Majestic Q400, FlightSimLabs A320 etc NDs all use our api which also simulates a narrow beam of radar and measures the aggregate precipitation intensity intersected by the beam. This accurately matches the level of the precipitation intensity (and type) you'll get as we directly control it based on the radar signals. If your tilt is wrong, then you have a danger of overflying an anvil top at cruise altitude and run into bow wave turbulence. We've even taken into account details like the reduced radar signal strength of ice crystals (in hail or at the top of a cell) The main difference with Active sky (and the radar implementations that are based on it) is that what you get in the radar actually matches exactly with the hazard your are about to encounter when you get into the "reds". This includes hail (if there), severe turbulence and updrafts/downdrafts. In the case of AS16 we actually made this so that if you try to fly a small aircraft inside the "reds", the wind shear will be so severe, that you'll definitely lose control. The proper modelling of a "system" in our flight simulation world means that a specific technology that a real aircraft has is modeled so that if the system does not work, it has certain consequences. In our case the "system" is the wxr radar/pilot/weather avoidance as a whole. If the weather avoidance procedure is not followed and you fly into the "reds" and nothing happens, then the system is not modeled correctly. Similarly the predictive wind shear (pws) functionality which by the way is part of the wx radar technology of at least airliners, if not coupled with a windshear/microburst effect, is just an eye candy icon on your ND/gauge. So, given the default fsx/p3d weather limitations (for proper simulation of hazards), I really don't understand the argument that a weather radar can work with "all weather engines". The weather radar and the weather engine are things that need to go together. We could easily create a gauge as a separate commercial addon more than 2 years ago when we first introduced this technology and earn more money this way. But this would not be a complete and correct "system" and in addition it would be too restrictive and wouldn't let us improve the whole technology as we move forward. On the other hand, there are obviously different views in the community on what's important to our simulator experience and on the definition of immersion and that's something I do respect.

A couple more comments: - As mentioned previously. AS16 and ASCA may be on a network machine, but they have to be on the same machine. - Please don't run ASN and AS16 interchangeably for the same target simulator. AsConnect interface is different between them and you'll run into trouble unless you remember to install each time the "correct" dll. (i.e for FSX, run ASConnect_FSX_Install.exe before using ASN and run ASConnect2016_FSX_Install.exe before ruinning AS16). This is not a problem if the applications target different simulator that is if you have both FSX and P3D installed and you want to use ASN for FSX and AS16 for P3D (or vice versa) - ASCA is cross- compatible with both FSX and P3D (if both installed). When you run the respective AS16 version (for FSX or P3D) , it will automatically update the target simulator for ASCA. This way it will know where to install the content.

Hi, "solid overcast" is a feature of ASCA, not AS16. Did you get ASCA too, cause this doesn't seem like ASCA to me

Hi, the problem is how the sim understands what we consider a specific coverage. That is for example if the metar specifies -TSRA FEW CB, we'd expect to look at the sky and see mostly clear skies but some areas of the sky (eg 2/8) would have a large CB. Now, try setting in FSX/P3D manually (with user defined weather) a single CB with 2/8 coverage. You'll immediately understand what I'm talking about. The sim will insert many "tiles" of few cumulus clouds with several very small "pseudoCB". And you'll get lightning out of blue skies too often, due to the way the sim calculates the area the effect should be activated. So, in ASN what we did to circumvent this is we added the High detail thunderstorm option, which will essentially skip the metar and try to create a more believable thunderstorm depiction by adding several cloud layers. This however has a significant performance hit and I believe now we've set the option to false by default for this exact reason. So, to resolve the OP issue, try enabling this option. In AS16/ASCA we have completely redesigned the cloud models used to depict thunderstorms trying to improve the depiction and at the same time trying to avoid too much overdraw (leading to a performance hit). You'll soon be able to test all this BTW: @Rob, we do ackowledge that in ASN one of the ways we used to provide variance in cloud depiction lead to non-reproducible test cases. This has also been addressed in AS16 by using a new hash generating algorithm.

Yep sky textures do change the way you describe. But ASCA does not include runway textures Yes of course. As Damian already responded backward compatibility is kept and is first priority to us. The weather radar works the same (and even better) way it's been working since we introduced it first about 2.5 years ago. Remember when we initially announced it everyone was skeptical. But it took only a couple of months and it became reality. When we announce a feature or new functionality it usually means it's already being tested for a significant amount of time and it's almost ready to release. This is something that the fellows who were lucky to attend fscon can verify as we had a demo of a system up and running. All these years we rely on a relationship with the community that is primarily basebased on confidence. We always try to be sincere and avoid misleading with promises we either can't keep or fulfill only after several years later. So everything we present here is actually working and is the result of hard work we've done during these last 3 years. It's there too

Hi, please check our forums as Damian just released a new build. We seem to have addressed this. Try it and let us know. Thanks, ASN developer

Hi, I assume by cloud cover you mean cloud draw distance. This is actually controlled by ASN itself and you can set the low and high limit of it. For example you can set the minimum cloud draw distance to 60 and the maximum to 130 and this way ASN will attempt to vary this based on the actual fps load. For example when on ground on a (or while approaching) high detailed airport, ASN will drop this to 60 to preserve somewhat your frames. When flying low, you don't need more than that anyway. In contrast, when flying at FL350 ASN will automatically increase it to 130 (if the "cloud load" is not too much). You can see in ASN debug window the actual selected cloud draw distance (CDD) in real time. Just make sure you avoid extreme values (e.g. 200), because this may cause memory issues (sometimes manifesting as disappeared clouds)

Hi, There are 2 things that come to play with this: - First, when icing should be applied - Second, what are the effects of excessive icing accumulation. ASN is (and should be) responsible only for the first one. The second one is relevant to how the flight model is affected and is aircraft specific. What ASN does is dynamically apply icing accumulation rate based on the environment the aircraft is in. ASN is the only way (at least for now) you can get icing outside a cloud in the sim (e.g. sitting on the runway in freezing rain), because in the FSX/P3D simulators icing by default is triggered only when the aircraft is "in cloud". As for the flight model consequences, I remember a couple of years ago, while testing our code, I left an NGX on a holding pattern at clean configuration (with wing anti-ice off) at about 210 knots and applied constant max icing. Since the aircraft was on auto pilot during this (as I did other stuff in the meantime) I can't tell when things started to feel "not right", I do know however that I got a stall warning after about 30-40 minutes during a turn. So. icing definitely affects the flight model. I suspect smaller aircraft will be much more vulnerable, but haven't tested it. I know things can be improved in this area significantly, but I am also a proponent of what we call in programming the SRP (single responsibility principle). This is directly applicable to sim addons too. The weather engine should only figure out when to apply icing, but how the aircraft behavior is affected should be determined by the aircraft designer. This is the way to get the best results overall. I am very happy to learn that there are aircraft addon developers that have started taking advantage of our icing related API (as they do for ambient turbulence too) and we'll see the results of it soon.

Hi, The scenarios provided by the 2 simmers here are no proof of a memory leak (or memory overallocation which is another thing) either coming from ASN or P3D itself. I would call it efficient memory management instead. Since, there is plenty of free memory in both cases, it only makes sense to skip unloading this allocated memory until a new allocation is needed that will replace it. This way if for example the already loaded cloud models and/or textures need to be rendered once again, this will happen much faster (i.e. less stutters). As I already responded on our forums, longer flights with various weather conditions reaching VAS to the limit may be needed to figure out if P3D is managing memory correctly in these circumstances.

Hi @David: Yes. Otherwise whenever ASN injects 8/8 clouds and you have this set to medium, you'll get 4/8 clouds in the sim @James: As I said, this is an issue that we have to fix. As for the other issues ("metars in the future", DZ etc), let's continue this on our forums (including logs etc)