virtuali

Yes, we are busy adding features requested by users, which obviously includes fixing all bugs properly reported (which can be easily proven by our release notes history), and ranting with unfounded claims, is not my idea of proper bug reporting. Do you think there are still unfixed bugs ? Then go to our forum, open a thread with some reproduction steps and then we can: - check if the supposed bug is really a bug, or a design choice, or something that happens because of a wrong setting or something else and why it happens and how. - verify this is a bug that must in fact be fixed, if it might been already fixed in our upcoming update or, if it hasn't, if we could manage to add it to the upcoming update list of fixes. THIS is what I call productive feedback. Saying "last few versions have just been an utter mess", without anything to back it up, is entirely useless. And no, please don't reply here, since this is not the FSDT support forum. Since I couldn't find anybody registered as "Mitch24" on our forum (maybe you used a different nickname ?), I invite you to register and post your feedback. That would go to great lengths showing you are in fact interested in providing useful criticism which would actually lead to yet another improvement, one of the many hundreds that already make their way in our products, always following users's feedback. About O'Hare, it's progressing well, the scenery it's clearly huge and we don't want to compromise on it, since the original O'Hare sold well for 9 years, which means the new one must be the final word on that airport. Which already sounds like a joke, since the airport is going to be updated *again* a couple of years after we'll release it but, we are trying to make it as easy as possible to keep it updated in the future.

All your GSX "issues", are not issues at all. You think they are, because there's a wrong basic premise here: You think that anything in GSX would control how Jetways operate in some way. This is clearly explained in the manual, inside a blue box, hoping nobody will miss it, but still... NOTHING in GSX controls or change the way jetways operates. With "Jetways" here, I'm referring to the ones using the standard animation system, which are operated with CTRL+J. You can edit the airplane all you want in GSX, and this won't have the slightest effect on such jetways! Note that, even if we might refer to them as "default", that only means "using the default jetway animation system". Even a custom jetway on a 3rd party airport, as long as it operated with CTRL+J, is still a default jetway, and it conform to the same rules. The ONLY thing that controls how or where a default jetway will attach to, is the [Exits] section of the AIRPLANE.CFG file and, since the default system allows only for a single jetway, the airplane developer must choose whether he'll set it to the 1st or the 2nd passenger door. Once that choice is made, there's nothing you can do to change it, unless you edit the aircraft.cfg file. Everything you change in the GSX configuration will only be used by GSX and, since GSX doesn't control default Jetways, you can change doors in GSX as long as you like, and it won't make the slightest difference to a CTRL+J jetway. If the scenery uses SODE Jetways, instead, this is entirely different. The GSX airplane configuration WILL matter now and, since GSX and SODE are connected, IF you operate a SODE Jetway from the GSX menu (opposite to the SODE menu), GSX WILL pass its own door configuration to SODE, which will know how to dock jetways, and will allow you to use doors other than the one defined as the main passenger door in the aircraft.cfg. You will know if a scenery comes with SODE jetways, because they are labeled as "/JS" in the GSX parking selection menu. If there's only a "/J", it's a DEFAULT Jetway. The stopping position is the same. Since it's a GSX data, it only matters TO GSX. If you position the airplane using the standard "Go To Airport" menu, the simulator wouldn't know anything about the GSX stop position, and will continue to set the airplane with its center of mass in the center of the parking. The customized GSX parking stop position will matter only to determine the correct stopping position in GSX (the Marshaller will read that) AND if you use the "Warp Me There" function in GSX to move to a parking, instead of the standard "Go To Airport" menu. And please, have a look at the GSX manual, the chapter named "Understanding the Stop position", which explains how it's supposed to work, and its relationship with the "Preferred Exit" in the GSX airplane configuration.

