Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by virtuali

  1. Hi to all, with the XBOX release only two weeks away, are there any news about the availability of the previously announced USB Hub, which will be required to connect the existing Alpha Yoke to the XBOX ?
  2. Just wait until someone will find a way to mine Ethereum with the Bravo...
  3. Does European market includes Switzerland too ? I've order mine from one of the largest PC hardware distributors in Switzerland ( Digitec ), in August 2020, and it missed the promised delievery date about a dozen times already.
  4. Mathijs, I respectfully disagree with you (we known each other from such a long time, that we basically grew old together with Flight sim...) so you will not mind if I'm telling you are wrong this time. 1) Access to GSX pre-release. Wrong comparison here, I never had any access to AES BEFORE it was released, so it would be unfair to compare a very different situation. Oliver will surely receive his free copy of GSX now that is out, although he surely can check it already if with all our airports, included AES interoperability, since all our airports also have AES... but, as I've said, he'll receive his free copy now, no problem. 2) Use of the intelliscene file. We HAVE our own interface and file format to recognize and configure airplanes, which is way more complete and complex comparing to what the intelliscene file does, since it adds (for example) dedicated entires for catering doors, not just as mirrors of the main exit, so we can accomodate asymmetrical exits like in the 737, and we can specify custom code to recognize non-standard doors and ground connections and much more, it's a file format written *IN* the Python language, it doesn't have any similarity whatsoever with the standard .INI file format that it's used by AES, even conceptually. GSX by default use that one, and this is what we prefer users will rely on. But, you can't blame GSX for being able to read EXISTING intelliscene files that might be ALREADY in possession of users, which are just plain standard .INI files, and are only used as a 2nd best option, if the airplane in unknown to GSX. In fact, recognizing the intelliscene format as a de-facto standard, is exactly the opposite of "competing" like you said, if we were trying to really compete, we would have introduced our own similar-but-slightly-different format, in Microsoft style, as when they "improve" the html format, in order to break a standard.
  5. Yes, that's correct. I've replied to simply clear up the issue, because the term "downsize" was a little bit ambiguous. That's why we prefer to say we "back-port" to FS9, to indicate that, whatever can be ported (because is supported by FS9 as well), will go in the FS9 version, the rest will not. That's not entirely correct. Or, better, is not the whole reason. In earlier sceneries, we had ground traffic vehicles (not road traffic, aiport traffic) in FSX made using Simconnect objects driven by our Addon Manager, which is very convenient, because we just need to lay down a track, and the vehicle will follow it, complete with realistic ground physics, because it's a real simulated object, so we could specify speed, acceleration, etc. For the FS9 version, we had to do extra work, to layout an animation track in GMax to get a animated BGL with static objects: an entirely different method, which also lead to inferior results, due to the lack of the ground handling physics, that required to do extra work in FS9 that wasn't really needed in FSX. We did this for some sceneries, but then decided the extra work wasn't worth the effort so, in spirit with the decision of porting only what can be ported without doing extra work in the FS9 version to replicate an FSX feature, we stopped adding those animations in FS9.
  6. Hello Rainer, We haven't downgraded anything in the FS9 version of our sceneries, because we haven't created any road traffic for KLAS and KFLL even in FSX, it's FSX that creates that for us! That's just how FSX works: if you draw the standard VTP roads, that we need to draw anyway in order for the scenery to match with the nearby road network, FSX will populate that road with traffic, without any further work on our part. So, we haven't "downgraded" the FS9 scenery at all, and expecting to do extra work trying to replicate FSX-only features in FS9 is just wrong. For example, FS9 doesn't have bump mapping or specular mapping. So, obviously, the FS9 version of our sceneries, and any other scenery out there, do not come with bump mapping and specular mapping textures and nobody complained about this. The same with road traffic: it's a feature that is an FSX default capability that FS9 doesn't have, not something that we specifically made so, same as with graphic effect, it's just wrong to pretend to have it in FS9, or saying that we "downgraded" the scenery or removed the feature in any way. I had to post this, because I think there might have been some kind of misuderstanding about this issue, as if we purposely "removed" something from the FS9 version, and it's not the first time it happens: some users complained that the FSX KFLL screenshots were much better than FS9, because the port was shown in the background, as if we did that one too and "removed" in FS9, which is not correct as well: we haven't modeled the port in FSX either, it's part of the FSX default scenery from Microsoft, which is simply way more detailed in FSX...
  7. They always have. Of course, only with AI models that have the Exits tagged with xyz coordinates in their aircraft.cfg so, if you used FS9 models without any modifications, the FSX jetways wouldn't work, because ther's no location for the exits in an FS9 aircraft.cfg. It's basically the same situation of the user airplanes, the FSX jetways works only if the exits are present and listed in the FSX format. However, there's usually a performance penalty involved when using FSX jetways with AI, because the skinned animation system is quite costly so, having an airport with 100+ FSX jetways, is going to cost something on fps. A common suggestion to improve fps, is to remove the exits from all AI models (all the FSX default airplanes have them), so FSX jetways will no longer attach to them. We managed to improve the performances somehow, by using the skinned animation only at the highest level LOD so, our jetways will attach to AI airplanes, but only when close to your viewpoint, because the lowest LOD versions of the jetways that displays in the distance do not have any bones attached to it. But of course, having no bones animation at all, not even for the user airplane (like in AES) would always be faster than having only the closest ones displaying...
  8. No, that's your assumption, but I'm sure we'll fix this, please, go to our forum, becasue there might be a few things that can be tried. I think there's some misunderstanding here: VistaMare IS the Aerosoft solution! We don't use that module ourselves. Try to enter now.
  9. Hello, We have an update available for Zurich, to be found on our forum: http://www.fsdreamteam.com/forum/index.php...g15218#msg15218 Also, starting from today, those downloading the full installer, do not need that upgrade.
  10. I'm sorry, but something must be wrong with your system, because I don't have other solutions to offer. Your forum account HAS been activated, so it's best if you post there.
  11. No, it's not. I have already explained the solution in the previous post, which is to ALLOW the module to run and try again, and eventually reboot Windows and try again. Just in case something went wrong and some files were not updated, try to manually delete bglmanx*.* files, reinstall the scenery, and try again. There are no other solutions, it will always work in the end, because it's an FSX problem, not an FSDT problem, not an Aerosoft problem, I keep getting it randomly whenever a new module gets installed and trusted, from any module, the wilco.dll, leveld.dll, etc. It always fixes itself when launching it the 2nd time, and sometimes requires Windows to be rebooted.
  12. Hello, I might be able to help here, because we had to deal with this issue a lot of times: It seems FSX sometimes just gets confused when a newly installed module has just been trusted. So, regardless of what module is, it presents the user with the red alert that suggests not to execute that specific module. The solution is usually to do exactly the opposite as is suggested: ALLOW the module to run, and don't even worry if it crashes the first time. Re-launch FSX again, and it will usually work at the 2nd try. If it doesn't, a Windows reboot usually fixes the problem.
  13. I strongly suggest NOT to do that, because just deleting that file it's not the correct way to disable ParkMe on an airport, because that file is referenced in another place and if it's not found, it will generate an error (which is not visible, but it happened) that will stall the whole Python engine, which is needed by the scenery to work, not just for the ParkMe feature, but for the scenery itself to be displayed, since many objects are called by Python, and they will disappear or they will *fail* to disappear (when they should), resulting either in missing objects (if objects are not called), or slowdowns, if objects are not destroyed. It's easy to verify this because, when the ParkMe *.PYE file is removed, ALL the other features, like YouControl or even whole plugins like XPOI will stop working, because the abrupt file removal stalls the whole script engine. So, for the time being, it's not possible to remove that file without consequences. We might considering adding a safety check, allowing for ParkMe areas to be removed, but that would be just a temporary fix. The proper way to do it, would be having a way for users to set and save their preferences about those features, but IT HAS to be done in both ways. Meaning, you should provide the same feature in AES, letting users to selectively enable/disable features, possibly for specific airports. Like, for example, being able to specify that at, let's say, JFK, ground vehicles will be provided by AES and safegates by ParkMe, and at KLAS, the opposite, if the user has reason to like it more this way. I strongly suggest you to consider it because, it's either this, or it will be complete chaos, when we'll update ParkMe with additional features, which will happen relatively soon.
  14. Your Addon Manager is not the current version. The current version is, please download the stand-alone Addon Manager from our web site (FSDT). If this still doesn't work, it might be your Simconnect is broken. The fact you see other modules working, doesn't mean much, because those modules might be programmed to use the older Simconnect, while the Addon Manager requires the SP2/Acceleration so, if your SP2/Acceleration Simconnect is broken, the Addon Manager might not work, but other modules might. Try first with the current Addon Manager version and, if it doesn't work, I'll tell you how to diagnose Simconnect problems.
  15. You guys are making a lot of assumptions (let alone the funny remark about Aerosoft being a "competitor" of mine with regard to the F-18 vs F-16), without even starting to ASK... There's no "secret" about the radar showing online multiplayer planes on the F-18. In fact, there's nothing specifically programmed to get online airplanes, the radar doesn't know squat if a target is online or not, it's simply comes as an AI. The method is VERY simple: just use Simconnect, instead of ITrafficInfo from XML, and that's it... Of course, to use Simconnect, you need to use C++, which is just another reason (I can add many others too) why I always pretended XML doesn't exist, which is also a reason for THESE figures: http://farm4.static.flickr.com/3395/325182...e46b7e173_o.jpg Umberto Colapicchioni http://www.fsdreamteam.com
  16. Hello, If you have updated the Addon Manager, either as a stand-alone install, or by installing any of the Trial version for FSDT sceneries, you need to be on FSX SP2 or FSX+Acceleration. The current version no longer works with FSX SP1.
  17. The copyright is probably the only thing that was copied...if you read the system specs and requirements, it would have been clear that they are specifically tailored for Geneva, just compare it with JFK, for example. Since AES support will come quickly after the scenery release, I don't see it as a problem having anticipated it in the specs, we never had AES support on release day anyway. I confirm AES support for Geneva will come very soon, we already given to Oliver everything that he needs to support it, just give him a break...
  18. Don't be. KLAX will require additional work for the developers to support AES, because as Oliver said, the jetways there are integrated in the terminal structure, so it has to be reworked to allow AES. That's exactly the same as in Bergen, it's just that, since KLAX is *much* larger than Bergen, it would have been impossible to do in this AES release and, we are also quite busy working at KORD... So we think it will come, but definitely after KORD release.
  19. The problem is that, the 1.04 updater file on Cloud9 server was incorrectly labeled as being 1.04, but it still contained files for the old version. The full 1.04 installer, instead, was fine but, if you ran it afterwards having run the "wrong" updater without uninstalling first, it wouldn't fix the files, since they were stamped with "1.04" time/dates even if the actual content wasn't... So, the solution to the "old scenery" message would have been to use the Full 1.04 installer, but uninstalling EHAM before doing that. There are no registration/activation issues doing this because, as long as you don't reformat Windows, it's possible to install and uninstall an unlimited number of times. Note that, since this afternoon about 3:00 PM (CET), even the Updater has been fixed by Cloud9 so now it's safe to use whichever installer, there's no difference, except downloading time.
  20. It's all right and true, except one small thing: it's FSDreamTeam
  21. If you have a look at the german forum, there's already a preview of another Cloud9 scenery that should make it into the next AES release.
  22. All right, this is good to hear, then I guess Cloud9 must still have something old in their installers as well (they maybe mixmatched the latest dll with the old dat files). I'll report it to them. All installers use file/date and version checking. An older installer should't overwrite newer ones. As an additional precaution, the latest FsDreamteam installer will now always update even Cloud9's product databases...
  23. That's no problem. If you haven't installed Zurich, it's normal you don't have this file. Just remove the bglmanx*.dat files you have, and reinstall. Do you, by chance, have FS Copilot ? There's a known issue with it, it apparently leaves Simconnect in a faulty state, blocking addons that are loaded after it. If you have it, try to change the loading order of modules in your DLL.XML file ( found under %APPDATA%MicrosoftFSX ), and move Fscopilot.dll entry, the whole section, included the <Launch> </Launch> tags, to be loaded as last.
  24. There shouldn't be any difference at all, with regard to Vista 64 support. They both work. Try doing the following: delete these files from FSX root: bglmanx.dat bglmanx_aerosoft.dat bglmanx_fsdreamteam.dat then reinstall our standalone Addon Manager It might be that, for some reason, the installer wasn't able to update these files.
  25. Have you tried the usual two Vista suggestions ? Turning off UAC Turning off DEP If still fails, have you tried the standalone Addon Manager installer we have on fsdreamteam site ? The program is exactly the same as Aerosoft's, but the installer does also an automatical cleanup of older esellerate files, that might fix the issue.
  • Create New...