kterz

Hi, when ActiveSky reports runways "in use", it follows the exact logic the internal fsx/p3d atc has when determining which runway the AI (and/or user aircraft) will be assigned. So, in 99.9% of cases the active runway reported by AS is what you'll get from the internal fsx/p3d atis. Unfortunately, there are limitations in the way the internal sim atc handles parallel active runways. And depending on the conditions (calm or variable winds, cross wind with slight magnetic errors in the scenery bgl etc), you may end up getting active runway(s) (from ActiveSky/simAtc) that is/are different to the ones reported by real world sources, even if wx conditions match 100%.

Hi, ActiveSky (since ASN) actually does that (plays an altered audio file when hail is present) and depicts snow in order to give the closest possible (within sim restrictions) feeling of being in hail. So, it doesn't work? What is the ambient precipitation reported by ActiveSky debug window?

Hi, unable to reproduce the "change back to live weather and ws warning not going away". In my case, once live weather was downloaded and injected, the winds and warning disappeared (as they should). May be it's a timing issue and since this is easily reproducible, I welcome any fellow simmer/ ActiveSky user to give this a test. If there is an actual bug, then please open up a support ticket so that we can investigate in which configurations this surfaces up. One other thing that would be really helpful is to enable the "Shear" button on the map. This would show something like this: This shows the presence of a microburst around the airport at the time. Please keep in mind that gusts are a different thing compared to wind shear/microbursts. The wind direction in a microburst is centrifugal (and not "steady") from a specific "center" where also the downdraft is maximized. This is the way this phenomenon is described in real life and that's the way we simulated it. As for your landing issues, I suggest (at least for GA aircraft that don't have an on board radar), that you install XGauge and enable the aural prediciton warnings. Cause in these conditions you are really lucky you didn't actually crash :)

Hi, just uncheck the "Realistic thunderstorm up and downdraft rate" and you're done. I think however that the simming community underestimates (and thus considers "unrealistic") the issues coming up due to the huge amount of energy accompanying thunderstorms. In contrast to the way people feel about them in real life. It's not unusual to get 6-10000feet/ min updrafts/downdrafts when penetrating a thunderstorm (or when the 20miles upwind safety margin is not respected). And that's what ActiveSky attempts to simulate. Take a look at this: https://www.airlineratings.com/news/thunderstorms-a-must-to-avoid/

Hi, not sure the exact time you've been there. This is what I get for yesterday: at 1400z: EBAW 181420Z 27015KT 250V310 9999 BKN027 07/02 Q1002 TEMPO 25025G35KT at 1500z: EBAW 181520Z 28012KT 9999 SCT032 SCT045 07/02 Q1002 TEMPO 25015G25KT at 1600z: EBAW 181620Z 27010KT 9999 SCT032 SCT045 07/01 Q1002 TEMPO 25015G25KT at 1700z: EBAW 181720Z 26006KT 9999 SCT032 SCT045 07/02 Q1002 TEMPO 30015G25KT 3500 SHRA at 1800z: EBAW 181820Z 21006KT 9999 SCT032 SCT045 06/02 Q1002 TEMPO 30015G25KT 3500 SHRA at 1900z: EBAW 181920Z 23008KT 9999 -TSRA SCT020CB SCT045 06/03 Q1002 TEMPO 30015G25KT 3500 TSRA while the TAF for the following hours was: EBAW 181711Z 1818/1903 25010KT 9999 SCT025 TEMPO 1818/1903 30015G25KT 3500 SHRAGS SCT008 BKN012CB Please refer to the exact metar when reporting an issue or claiming that something is not realistic, so that we can be on the same page

AS16 and AS for P3d version 4.x do not create multiple overcast layers. This was an option only back in ASN but is not needed since we introduced ASCA overcast models so it's disabled by default.

Hi, "Something" corrupted the file wxmapping.bin inside p3d\weather folder, hence the message you got from ActiveSky. It was just attempting to restore it (and it failed). Recent versions of ActiveSky (since ASN) just read and do not touch this file anymore, since our depiction is not based on internal sim station anymore. A corrupt wxmapping.bin will cause a CTD in weather.dll This is known since many years ago. Our support team will help you fix it.

It shouldn't be there when ASCA overcast cloud structures/ models are installed. I remember working on this specific issue more than a year ago and made adjustments to the radar code (when working with the ASCA model) in order to fix this issue. Keep in mind that any adjustments I make to the radar code have to be model specific (cause as I said the "stitching" of the cloud models is different each time). There is no "generic fix" on this one, cause this is not ActiveSky's problem per se. It's the overcast model's design that leads to it (in an attempt to make the overcast more solid) So, are you sure the ASCA overcast model was properly installed when you tried this with ASCA? If yes, I'll need more info and proof (screenshots etc through a support ticket), to see what's going wrong.