The P3D4 SDK (and lots of it was already improved in previous versions) is SO MUCH better and powerful than the FSX ever been so, LM has made a very good job improving it. The issue is, until today, the most we saw from 3DP developers was: - Just recompile some scenery with the P3D4 SDK, to get rid of obvious rendering problems when using the ancient FS8 ground polygons, which was basically mandatory in order to keep selling airports in P3D4. - Support the new installation methods, but only because users finally realized how much better is for them, especially when updating the sim. And still not every developer is using it. We can only hope (and you can be sure we'll do our best to lobby in favor of this), that LM would entirely block the legacy installations method in future versions. But all of these are both very easy to do and, other than fixing bugs and offering more convenience to users, are not really offering anything NEW to the simulation experience. But there's a whole lot more in the SDK, which almost nobody has ever tried to exploit it so far: The very powerful PDK, with is a lower level version of Simconnect, so it's more efficient (no client-server model, no communication pipes which can be clobbered by too many apps running together), and it allows things not possible before without relying on very dangerous hacks, like the new Render To Texture features, a whole new Camera API (no hacks to control the camera), an improved weather API, the ability to *draw* things like objects, lines, lights, in the 3d scenery, using fast C++ code. There's a whole new API called the ISimobject SDK, which allows creation of new "native" object types, with custom behaviors, custom variables, custom events, etc. It's even possible to entirely rewrite the flight model, from the ground up, without resorting to strange hacks. Human animations are far more powerful and could use more detailed skeleton models (going up from 22 to 64 bones per character), which are more compatible with industry-standard animation packages, motion capture systems, etc. So, why we haven't see much of these new features, if they are so good ? My theories are: 1) Developers are still not entirely confident to move away from FSX or other 32 bit sims, and create a REAL 64-only product, not just something "larger" that won't OOM, but something *different*, that couldn't even be made for FSX, even if it FSX could hypothetically be ported to 64 and not having any memory problems. User CAN do something to change this situation though, and make quite clear with their preferred developers, they won't buy anything which is not 100% P3D4-compliant, and won't buy an FSX product if it's released first, with only a "promise" to an eventual P3D4 update. 2) Most of these new features require C++, which is hard to learn and this probably cuts out most of the freeware developers, or the freeware-turned-commercial, which is a very common breed. 3) Even if a developer is fully proficient with C++, implementing these things still takes time. A lot. As an example, LM started to introduce Render to Texture feature since P3D2 and, of course, as soon it appeared, I jumped over it, and was probably the one giving the most feedback to them across all these years. By the time it was finally usable, P3D4 came out so, it took a least 4 years before someone did something with it. Our upcoming GSX Level 2 expansion and Chicago O'Hare V2 will start to use such features, but it wasn't easy to get to the level we are confident of their usage. The issue is, if there aren't enough developers using it, it's even difficult for LM to TEST it in the first place, and such testing is quite complex, because with the complete freedom to draw stuff in DirectX 11, also comes with the inherent difficulty of DX11 programming, which is even HARDER than plain C++. There IS a reason why, in the gaming industry, almost everybody use full game engines like Unreal or Unity: nobody wants to write DX11 code or write their own shaders, which what you are supposed to do when writing a PDK Render To Texture plugin. In the end, I'm confident the good stuff will arrive, given enough time, and the approach used so far by LM is the right one, which is consistent with a professionally-oriented simulator: constantly improve it, without trashing the old stuff all at the same time.

Exactly. Anybody with a cursory knowledge of how Windows works, should know that a separate .EXE on Windows has the following features: - It runs in its own entirely separate memory space, so it won't take any memory or other resources away from the sim or any other running app. They all have their own separate memory space so, as long there's enough total memory in the system to run them all at the same time without reverting to virtual memory "swapping", they will all work very fast, without slowing down each other. - It's an user-space program (not a service, or a driver), so it cannot access the simulator or any other running app memory space, not even theoretically, because Windows prevents two separate processes from sharing memory, unless *both* agree to do that, using special methods. Couatl doesn't even try to do that and, of course, it would require the sim to allow it. Could Couatl crash itself ? Of course it can, like any other application out there, but it surely won't bring the sim down with it, as a .DLL or a .GAU COULD. - Due to how Windows preemptive multitasking works, even if Couatl took a long time to do something, it couldn't possibly slow down the sim or the whole system because, starting from Windows NT, the OS can reclaim control of the CPU even if an application got stuck or didn't yeld control back to the OS. If Couatl ran under Windows 3.1, then yes, I guess it COULD slow down the sim or the whole system... - Thanks to how the multi threading scheduler works under Windows, if there's are any "spare" CPU cycles available on one core, the OS will assign the threads belonging to an application to *that* core. If the sim is taking 100% of the first core and 10% of the others, Windows will *never* try to assign Couatl to the 1st core. When Couatl starts, it does a lot of things, like checking the whole scenery database for changes, so it's quite busy until the usual "Airport cache loaded successfully" message appears, which means Couatl has loaded and GSX and all the other scripts are ready. This process can take a minute or so, but in that time, the simulator doesn't stop, and the fps is not any lower, for the precise reason it's an external .EXE so, it's running on a spare unused core and, with the newer CPUs, the number of unused cores is ever increasing, which means it would be best to have as many external .EXEs as possible running, instead of having too many in-process executable, like .DLL and .GAU files. Those CAN slow down the sim, and sometimes they do, for example when initializing the panel, with a visible effect on fps until the message goes away. This is called using a scientific method, instead of believing in ghosts. Bravo.

