virtuali

In any case, your error has already been fixed in the latest update (2.4.1)

Please don't post here about errors, this is not the FSDT support forum, and this thread in particular is an announcement that is supposed to explain the update benefits. We are of course trying to understand it ( I cannot reproduce it ), but you can find more informations and follow up discussion in the appropriate thread about this in the FSDT support forum.

No airport profile could possibly have fixed the lack of information about the jetway status. Have you seen the video which explains all the details ? Of course airport profile will still be useful, but not to make jetway work better, but to improve vehicle positioning, fix possible clashes between vehicles and static object in the scenery, to create custom pushback routes, to create custom remote deicing areas, to create walking paths for passenger, and so on.

Today Microsoft released Sim Update 12, which has added lots of important improvements to the sim covering many areas. But for FSDT and GSX Pro, the most important feature is the addition of full Jetway informations to the Navdata API, which will offer big benefits to how GSX works. The changes are many and their impact so profound, we had to make a presentation video to explain in the detail how much this improves GSX: We would like to thank Microsoft and Asobo for listening to all our suggestions about this new API, which has been added exactly like we asked, and makes GSX working with jetways so much better. Changelog: GSX MAJOR UPDATE: Support for the Sim Update 12 Navdata API, which allows proper Jetway recognition and handling in a more streamlined way, to solve all issues previously caused by the inability to detect jetways reliably, like invisible Passengers, Passengers walking on air, or Jetways retracting unpredictably. GSX Pro NEW: Overall performance improvements due to using the new Simconnect feature added in SU12, to access L: Variables directly, bypassing the WASM module for all these. Reduced latency in the menu and in all cases were using L: variables are involved GSX Pro NEW: Menu more responsive, in party due to Simbrief data read asynchronously. The menu will open without waiting for Simbrief to reply, and the Simbrief button will automatically refresh on opening, after receiving the flightplan data. GSX Pro CHANGE: Usage of the SU12 Navdata is Enabled by default and it’s always active, since there aren’t any side-effects that could require going back to the legacy “Airport Cache” method, due to all the improvements in the SU12 SDK. GSX Pro Fix: Solved a case when the GSX menu would be stuck on Loading. GSX Pro Fix: Solved a case where the menu would automatically hide.

But sometimes it IS funny ( and scary, at the same time ) Yes, it even added the emoticon. This is ChatGPT 4.0, BTW, which has improved quite a bit, in just a few months.

Changed ? In the two years since that post, were we correctly estimated MSFS would have took over the whole flight sim market, two main things have happened: - MSFS really took over the market, and by an huge margin, exactly as predicted. P3D is not even the 2nd, that would be X-Plane, and we don't have time/resources to support that either. High end aircraft like Fenix, PMDG, Leonardo ( but even the free FBW A320 and the A310 included with MSFS can be considered high-end) came out so, compared to 2020, the MSFS position has only improved. All users are there, basically. - For us, GSX Pro for MSFS came out, and supporting this it with new features and updates is taking all our available time, up to the point we hardly have any time left to work at airports for MSFS, let alone any other sim. We have KIAH for MSFS basically completed, but we couldn't find time to release it, because to do the finishing touches, we need to find spare time during the MSFS betas, were it might not be safe to release too many GSX updates. In addition to that, we tried some experiments trying to port back some objects from MSFS to P3D, and going in that direction it's not as easy at it seems, it's a lot of work and it's just not worth the time/effort, considering how shrunken the user base has been. A GSX Pro update with some new features, that takes very little time to do, if properly presented ( sometimes it takes more effort creating a promotional video than doing the actual feature ), is taking in more sales than a whole new airport scenery for P3D. That's how the market is today. I'm sorry but, unless a future P3D version would came out, offering dramatically improved features, a whole new graphic engine, I can't see any chance to release new airports or new products in general. Yes, LM working with Unreal engine is interesting, but I don't think we'll see anything really new before some years. Just be happy that, the way GSX works, with almost all its code running externally and not much affected by the underlying simulator, almost every new feature related to its code logic or sounds or new operators we add to the MSFS version, will automatically go back to P3D, that's the only level of support we can think of for the foreseeable future. So, to answer your original question, plans might have changed, but not in the direction you were hoping for, meaning if in October 2020, we still had some minor hope to be able to do something for P3D ( possibly converting back from MSFS ), in March 2023 that's no longer an option. Obviously, plan can always change again due to changing outside conditions. If LM were to announce something like a brand new version, using the Unreal engine and the vast array of its capabilities and plug-ins, and perhaps a worldwide scenery based on, let's say, Google Earth, that would be something worth changing plans for.

