virtuali

That's precisely the opposite how not only what my previous post was about, but it's not what ever happens. I never "blame users", when I say something is not caused by GSX, that doesn't mean I'm saying it's the user's "fault", I'm just saying it's not GSX, and I always provide evidence to backup my claims. By saying I'm "blaming users" you are expressing your opinion about what you think I mean. Since I surely know what I really mean, I'm calling you out saying that's not what I mean. And again, you can "discuss" as much as you want, but when there's a need to move from the discussing step, to the actual troubleshooting step, with possibly back and forth interaction of exchanging diagnostic logs that doesn't have much meaning for regular users, then no, a general forum instead of the developer's one is not the best place do that. That is if you want the best and most effective support possible.

You quoted my sentence, without really understanding it: The subject of the sentence was the troubleshoot action so, when I say "not really the place to do that", I'm referring to the troubleshooting only, you can discuss about this here as much as you like, but to get something solved, steps must be taken to understand what is really happening, and this is not the place to do that. I don't think the OP posted here just to put a possible issue out in the open. Instead, I think he IS genuinely interested in getting the problem fixed, so I gave him several useful information, including the fact his issue was already being discussed so, in that small sentence of mine which you quoted as your point of contention, there was everything he needed to know to find a solution in the fastest way possible.

You should have reported this in the proper places: - the FSDT support forum OR - the GSX Community channel on Discord ( I suggest this, for a faster reply ) Those are being discussed already, and there are ways to troubleshoot those, and this is not really the place to do that.

Then you should do as I asked, and report this in the FSDT forum, or the GSX Community channel on Discord, so we can troubleshoot it with diagnostic logs.

If you bought it from the Marketplace, it can't be supported. If you bought it from PMDG, that's not normal and you should report this to support.

Most likely cause is the antivirus. Configure it to add the whole Addon Manager folder to the antivirus Exclusions, and run another update CHECK in the installer.

Then you now are sure it's nothing related to GSX. Yes, this happens, the default jetway animation system in MSFS is quite limited, jetway treat all airplane doors equally, so they'll dock to the first one solving, if you place the airplane forward enough, they'll dock on the rear door, and sometimes they even dock on the service door with the head reversed. Or, they don't dock at all, or dock from the wrong parking. Again, nothing to do with GSX, which just sends a single Trigger command to operate the jetway, the rest is done entirely by the sim.

Assuming you are referring to the GSX replacement jetways on default airports, which are the only airports you are supposed to used GSX replacement jetways (with "default" meaning really default, NOT Handcrafted/Premium airports: these *cannot* use GSX replacement jetways), a possible reason why you'll find the default jetways to "work better", is because they have been modeled using unrealistic too forgiving constraints, the jetway head is allowed to bank, something a real jetway head will never do. Also, they use 5 coaxial sections, when in real life they usually have 2-3 sections with different sizes. The GSX replacement jetways, even if they have the same measurements and are placed in the same position as they ones from the default scenery, have more realistic constraints and are modeled over more real life jetways, which means they look more accurate, but they might have more issue connecting, because they respect realistic constraints, they never bank for example. You might be able to improve this by setting a Custom Stop position in GSX, which is what custom Airport profiles do, but the main problem is, not many do and share profiles for default airports, because they have so many other issues, that most creators don't find worthwhile to make profiles for default airports. And of course, you are not forced to use GSX replacement jetways, since you can disable them, either individually by airport, or entirely.

How typical, reminds me about all the drama about engines sounds on the LH Maddog, and recalling talking about that with a friend who used to be Captain for Meridiana, sometimes flying it 4 times per day, saying "you had to check at the engine instruments to know if engines are running, there's no way you could hear them from the cockpit"

BA2157 from Antigua to St. Kitts, 25 minutes.

Not exactly. GSX position is based on the Preferred Exit, which it's usually L1, especially considering we didn't had much of long haulers before, but the chapter in the manual named Understanding the Stop Position, at Page 48, and especially the diagram in the following page, explains quit clearly how this works. However, if the issue is the airplane is too far ahead, so it would end up inside a building, seems to indicate Stop positions hasn't been set, because for all of that to work properly, a custom Stop position must have been set for each gate, using any airplane (doesn't matter which one), since what GSX will do, is to position the airplane so the Preferred Exit of the airplane *you* are using, would end up in the same place as the Preferred Exit of the airplane used to customize the Stop position. That's even without considering a GSX airport profile can even use custom Stop positions for different airplane models, in case the above strategy of "aligning the Preferred Exits" doesn't work in some particular spots.

Assuming the monitor can support more than 60 hz refresh and it's configured to do so.

Yes, it's a confirmed bug of recalling a Cold & Dark save state in the Fenix. While the airplane own systems are off, there's a mismatch between the internal engine simulation, and the standard A: variables which represents the engines in the sim, (the only thing GSX can read), reports one engine running. We reported it to Fenix and they promised a fix. I guess they are fairly busy doing new things, that's why a few minor issues like this (another is the airplane resetting the GSX passengers number to 0 on restarting GSX, for which we had to do a workaround) hasn't been solved yet.

The most common cause for this, is closing the GSX Toolbar Menu with the mouse, instead of following the suggested workflow in the manual: The manual explains why is this in detail, no use repeating it here but, the worse side effect of having closed the GSX menu from the Toolbar in the middle of using it, is that GSX won't be able to display a pop-up menu, with the most important one being the one asking for a direction during Pushback. Because Pushback is important, we added a specific handling for this case, which is the "Continue Pushback" option that will appear if you re-open the menu from the Toolbar again.

work with no problem, for the few users affected ot might be a network replication issue, which is fixed using the offline installer