kterz

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)

H James, we' are aware of an issue in our signal attenuation with distance algorithm, that may lead to increased signals close to the aircraft. What we tried to do is to fine tune the extent that signal intensity attenuates as the radar beam spreads with distance (at some point during ASN SP3 development). That seems to work inversely and may adversely affect signals close to the aircraft in certain cases. By increasing the ND range, I am certain you will not only get "red" signals. We'll adjust this at some point. I will not comment on other posts that are not specific enough and may be the result of not correct (i.e. unintented) usage of our technology. I do want however to make some other comments: - You can't expect to get realistic thunderstorm depiction when the "consensus" (by well "respected" community members) tends to be to have the cloud density slider set to medium, in order to preserve performance (especially in P3D). - Lightning: ASN does not control that and is unrelated to the way the radar works. You'll get lightning out of nowhere if you add a CB cloud with a coverage 1/8 or 2/8 in the sim. It's in our plans to try to "fix" this too, but it's not yet here. - In FSX/P3D currently there is no way to visualize rain shafts/virga in the distance. So it's all about what we get at the aircraft positiion and the radar is working based on what ASN will inject as precipitation/turbulence at this specific point once the aircraft gets there. - What ASN does is control the ambient precipitation intensity in real time and keep turbulence and generation of up and down drafts in sync with that (as proven by ASN debug window). This includes hail generation when certain criteria are met. These are the only things a weather engine can (and should) do. The final "effect" you'll feel in the sim obviously depends on other things (aircraft weight etc). Obviously not everything is perfect, there are bugs and limitations (in both our code and the sim) and we always try to improve things moving forward. But I do wonder if you set in ASN settings the max up/downdraft values to let's say 2000 feet/min, check the detailed thunderstorms option, have cloud density to max and then try to fly in a thunderstorm ("red") area how well you'll be able to control the aircraft on approach (or at cruise). Of course to get all this ASN has to be up and running.... Have a nice weekend.

Hi, manual weather can only be set to weather stations and not directly to airports. If you wish to do this, then you'll have to create a new wx station and add it to ASN's database (read the manual on how to do this)

Hi, one of the reasons ASN may strain the simulator during weather updates, is due to the way the clouds need to fade out and redraw themselves. This is the downside of getting completely seamless cloud changes that resemble how conditions change in reality with no cloud shifts. Forcing cloud shifts is always "cheaper" for the graphics system and it's possible to be enabled with ASN. Add this line in ASN.cfg (in [ASN Settings] section): - SmoothThemeLoad=0 Of course before going there, there are other things you may want to try first, for example enabling the option: "Suppress local weather changes". In addition, try playing with SGSS, CloudDrawDistance, maximum cloud layers etc until you find the correct balance for your setup. Having said all that, in Richard's case I am not 100% convinced that ASN is his issue...

James, This option is still there in ASN for FSX (SP2) (and if I am not wrong this is the MS FSX forum, correct?). Obviously Carsten is using P3D. In ASN for P3D the option is removed as this option is off by default (this "fix" is not needed in P3D).

Glad it worked I'll simplify it anyway though

Hi, assuming that the screenshot is at "Local machine" here, then 2 possibilites: - Double click the install_path and paste: "C:\ActiveSkySnapshots" - Make sure "ASv6.exe" is present in this folder. If it's already present in C:\Users\Owner\AppData\Roaming\HiFi\ASE, then copy it to C:\ActiveSkySnapshots. If it's not present, then make a fake one (as suggested above). If you run into trouble, let me know and I'll attach a fake "ASv6.exe" file to you I am about to simplify this. I'll add an option ("Common export path"), so that you can do this using ASN itself with no need for registry changes. Not sure when this will be released though.

Hi, which version of ASN do you use exactly? There were some issues casuing SimConnect to freeze that were resolved in the latest beta. Please open a support ticket considering this

Which exact version are you using? There was an issue identified and resolved in the latest beta: http://www.hifitechinc.com/forums/showthread.php?4338-ASN-SP2-OPEN-BETA-For-FSX-FSX-SE-and-P3D

Hi Vernon, they are above the destination airport. Winds however don't change that much laterally within let's say a descend path of 80 miles (while they do change vertically). This is an approximation we're discussing anyway here and still preparing this in preflight may be inaccurate (if the leg is long). Of course there are exceptions (as in the case of very long STARs), in which case it still is best for this to be done manually based on raw data. Frankly though I think that the NGX FMC is very accurate in most cases (for short to medium flights) by just providing it the average winds in ASN briefing.

Hi, try using live wx briefing in ASN by tuning to 122.05.

Hi, easiest way to open ASN debug window and then create a test micro-burst. Read ASN documentation for more info.

Hi Richard, that's great, thanks for confirming it actually works