Neural networks has been researched and used in the academic world for a long while, the only difference in recent years was the continuous improvements of hardware optimized for AI calculation and, of course, enough big companies willing to invest in this field, which in turn drives even more money into development of even better hardware.

GSX Manual, Page 73, the explanation of the "SimBrief Ignore Time" option:

Username is clearly username, not Pilot ID. With the old Simbrief site, it was a bit confusing because, there was a page where it was called Username, and another page where it was called Alias but now, with the new Simbrief site, it's listed as "Alias (Username)" so, there's shouldn't be any doubt about what GSX needs, which is not the Pilot ID.

More or less. KIAH for MSFS is a port from the P3D version (which was originally made by Alessandro, who's the main GSX 3d modeler), but in a similar way to our KCLT scenery: a whole new terminal has been modeled from scratch for MSFS, and all the ground and taxiways that were affected by this change has been updated. This work has been made by Massimiliano Addante, who's the author of KCLT, KSDF, LFSB and LFNC, and it's done, there's nothing left to model: we only need to test the scenery for issues, and package it as a releasable product, and this requires some work and, of course, it might be possible that when checking everything, we might realize extra work might be required, so it's difficult right now when it will be released, but I guess in the next months, before the summer.

Sure: I was looking at the same image, and got mixed up the hues. It's fixed now.

That's not what happened. What really happened, was you tried to suggest that GSX should have ignored the airplane type, which was ONLY because PMDG set it wrong in ONE of the 3 variants: the 737-800 which had an icao type of "737", which is in fact the code for the -700, and since this happened almost at the same time the -800 came out, you tried to convince us and other users that GSX should ignore the airplane type. THIS is the suggestion you were rightly attacked for by everybody else, and the obvious reason for its rebuttal was something that has been made very clear to you, over and over, which was that, by ignoring the airplane type, GSX might have loaded a flight plan made for, let's say, a 747, and started Boarding 400 passengers on 737, and this would obviously look like a "GSX bug" Ignoring the time won't have any real bad effect on the simulation itself ( like using 5 Bus or taking an hour to board on a 737 ), except the VGDS saying you are 10 hours or so late, but that's a minor issue.

Way more than a month: support for the SU10 Navdata API has been added to GSX since last October. However, we expect even better results with the SU12 SDK, which will update the Navdata API and should finally give us all data we about jetways, including some we never had before, not even when we *could* read the airport .BGL, and that should once and for all solve all the remaining issues with jetways that are only caused by lack of enough data about them.

Is still just visual, except that GSX turns on all default deicing systems in the airplane for you, but that's the only thing it does and it was the same in FSX/P3D too, since the variables related to icing has always been read-only there as well. However, should the ability to write those variables will ever become available, adding them to GSX will be really easy.

It might be AIG traffic injection creating too many objects, surpassing some kind of limit on the number of objects that caused the airport to eventually disappear: https://forums.flightsimulator.com/t/arrival-airports-traffic-and-fps-have-disappeared

KIAH came out in June 2014, that is 3 full years before P3D V4 came out and the year before P3D V3, so it was designed in the P3D 32-bit OOMs era, and it followed another scenery we made that had features never seen before ( dynamic shadows in FSX and P3D 2.x ) CYVR, which nowadays is seen as a simply good and easy on fps airport with no issues whatsoever, but when it came out, in the P3D 32 bit OOM era, when everybody already filled up RAM with PacNW and Vancouver+, CYVR being just being released, it was accused of "causing OOMs", when of course, as usual, the cause was simply the fact that, on 32 bit sims, you simply couldn't add, and add, and add stuff without reaching the breaking point. Today, everybody knows that and we are all grateful the 32 bit era is behind us, and even other big airports released after CYVR were released after it and they were *all* risking OOMs, people started to be aware of the 32 bit limitations, so in time, especially after P3D V4 came out, nobody ever accused CYVR to be the cause of OOMs. However, since P3D V4 only came years later, we couldn't obviously stop making sceneries to wait for a 64 bit sim so, since we always take user reactions very seriously, for the NEXT scenery, which was incidentally an airport even bigger than CYVR, that is KIAH, we decided to just forget about the "never seen before" features, and work on 3 things: optimization, optimization and optimization, trying to say every last bit of memory we could, in order not be sure nobody would ever experienced an OOMs. This PAID OFF in support: KIAH is BY FAR, the product which required less support, and not by a small margin, even if it might have not looked as good as it could have been, but we really didn't want to risk another OOMs urban legend. As I've said, KIAH came out in 2014, 3 full years before P3D4, 1 year before P3D3, which was still 32 bit, and even worse than P3D 2 from a memory point of view, since it has lots of new graphic features ( dynamic shadows, duh...), but with the same 32 bit limitations so, we really couldn't design KIAH anything different from 2013-2014, if we wanted a reliable product. And it *was* reliable. And it even outsold the better-looking CYVR so, we assumed users valued reliability, surely at that point in time, when it was a miracle if you managed to complete a flight without OOM-ing. However, I don't think it's fair to say KIAH looked "older" than KDFW or KJFK, I think KIAH overall was better looking, but KDFW and especially KJFK are probably more interesting as airports in general, with better chances to appear to look good, even if they really aren't and they are way older than KIAH ( KJFK came out 2009 and was last updated in 2013, KDFW came out in 2010 ). And yes, we have been really busy with GSX's release, because I hope everybody will understand that, it's more important to work on all possible issue of an already released product people pay money for, than switching on the next thing. At least this is what seems to be the general consensus, usually when people complains about a developer, they complain about moving the next product before fixing the issues with the previous one. And GSX is of course very different than a scenery: it needs constant support and evolution, while an airport can stay the same, as long its real world counterpart doesn't change much. So KIAH had to be put in pause when it was almost completed, but we'll surely get back to it and, in fact, since we are planning to attend the next FsExpo in Houston, it would be nice to have the scenery ready in time for that. Sure it was but, if it wasn't for the MSFS version, we would have lost money on it, because the time it took to create those features, might have been spent to make a cople of new extra sceneries instead. And, when P3D V5 came out, which a DX12-only implementation that had lots of teething issues for a good whole year until it became stable, lots of that work got lost because the features we needed most ( True type Font rendering ), has been removed from DX12, or required an extremely complex hybrid rendering of DX11+DX12 which I don't even know is possible running under an host simulator, and even if it was, it was so complex that it would have been a nightmare supporting users if anything went wrong ( DXGI-crash-wrong... ). If Microsoft, which is supposed to be the strongest advocate of DX12, still hasn't removed DX11 support from MSFS, it tells something... While we are fairly sure MSFS will never allow DirectX access, we might only hope that in the future, some kind of safer and easier to use Render-to-texture feature will eventually be offered in the SDK for something that is not an airplane gauge. We of course asked for it even before MSFS came out, but when lobbying for new features is concerned, it's always best to ask for the easiest things first, the ones that have the better chance to be added, in our case the Navdata API which came out in SU10 and the addition of Jetway data that will came out in SU12, and move on to the more exotic and complex requests later...

If your antivirus ( following your report that MSFS said "an application prevented to load Couatl" ) is messing up with the startup of the programs, IT CAN crash the sim ( the antivirus can, Couatl cannot ), so you can be easily mislead GSX caused the crash, just because you don't have the crash without it. Don't you think if GSX *really* caused a crash, we would have know it by now, and we would have both our forum and everywhere else flooded by similar complains, same as when GSX came out, when because of an issue on MSFS servers happened exactly when GSX came out, we DID had the forum and everywhere else flooded by CTD reports, which obviously turned out not to be related to GSX in any way ? That is just to say, if this really happened to lots of people, we would have heard it by now.

From today's update:

What that error log is saying that Couatl has crashed BECAUSE the sim crashed, which is normal since, if the sim crashed for other reasons, it would break the Simconnect connection abruptly, which will like MADE Couatl crash as well. Nowhere that log indicates Couatl was the cause of the crash. In fact, it was likely the victim.

It's not possible that Couatl could prevent the sim from loading, since it's an external .EXE and, by definition, and external .EXE cannot prevent the simulator from loading. Not a normal .EXE like that, which runs as a user-level program and surely doesn't do anything weird, like attaching itself to the simulator like a Debugger, which would be the only way in which it could possibly affect its process or its memory space. The simulator is possibly trying to start Couatl by itself ( normal, since it is added to the EXE.XML ), so maybe it's reporting the real cause of the problem: that "application" might be the antivirus that has blocked it and, opposite to Couatl, which is an user-level program that has no access whatsoever to the simulator process and memory, antivirus use lower-level services that DO have the ability to block other apps and potentially make them fail. Configure the antivirus to add the whole Addon Manager folder to the antivirus Exclusions and, while you are at it, configure it to exclude the whole MSFS folder and Community/Official folder. In addition to not being mislead again GSX "crashed your sim", which it can't, your simulator will start faster and will run better.

The installer is way more reliable than any typical installer/updater. A typical installer/updater that will just check some kind of "version number" without verifying each and every file of the installation, cannot guaranteed you really have the latest version of all files, cannot guaranteed none of the files are missing, cannot guarantee none of them has been altered/corrupted, and cannot guarantee a download failed or some files weren't the right version, because what a typical installer/updater does to tell you a version, is checking only a few files ( like the main .exe or the manifest.json ) and assume nothing could possibly go wrong, either while downloading or after, if any of the affected files is not one of the few files that are checked for the version. While this might even (kind of) work for some products, where most of the crucial code in in a single .exe, or in a gauge file that is always updated when a new update comes, for a product like GSX, which is made by over 30.000 files and each of them is equally important and might cause issues if missing/corrupted/outdated, such kind of simple version checking doesn't work, so our installer/updated always makes a complete integrity check of each and every file while the update is performed, which means is able to restore the installation integrity, no matter what. And not just that: instead of assuming that, just because a file has just been downloaded right now, it "must" be the correct/latest version, it will check what's being downloaded, and will try to download it again the next time, protecting you even from issues of failed downloads or outdated files due to internet caching. If it didn't that, you wouldn't have even the slightest suspect something was wrong. Instead, by noticing that some files are being downloaded over and over ( other than the ones that are supposed to, for performance reasons ), you are made aware even of this issues, which are covered by the alternative Offline installer. I understand this higher than normal fault tolerance might be confusing, such as the lack of a "version number" which, if you understood all the above, cannot really be guaranteed, unless every file is checked, which is exactly what the program is doing right now so, apart for the issues of outdated downloads due to caching (which you can know if you are affected by, in the way explained above), in fact is way simpler because, the way the updater works, it will guarantee you will have the latest version after you run it. The latest version of everything, not just the latest version of the few sampled files that are checked for versioning. Again, I understand this is "different", but different means more reliable here, not more "confusing". Having said that, since this is very hard to explain and users prefer familiarity with established methods, we will update the installer/updater to SHOW A VERSION NUMBER soon. Of course, it won't make the program any more reliable than already is, it won't change anything the way it works, it will just look like other updaters.

It would have been best if: - You posted this on the FSDT forum before uninstalling it. - Even if you failed to uninstall it, if would have been best to post on the FSDT forum exactly what happened during the uninstall, while the post you made there just said "Not even that works for me", which is not very helpful for troubleshooting. Of course the uninstall works, why it hasn't worked for you it's something that must be properly verified, possibly related to the same issue which prevented the update to work to begin with. But again, please open a proper post, with a proper title and a proper precise report on our forum, which is the correct place to be supported. I checked all your post in our forum, and other than a couple of questions, nothing you wrote ever suggested you ever had a problem with the updater or the installer, but you stopped posting after Sept. 4th, and just came back here to report an issue we couldn't possibly be aware of. Please don't reply here about this issue, but continue on our forum with a report, so you can be followed there in the most appropriate way.

GSX for MSFS is clearly better than the P3D version, considering they share most of their code, which runs externally from the sim so, it’s just not possible anybody could say the P3D version was “better”, when it’s basically the same code, but with better models, textures and animations and extra features too. The only remaining issues are mostly due to limitations with the default jetway system and the limited data we have about them (even more limited if we use the Navdata api), which cause all sort of issues with passengers, but these should be gone with SU12, as I explained in another post.

not only GSX allows to very easily customize the kind of loaders (and container types) for each airplane, but it’s even possible to have individual customization files BY AIRFRAME, to simulate different options depending on airline choices.

I'll copy here a post I made on GSX creators Discord server, which might clarify any current issues with Jetways, especially when using the SU10 Navdata API: Any time you see issues of passengers with the SU10 Navdata Enabled, it's normal, and it's due to limitations in the API ( which is why, we don't enable it by default, because it's still incomplete ). The problem is, the API only tells if a parking has a jetway, nothing else. We don't have any information about its position, so when Navdata is Enabled, GSX must first search all objects in the scene trying to guess which ones might be jetways, based on their names. Then, it tries to figure it out the one is associated with the parking spot you are in, searching for the closest one on the left quadrant of the parking radius ( + some overlap because some jetways are placed right of the parking center ). If there are parking spots with DOUBLE jetways, a "proper" animated jetway and another one a static that has been represented by the same Simobject, there's no way for GSX to know for sure the right one; they are both Simobjects, with the same name and the static one might be the closest to your plane. None of this happens when we read the .BGL. In that case, we know all jetway positions from the .BGL, so it's very easy to identify a jetway, by matching the coordinates in the .BGL with the coordinates of the objects found in the scene, and GSX can't be confused by double jetways or jetways placed in weird ways, outside the allowed overlap for the left/right quadrants of the parking radius, and there aren't any issue with the names. . ALL of this should be fixed with the SU12 SDK, which will add lots of new information about jetways through Simconnect: we'll get the position, the parking spot associated to it, the jetway current status (docked/undocked/moving), which airplane is docked to and, most importantly, the actual position of the Jetway controlling Bones ( Primary and Secondary Handles ), which can be used to know where the jetway has docked, exactly, and this will fix even the issue of jetways not pivoting on their center. SU12 will come out in March, but we expect the Beta starting sometime in January, which should give us enough time to add it to GSX in time for the general release, and if everything works as expected, GSX should then work with Jetways as reliably as it was in P3D, so people might hopefully stop assuming "passengers are bugged", which is ENTIRELY caused by lack of data about Jetways in the SDK, coupled with the bugs the Jetway system has on its own, like Jetways docking in absurd positions ( for example, reversed on the catering door ). With the info about the position of the bones, we'll be able to detect exactly how the jetway ended up after the animation ( impossible today), so it would be trivial to always have passengers walking the correct path. Even the supposed disconnection, is likely related to all the above issues about detecting the correct jetway, which is less reliable using the SU10 Navdata, until will be completed as explained, in SU12.