First you said KLAX was a poor performer, now you are changing your version and are saying it started after KLAX...but of course, everybody could see from my video, they aren't very different in fps. But again, everyone can confirm what I'm saying, because we have a TRIAL so, why you continue saying so, when everyone can see the things you are reporting are simply not true ? Why several users that posted here clearly understand why an airport performs in a certain why and why and where fps might be lost, and why it's wrong to compare a tiny single-airport with few parking spots on an island, with an huge hub with multiple runways, hundreds of parking spots, hundreds of animated jetways located in a dense metropolitan area, but you don't ? FSDT sceneries are optimized as **ll, and the Couatl engine SAVES resources from the sim, instead. Haven't even read my previous replies ? They USED to do this, on a 32 bit sim intentionally because, it's best having some stutter, caused by the dynamic creation and destruction of the objects, rather than having the sim CRASH because of an OOM! And it's not the Couatl engine which is "inefficient" doing this: it's the sim itself that, when destroys and creates an object programmatically, cannot do it in the background without stopping the sim for a brief pause. But this is what could SAVE a 32 bit sim from an OOM crash. Under 64 bit, all memory management parameters are entirely different, so we basically never create/destroy anything until you are well outside the scenery area, so there are NO STUTTERS and NO POPUPS, as can be clearly seen in my video, and of course everybody using our sceneries with P3D4 can easily testify how much different they run in 64 bit. About the supposed "take several minutes to load", that's obviously not true. First, they do not take that long. Maybe you think more to load than other airports, but that's just because most part of the scenery will start to load *after* the "Loading Scenery" progress bar, so it give the impression is taking longer to load, but it's not. If you take any other similarly large scenery, it will stay longer in the "Loading Scenery" progress bar, so you really cannot tell if it's the airport, the AIs or the terrain, and when the progress bar ends, there's nothing left to load. Let's say this part took 1 minute. On an FSDT airport, since 80% of the scenery is not loaded during the "Loading scenery" progress bar, but it's only created after it, you might think it takes longer to load, but the total time will be roughly the same, for example 40 seconds in the progress bar, and 20 seconds after it. In the end, you still have to wait 1 minute to use the scenery.

It works under Windows 7, just that you'll probably see the API.DLL error on exit, that doesn't happen under Windows 10. Which is mostly harmless, since it doesn't prevent the sim from closing correctly but, if that error worries users, disabling the RTT feature will prevent it to happen and, we are not using it yet, but we will for GSX Level 2 and KORD V2. When those two will be released, you'll have the following choices: 1) Re-enabling RTT, in order to get the new features (Gate numbers on Jetways in GSX and live information panels in KORD V2), and possibly getting the API.DLL error on exit, under Windows 7 only. As I've said, I won't be worried about the error so, if you are convinced keeping Windows 7, that would be the best option. 2) Keep the option disabled and not get such features, so you'll not see the error on exit with Windows 7 3) Upgrade to Windows 10, which will allow RTT to work with no errors on exit. Note that, this option is not a magic fix-it-all for each and every appearance of the API.DLL error!! It will only fix it when it was *caused* by the Addon Manager. But there might be a lot of other cases were the error will still be there, even with this option disabled and, in this case, it can only mean the API.DLL error was caused by something else. API.DLL is Simconnect and PDK so, basically, every add-on can potentially cause it, we can only fix the error that was related to us.

Due to the way GSX detects scenery changes, it cannot detect a file rename or removal, otherwise it would have to scan each and every file at each start, making it very slow but, instead, it only checks the folder last modification date, and this doesn't change after a rename/removed from a folder, which means, if a scenery file has been renamed/removed, you MUST select the "Restart and rebuild the airport cache" option from the Couatl menu after the renaming took place. This is quite common with sceneries that have an external configuration utility, which renames .BGL files. We are trying to detect such cases without slowing down the cache rebuild so, hopefully, in the next update it might not be required to explicitly rebuild the cache when using sceneries that switch between different AFCADs with an external utility.

Of course it does!

