kterz

Commercial Member
  • Content count

    215
  • Joined

  • Last visited

About kterz

  • Rank
    Member

Flight Sim Profile

  • Commercial Member
    No
  • Online Flight Organization Membership
    Other
  • Virtual Airlines
    Yes

Profile Information

  • Gender
    Male
  1. 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.
  2. 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.
  3. 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.
  4. 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).
  5. 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)
  6. 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.
  7. 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
  8. 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
  9. Hi, this has been fixed and will be part of an upcoming hotfix. For now, first close AS16 and then the simulator
  10. Why hundreds? Hundreds of areas 1000nm each? May I ask why is this so important?
  11. You do know you can copy/paste custom weather on the map if needed?
  12. 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.
  13. 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.