Hi, keep in mind that the radar depiction reflects the actual precipitation produced by certain clouds, so it's greatly affected by the cloud structures used in the sim. So, the "solid overcast" advertised by the cloud structure program you may use might also mean that the lateral "stitching" of the cloud structures is affected and while this may not become apparent when looking directly the clouds in the sim (unless maybe you look carefully), they are revealed when looking at the radar as these grid lines. With ASCA (and the default fsx/p3d overcast models) we have full control where the cloud sprites are, so we avoid these issues altogether. We cannot ascertain however that it will show up ok in all cases regardless of the depicted cloud structure. The radar signals are just a vertical projection of the depicted cloud model (assuming all of it contains precip).

Hi, this is unrelated to ASCA (or Active sky). It's the way cloud sprites are rotated by the way P3D is rendering them. In your case it's more pronounced due to the low zoom level (I think). In addition, the GPU/driver combo may play a role as shaders tend to behave differently in some cases (e.g. ATI cards)

Hi, both ActiveSky and ASCA API are well documented and open for integration. Any add-on can take advantage of the dynamic cloud/sky texture handling ASCA offers.

Hi, Most of us have been using 64bit CPUs and 64bit OS since many years ago. The big difference is that now the sim will actually be 64bit (it will be compiled using x64). So, in addition to the gains in memory what does this mean for the performance of an application? - First it will avoid the indirection layer of WOW64 32bit emulation used in Windows. This leads to to a slight increase in performance. - In x64 mode an application has access to twice as many registers compared to 32bit (the so called x86 mode). This means that local data calculations will not need to access the main memory, more cache memory will be available and thus we'll gain speed. - It uses double the number of XMM registers (the ones used for floating point calculations, vectors etc). - Functions are called with the "fast call" convention, avoiding (in many cases), CPU cycles to create stack frames etc. - On the other hand, a single pointer is now 64bits, meaning it's double in size, so for relatively small data (such as a small array), this means you'll need double the amount of memory. So, what's the net effect? A simple recompile of an application to x64 bit without any other changes/optimization as an average will lead to a 20-30% increase in speed, but this depends on the type of the application. For a whole world flight sim, where the "basic stuff" (such as the lat/lon coordinates) need to have double precision (aka 64bit), this is even more important and so CPU performance will likely see even more benefits. The one thing you have to keep in mind as far as modern games are concerned is that the main bottleneck in most cases is not the CPU. It's either the GPU itself (depending on the power, the AA level and the amount of semi-transparent objects that need to be rendered such as the clouds) or CPU-GPU communication. In a whole world sim, the disk-RAM also play an important role as we need to update objects and textures on the fly As far as P3D v4 (since I've been a beta tester), I think we get the expected performance gains. I've seen (on my modest machine, with everything default except for AS/ASCA) a steady increase in frames from 25-55 in P3D v3 (depending on the conditions) to about 35-75 in P3D v4. Of course YMMV and things will probably get worse as we add more addons and stuff, but I think it's a good starting point. Kostas Terzides, Active Sky developer

Yes.

Not true in full dynamics mode. See my explanation here: http://www.hifisimtech.com/forums/showthread.php?6529-Difference-between-full-dynamics-and-global-automatic&p=32482&viewfull=1#post32482

Hi, this has been fixed and will be part of an upcoming hotfix. For now, first close AS16 and then the simulator

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, thanks all for you feedback. A couple of notes: - Texture size: In all static themes and in global automatic mode the texture size selected by the user is fully respected. In "Full Dynamics" mode, several clouds may have different textures (of different size each). So if for example you have selected texture size 2048, some cumulus congestus clouds may be 2048 (as they need to be sharper), but softer overcast stratus ones may only be 512 (cause they actually don't need more). In Full Dynamics you can get both of these clouds in the same "scene". The selected texture size (in our example 2048) in this case, behaves as the "Maximum allowable texture size". So, you'll get 2048 or less. - Cloud motion effect: This effect was designed with the first thing in mind to have zero impact on frames (and it does). Due to that, it's not calculated per frame and some small inconsistencies may be noted. But, in real life we also may get this feeling for a couple of seconds after exiting the cloud (or prior to entering the cloud), so it's not that bad. We do acknowledge however that up to point this is subjective and some of you may not like it. That's why an option was provided.

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.