If you continue to post unfunded opinions, you can expect to be presented with proper explanations and support evidences, as I did with the two video showing both CYVR and KLAX happily performing very well. This, if all the other witness from several other users that posted in this very thread, saying they don't have the slightest issues with FSDT sceneries, which are entirely comparable to other similarly detailed airports from other developers, wasn't already more then enough. So, you can decide not to trust my explanations and proofs, because I'm obviously biased (and my video surely must be fake) but at least trust the experience of other fellow users.

There are several users that posted in this very thread that said otherwise. The scenery is the same so, clearly, it's just wrong making a blanket statement such as "this airport performs poorly", when there are many users that have the same scenery working very well. No. There CAN be airports poorly programmed and can cause a significant fps loss on their own, even without too many addons. I'm just saying the FSDT ones are NOT such case. Sorry, I don't agree. It sounds as if you are trying to say that some add-ons have the "right" to slow down the fps, while others can't and you expect they would always perform at the maximum, regardless of how much other stuff you installed, which is simply not realistic. No, you just bought a Ferrari, but are complaining it's not reaching its advertised speed when the highway is already full of cars.

That's not an FSDT problem, but more of a problem of the default instant replay not being compatible with objects created dynamically with Simconnect calls. Of course, back then when we were the only one using this method, some users assumed we were the weirdos doing things in strange ways "because of the Couatl engine", but that's just because we were the first using such techniques. But now, since so many developers finally realized that you NEED some kind of interactivity in the scenery to make it attractive and alive ( which means create objects dynamically ), they started using things like SODE and some even developed their own similar solutions, and the issue is way more common now and finally everybody should have realized by now it's a limitation of the simulator Instant replay feature because, of course, even a scenery that doesn't use Couatl but, for example, use SODE, will have all the SODE-created objects (Jetways, for example) disappearing from the Instant Replay, same as with Couatl because, of course, it was never a "Couatl problem" to begin with...

It's not. See the video I've posted above at KLAX. Before saying it's the airport that "performs poorly", always try to understand who's really slowing down your fps in a certain place. An easy way to test this, is disabling the AI and loading a default airplane. If you fps goes up significantly, then you'll know the airport wasn't the cause.

I'll correct this for you: FSDT is known for having extremely good performances, considering they always did very large airport located in areas where the default scenery was already very crowded, so users mistakenly assumed the performances were caused by the scenery, which wasn't obviously the case, and the real issue was that, in case of CYVR especially, it was unfairly accused of bad performance and OOMs, because when it came out, everybody tried to use it with memory-hungry airplanes + OrbX PNW + Vancouver+ and the 32 bit engine of the sim simply OOM-ed. If anything, CYVR raised the awareness that memory wasn't "infinite" on a 32 bit sim, and in 2013 there were just too many addons that could be used TOGETHER, which wasn't possible to have multiple background sceneries + a detailed addon airport + a memory-hungry airplane without risking OOMs. The Couatl engine is exactly what allowed FSDT to have usually better fps than other similarly detailed sceneries AND additional feature that nobody ever has. As explained so many times already, Couatl is an external .EXE so, it CANNOT "slow down the sim.". In fact, it's what especially under FSX, has saved the skin of many user, by doing a very aggressive memory optimization, saving from a crash that would have surely happened, with any other scenery that doesn't use it, and users started to assume that "Couatl cause stuttering". Of course it did, to prevent a crash! Destroying objects when they are not needed or out of view to reclaim memory and then creating them again *will* create a small pause in the sim, but the reclaimed memory might be enough to save the sim from an OOM, if the system was already close to exhaustion. Here's a video showing KLAX, with a comparison with a similarly large scenery (Aerosoft EDDF) later in the video, to show how KLAX is at least as fast as that one, if not faster. And another one I just made now, at CYVR, so much for the "sluggish performance"...

If your P3D is really clean as you say, and the list of used add-ons is accurate as posted, which seems to indicate you don't have GSX installed, this seems to indicate ( I already know about this but, at least, there's some evidence...), the API.DLL crash on Exit can also be caused by entirely different issues.

With regards to FSDT, we don't place *any* files related to the scenery in the Documents folder. ONLY the add-on.xml is there, with paths pointing to the actual scenery files location that can be anywhere. This is the best way to install a scenery the P3D4-way that still allows for auto-discovery (no need to reinstall the scenery after a complete reinstall of the sim), and also give users the freedom to install a scenery anywhere, even on a different drive. So no, there's no need to move anything, at least where FSDT is concerned.