Hi Vaughan, Actually there is a way to do this. It relies on (undocumented) code that keeps compatibility with older versions of AS. Here are the steps to do this: - Create a (common) folder you want to keep the exported file, let's call this "F" - Create a registry key in HKLM (Local Machine) in Software\HiFi called "ASv6" (If needed create the key HiFi too) - Create a string registry value called "Install_Path" inside this key and edit its value to point to "F" - Open up notepad then click File-Save As and then select "F" as the target folder and as name "ASv6.exe" (including the quotes). This fake file will make ASN believe that AS v6 is installed and it will export the snapshot into this folder. This file is updated each time ASN parses new weather data (and it depends on your setdownload interval). You may run into security issues if ASN is not able to access HKLM, but if you have UAC disabled and run ASN as admin, I think you will not have any issues This is a "dirty" unsupported solution, so give it a try at your own risk. In any case, this is a very interesting idea and we may automate and make this official in the future. Let me know if this works for you!

Hi, we're talking here about 3 different things: - The "NewMaterialUsage" shader fix. This is autmatically applied by ASN and prevents cloud poping and is not related to terrain intersection. Note, that this is not resolved in 100% of cases. For example if using DX10 fixer "Discard Fogged" option and when visility increases dynamically by ASN, apparent cloud popping may also come up as fsx decides that a cloud sprite previously not shown should now be drawn. - The DisableHazeLayer/EnhanceHazeLayer options. If the first is on and the second is off, can indeed help avoid the well known terrain intersection problems caused by drawing a low cirrus cloud layer to represent haze. The drawback is that this way we get the issue of climbing above hazy conditions only to be able to clearly see terrain below us. Having both of these options set to on, is a good compromise (my personal preference), as we get a subtle localized haze effect applied only to "significant" airports along our flight plan. This way terrain intersection flickering chance is mimimized (but not 100% eliminated) and we still get the nice feeiling of hazy conditions (when surface visibility is reported to be about 4-8SM) - All cloud/terrain intersection flickering. This is a z-order issue (as already discussed by Devin). This is aparrent with any clouds and is the result of a bug in fsx calculating the z-order of cloud sprites only based on the lateral distance to the camera view point. This is the main reason we only notice this when the camera view angle is relatively vertical (and this is also one of the reasons we also notice weird gaps/sprite rotation issues when "looking down" or "up"). The cloud rendering system (at least in fsx) is optimized for relatively horizontal camera view angle values.

Check for airmets/sigmets affecting your route. in addition, windy and gusty condtions at departure and/or destination give a hint about the presence of turbulence. Best way (IMO) is to use 122.05 This gives a live (updating as you fly) briefing including warnings about possible weather hazards (sigmets/airmets/t-storms/wind shear/microbursts) that you may encounter in your flight path. Of course, turbulence is not predictable in many cases, but the above will give you info about the most significant ones.

Hi, most possibly a corrupt dll.xml Take a look here: http://www.hifitechinc.com/forums/showthread.php?4087-Common-support-issues This shows an example of Simconnect.xml, but the same rules apply to dll.xml. So, there must be some kind of typo or error in your dll.xml and fsx cannot parse it. Please attach it to let us take a look if feeling uncomfortable doing this on your own.

This depends on the "active" cloud draw distance. If you have it set to e.g. 60-110, then on ground you'll get detail with 60 miles zoom

Hi, I tried to reproduce this using historical weather around the time you posted the first post, but the winds were not close, so a first suspicion is that you didn't use live weather. Other possible causes: - The winds did actually change from the time you initially obtained the first report. There is an option in ASN (prevent downloads on approach) that will prevent such "surprises". - Close to KLAS there is at least another weather station reporting different winds in many cases. If you haven't specified KLAS as your destination (using a flight plan) within ASN, then the final result will depend on both stations. - The winds may have been variable. While this is included in the metar text, it may not be reported in the atis. ASN does actually take wind variability into account when deciding how to depict winds. It's important to clarify the active date time ASN used when reporting such discrepancies, so that we may have a chance to reproduce the conditions and see what happened. Alternatively, copy paste the metar text from the conditions page.

Hi, ASN decides if it should rain on the lateral axis based on the radar signals it receives. So, in the case of Jim's 3rd screenshot, it might be the case that no clouds/signals exist above the aircraft. So, cross checking with ASN's map (in detail mode) will tell you if something is indeed wrong. As for the rain above the visible clouds, the problem may come up in case of rather thin stratus clouds, where ASN assumes a specific thickness while in reality it is much less. In FSX, the cloud model thickness and vertical scale are determined in code, thus in most cases we're able to detect it within an acceptable error margin. In P3D however, the cloud model scale logic has moved (completely) to the shader/GPU code and with all the recent P3D changes in this regard (that solve other issues), we may have a mis-sync. We will attempt to make our calculations more conservative, but please open up a support ticket with the details (including the exact version of cloud.fx file you use) to help us track this. Thanks (and Merry Christmas to all)