virtuali

In almost 13 years, since it came out in 2013.

Are you using the Fenix ? If yes, disable the automatic jetway option in the EFB. A pushback that can be stopped from the MSFS ATC is NOT a GSX Pushback, so this issue is completely unrelated with GSX, that doesn't use or call anything from the standard Pushback system.

It was like this years ago!! And users begged to change it so the direction could always be decided at the very last moment, this way you could comply with an online controller giving you another direction after the tug was connected.

No, that's correct: Windows has *two* default audio devices: - the default "main" audio device, this is the one that it's used for normal windows audio. - the default "communication" audio device, this is the one used for microphone, headphones, etc. They might be or not the same, and changing the default windows main audio device won't automatically change the communication device, they are separate settings. By default, GSX assigns: 1) the Outside sounds to the default Windows MAIN audio device. 2) the Comms and UI sounds to the default Windows COMMS audio device. So, if you have configured speakers as the default main device in Windows, and headphones as the default comms device in Windows, you'll gear GSX vehicle/outside sounds through the speakers and the GSX spoken voices and other UI sounds through the headphones. But that's just the default assignment, which you can change, so you are not restricted to GSX having to use the same settings as in Windows, which might or might not be correct.

I understood you perfectly: I just used your post related to Vatsim as an "anchor" to explain what really happened with that in-famous issue that resulted in users pushing with GSX being seen with the airplane completely pitched up/down by other Vatsim users, which many assumed to be a GSX bug, when in fact was just a result of the combination of the sim not freezing the acceleration variables when the airplane is frozen, and the vPilot client relying on the acceleration data to predict the attitude of the local representation of other players.

"Bloated" ? Let's see: - Models ? Almost every GSX model is full optimized using up to the maximum number of 8-9 LOD levels allowed in the sim. Lots of well regarded airplanes out there don't even use *one* extra LOD: they are full loaded at the max detail no matter the distance. Most of the AI traffic packages out there (similar in modeling to GSX vehicles) use 3-4 LOD at most. This because adding extra LOD requires lots of extra work, and you must do it again every time you update the model, that's why they are not used as much as they should. But we don't mind the extra work, because performance is extremely important for us, even if 90% of the available memory is already taken by something else. - The thing that might affects fps more in GSX are Seated Passengers. That's precisely why they are not enabled by default, it's your choice to use them. Something like Pushback, for example, doesn't have any impact compared to the default Pushback. - Startup time ? Yes, GSX affect Startup time, exactly like any other large collection of AI models with many liveries and what affects startup time is the huge number of operators, almost 700, which multiplied for all vehicles results in ten of thousands of new objects added to the sim, which affect the startup time. However, you are not forced to install ALL 700 operators: there's an extra Livery Manager utility that comes with GSX that can be used to create customized sub-sets of operators for the areas you fly the most, and reducing operators has a big effect in reducing the startup time. - Code performance ? GSX runs completely outside the simulator, so its code cannot possibly slow down the sim in any way, because it runs as a separate process in a different thread so, any calculation in GSX regardless how heavy it is, cannot affect the sim own fps, this is enforced at the OS level, which will automatically assign GSX own separate threads to spare cores of the CPU. - Code safety ? Fact GSX runs completely outside the sim, makes it very safe compared to how it would have been if it was running in-process using WASM. And you don't have to take my word for it, making add-ons using external .exe is the suggested method in the MSFS 2024 SDK: https://docs.flightsimulator.com/msfs2024/html/6_Programming_APIs/SimConnect/SimConnect_SDK.htm As Microsoft/Asobo wrote: So no, GSX is not bloated, its modeling it's extremely optimized, its impact on fps is very low and can be easily controlled, its impact on startup time can be controlled, and it's coded using the best practices suggested in the latest MSFS 2024 SDK for both performance and safety. I can fully understand you might have a bad experience at start, because MSFS 2024 *itself* had lots of issues that affects GSX. At a certain point, it was found even the most basic Simconnect "Open" command (which every app must do to start connecting) was leaking memory at each call starting from a certain update of the SDK (this was discovered by the author of Air Manager), with SU4 a bug was introduced in the programmable Tooltips GSX use to write messages on screen resulting in truncated text (fixed in SU5 Beta), during the SU5 Beta, a couple of version had ALL wheels animations INOP (affecting GSX and things like FSLTL), but both the sim quite different compared to how it was a year ago, as @Noel witnessed so, while I understand you might have found issues, GSX itself today is also very different than it was a year ago.

about Vatsim, I would like to clarify the problem with GSX been fixed a long while ago by Ross Carlson, author of vPilot, with a vPilot update. The real cause of the problem was: - GSX must freeze the airplane when using a towbarless tug that raises the front gear. It wouldn't work otherwise. - When the airplane is frozen, the simulator doesn't freeze the airplane body velocity variables. One might say this could be a design flaw in the sim, since I don't see what's the point to keep updating the acceleration variables after the airplane is frozen, but that's how the sim works. - vPilot used a common network optimization method used by online games: instead of sending only the airplane positions, it uses the body acceleration variables to locally interpolate and predict the position for all connected planes, including pitch/bank/heading and since those variables didn't stop and kept their values, the last pitch acceleration caused by GSX raising the gear kept its previous value long after GSX stopped raising the gear, so vPilot was fooled thinking the airplane continued to being pitched up, but it wasn't, since it was now frozen. - After a long troubleshooting process and having tried a fix from GSX side, by constantly rewriting all the acceleration variables to 0 at each frame, which improved a bit but was still constantly fighting against MSFS that also wanted to rewrite the variables, we found the best solution was a fix from vPilot, which was easy enough: if the airplane is frozen, it would stop to use the acceleration variables to predict the plane attitude, and that fixed of planes pitched up on Vatsim when pushed back by GSX using a Towbarless tug.

That's a specific thing that happens only with the PMDG, which has a custom parking brake variable that is not set until *after* the airplane has completely loaded. The issue is, the airplane is *not* completely loaded when MSFS is read to fly (so that GSX could detect that), I think as a PMDG user, you surely have noticed the PMDG has a few seconds of pause *after* the sim is ready, and during this pause, it's initializing all its custom variables, including the parking brakes. That's why, during this period where the sim is ready but the airplane is not, GSX can't tell if the parking brake is on, because it's not On until all the custom variables complete their initialization, taking a variable amount of time, which is the "pause" were you can see the yoke turned and the sim almost stopping for a few seconds.

Another thing that both an aircraft handler or an airport handler can do, based on any conceivable logic, is to temporarily disable certain doors without requiring to update the aircraft profile.

Your request has been granted, exactly 2 hours after you posted it. Check version 3.8.4, out now: Well, in fact we were always aware this was a missing feature, it's just that we had so many other things to do, that is had to be put in the backburner, but now it's finally there.

It's as "aware" as far the SDK provides, with extra data added with an airplane profile.

Yes, this is correct, and the only reason why the aircraft doesn't disappear, it's because you are still not close enough OR the same AI got injected again, so you might not see much difference. Note that, opposite to FSX/P3D, is NOT possible in MSFS to "remove" AIs not created by you ( "you" meaning the app in question ). Or, to be more accurate, no app that doesn't don't any in-memory hacking is capable of removing objects created by simconnect clients other than itself. GSX being 100% SDK compliant and not doing anything potentially dangerous in memory (you can recognize these app when they require an updated *every* single MSFS update), is bound by this limitation. What GSX really does, is "just" *moving* the selected AIs out of the way, which is the only thing it can do, but the AI is still well alive and possibly under control of the creating app. If you are using an AI injector that updates the position of its own created AI at every frame, what is really happening is that GSX will move it away, and the injector will be then put it back in place where the injector assumed it should have been, so you are mislead assuming GSX AI removal "doesn't work", without understanding what is *really* happening.

That's because if you call it when you are not close to the gate, MSFS will automatically refill the same gate with another AI which would steal the gate for you. It wasn't always like this, it's a "feature" that has been added in MSFS in some update, that's why you might assume the GSX feature stopped working. It we tried to outsmart it and keep removing the new AI over and over, not only we would create unnecessary traffic on Simconnect, but by the time you arrive at the gate (but not close enough for MSFS to stop respawning new AIs), you would see AIs constantly being removed/recreated in a loop so we are not obviously doing that. The chance of this happening, of course, depends how many *other* spots are free, how dense is your traffic, you location when you asked for AI removal (affecting how long the taxi will last ) but the main issue is: MSFS will consider the gate "free" to use because it obviously cannot possibly know that you requested it in GSX. It would work only if you used the default ATC, got a gate assigned to you, and then select the same gate in GSX, so MSFS reserves it for you for the whole time.

Nothing PMDG does can possibly hamper how GSX will work with it. In fact, if they had a problematic automation, removing it would only make GSX work better, since the only automation at play would be GSX's one, considering all those weird things happening with doors opening/closing were caused by both automations at play. We even added documented variables that developers can use to *stop* our internal automation, on the assumption PMDG would have a wonderfully perfect automation themselves, so they might have wanted to shut down ours, but they decided to remove it instead. Or, at least, to tell users they removed it, since I can still see several GSX LVars inside their .WASM code for all 737 and 777, but of course I cannot possibly tell for sure it's they have been left there as dead code not running, or they are still doing something. If they remove the GSX profile, it's also better, since we would be sure that, barring any user customization, the profile used is our internal one, that works and well tested.

Give it time, but you'll see lots of incredible stuff being added. This is really next level compared to what was possible with a simple .INI profile or with the extremely limited .PY addition which were just naming decoration.

I'm not exactly sure what sounds you are referring to, exactly. It seems you are referring *just* to the pilot good engine start confirmation, that seems like a very little and nitpicky thing to put in 1st position, those are the only voices for which a variation exist (accents and variations within the same accent) and the reason why is not there, it's because we want to do it properly, since that's *your* pilot voice, so it shouldn't be simply a part of the regional voice system driven by the ICAO, but it should have some kind of global setting where you can set your own preferred voice and accent, unrelated to the airport you are flying it. The "Continue Pushback" is there precisely for those that keep close the menu with the toolbar, so they won't lose the pushback in the middle. If you are sure you didn't do that, it must happen for some kind of accident (maybe it restarted automatically), but it's NOT how GSX normally works. If you have the menu active and just hidden, the pushback direction WILL pop-up automatically. Well, unless you let the 30 seconds timeout expire: if you see didn't notice the pop-up, it would have disappeared after 30 seconds, requiring reopening the menu to "Continue". I can't believe I need to explain this. The message ("garish" or not, it's obviously subjective), it's NOT preventing GSX from working!!! It's just a text, you can ignore it or not, but your current session will continue *exactly* as before, just with the older version. No need to shut down MSFS, at all. And I'm sure you noticed the different level of quality, because most of its animations are "in place", so they are not combining manual animation + procedural movement, at least not while the guy is idling. Add-on don't have the same options available to the SubtleTaxiRibbon: we can only create Simobjects through Simconnect, with great attention to their number, in order to be sure we not only create too many of them, but also because of the extra latency due to having to individually set their position, heading *and* altitude over a possibly sloped terrain. So, less objects, which must be larger in order to be seen. The simulator internal functions, not accessible to us, don't have to call Simconnect, don't generate extra traffic on it, so they can do things we can't.

It's not that I don't "believe" anybody, is that before saying it insert the payload wrong, and being sure it's GSX that is doing that, one should provide so kind of proper report. In this case, just a log might not be enough because a log would only indicate if GSX read the data wrong from Simbrief or possibly sent the wrong data to the FMC. But it won't tell if the issue was instead caused by too much lag so the delay that normally works might not be enough in some situation, of you just had already characters on the scratchpad, which is not something we can really fix automatically, since there's no way with the PMDG SDK to automatically clear the scratchpad. To find if you fell into those TWO last issues, I would probably need a video, or at least a description of what you saw. That is, of course, assuming there isn't a problem in reading the data to begin with, like getting the wrong flightplan, getting the wrong values or sending the wrong values, which is the 1st part of my answer that could be diagnosed with a GSX log.

I'm not exactly sure what we could do more, considering how passengers must work. We already have each passengers animated separately, no two passengers have the same animation (already a huge effort) and that can't be said about any other similar system, both in the default (MSFS 2024) passengers system, but also in other system we've seen in other simulators, where it's clear the same animation has been used for all passengers, resulting in a very unnatural "army of clones" effect when they walk together. The main problem is: passengers needs to be versatile, go everywhere, climb steps, turn over waypoints. This means their animation is PART manually animated and PART procedural, namely the translation/rotation part is made procedurally, since a passenger can possibly walk around the whole airport. While is reasonably easy to make a convincing animation that works "in place" (like the dancing marshaller or the various poses "at rest" of the recent manual stairs operator), when you combine the mandatory procedural part with the manually animated part, there always be some kind of disconnection, since (for example) real people don't make turns in the same way (it changes depending on the turning radius), there's the missing "gait" effect (the translation speed is not uniform across the whole step cycle) because doing this would increase traffic over simconnect quite a bit (having to adjust the speed of each passenger at each frame). As always in GSX, there's always reasons why things are done in a certain way and not as they might be, if it ran under a character-oriented game engine (Unreal, Unity), instead of a flight simulator. Unfortunately, the new procedural character system added in MSFS 2024, is completely not documented, and there are no tools provided to create these new kind of passengers (and if you fill up the default 737 with 180 pax, you'll see how your fps will go down compared to GSX), we think because the character system has been supplied by a 3rd party that hasn't licensed their tools to be included in the SDK.

I don't see why not, the method would change depending how you are getting that data. If you are obtaining historical weather data from an online service, you make an web API call to get it. If the data is coming from an application into the sim, you can call Simconnect directly in an handler to get data from the sim.

Absolutely, there's a dedicated channel on GSX Community on Discord to discuss handlers (they have been playing with the Beta since a couple of weeks), and somebody already discussed about doing this. The ability to parse CSV files from a Web API request has been added specifically because the Vatsim Slurper API returns CSV. Note that, there's no unified vACDM API in Vatsim, the individual branches have their own solutions, but as long as you can make an API call, and the result is either a .JSON string (most common) or a .CSV file, it can be read by an handler. What to do with the data, is completely up to the profile creator, but we provided support to inject any data into the VGDS, either by adding new cycling pages, but also replacing existing pages. It's an extension of the work we did a few months ago by providing the ability to customize VGDS messages, but it was more static and pulling data from the web would require writing a separate app, now it's all integrated in GSX, so it's easier to write and test, with no intermediate apps required.

I'm sure it will work better after PMDG removed all their automation code, which conflicts with GSX own automation. All those "random" doors openings are caused by that. The ZFW is also always entered correctly, but it will fail in case you have some characters on the scratchpad, or if your system is to overloaded, that even the very conservative delay time between keypresses that normally works, might not be enough in your system to prevent missing some keys. And since this post is about handlers then yes, you CAN configure this delay by changing a property in the PMDG Handler. Of course the VGDS shows the airline code in addition to the flight number, assuming is correctly set in the flightplan (because in many cases is missing from the aircraft.cfg or the livery.cfg and yes, in this version we read even the non-standard PMDG livery.json, because for some reason they place the icao airline code only there, instead of the standard locations). In addition to that, you must have missed an update which came out months ago, which introduced the ability for users (or creators) to CUSTOMIZE every VGDS page, by using local .json. Handlers make it even more dynamic, allowing to customize VGDS messages on the fly, based on any kind of logic.

Follow up from that: 🌐 Your GSX airport just got a live connection to the outside world. Following up on our recent post about Handler Scripts, we want to spotlight one of the most powerful — and perhaps unexpected — capabilities they bring: your airport and aircraft handlers can now reach out to the internet in real time. Not just to display a static message. We mean actually fetching live data, downloading updated files, talking to APIs, and keeping your airport in sync with the real world — automatically, every time you fly. Let's walk through what's possible. 📡 Live weather from a real meteorological API The moment you park at a gate, a handler can call the open-meteo.com API with the exact coordinates of your airport and pull down the current temperature, wind speed, and conditions. No plugins, no external tools — just your airport handler making a web request and showing you: "Current conditions at EDDM: 2°C, wind 18 km/h NW." This is real weather data from a real API, fetched the moment your wheels stop. And since the handler knows your airport's latitude and longitude automatically, the call is completely self-configuring. 📋 VATSIM live traffic — who's online, what's filed If you fly on VATSIM, handlers can poll the public VATSIM data feed — a live JSON file updated every 15 seconds — and cross-reference it with your SimBrief flight plan. Is your callsign currently connected? What squawk code were you assigned? What destination did you file? All of this can flow directly into your VGDS docking display at the gate. While you're on stand, the board cycles through your squawk, your filed destination, your online/offline status. It updates automatically in the background every 30 seconds, without you doing anything. Flying offline? The display simply stays clean. Come back online, and within half a minute it picks you up again. 📁 Airport profiles that update themselves This is where things get genuinely exciting for profile creators. With fetchINI() and fetchPY(), an airport handler can download the latest version of your airport's profile and parking customization file directly from your own server — every single time the pilot arrives at your airport. Think about what that means: you publish an updated profile fixing a gate position, adjusting a pushback route, or adding a new stand. Every user running your handler gets it automatically on their next flight, with no manual reinstall, no forum post saying "please re-download version 1.3." They just land, and it's already there. The system is smart about it too — it uses HTTP ETags to only download when something has actually changed. If your files haven't been updated since the pilot's last visit, nothing is transferred. Zero bandwidth waste. A concrete example: you maintain the profile for Milan Malpensa (LIML). You push a corrected parking layout to your server. The next time any user with your handler lands at LIML, onEnterAirport runs, calls your server, gets a 304 "nothing changed" on the INI — but detects the PY file is new, downloads it, and silently reloads the airport customization. The pilot never notices. It just works. 📊 CSV data feeds — real airline schedules, ATIS, custom databases fetchCsv() opens up a whole category of structured data sources that speak the humble comma-separated format. Some ideas that become straightforward: Pull a real-world schedule CSV for a specific airport and check if your flight number matches a known departure slot — then show the real scheduled time on the VGDS display. Maintain a gate assignment table on your server: a simple CSV mapping airline codes to terminal areas. Your handler downloads it on arrival and routes each airline to the correct part of the airport automatically. Use the VATSIM Slurper API (which returns headerless CSV) to check ATC coverage — is there a ground controller online at your destination right now? Show it on the VGDS as the pilot prepares for pushback. The function handles headerless CSV gracefully — you supply the column names yourself, and rows with extra fields (like variable-length position data) get collected into a separate list automatically. 📦 Reading INI and JSON configuration files locally too Not everything needs to come from the internet. Handlers can also read local configuration files directly from the aircraft package — the aircraft.cfg, the manifest.json, PMDG's 737_Options.ini from the WASM work folder, or any custom JSON file you ship with your add-on. This lets aircraft developers make their handlers truly self-configuring. A handler can open the manifest, read the package version, and adjust its behavior accordingly. It can read a PMDG options file and detect whether a specific avionics configuration is active, then change the pushback parameters to match. All without hardcoding anything. ⚡ It's all non-blocking One concern people might have: won't making web requests freeze the simulator? No — and here's why. All the fetch* functions are designed to be called from within handler methods that run in background tasklets. A polling loop that checks VATSIM every 30 seconds runs entirely in the background with runAsync(), completely independent of GSX's main operations. The simulator keeps running, vehicles keep moving, passengers keep boarding. Your web request happens quietly in the background and updates the display when it's ready. Even ETag caching is built in — if the server hasn't changed its data since your last poll, the response comes back instantly from cache with no network round-trip at all. 🔒 A word on safety The fetch system is deliberately constrained. Profile downloads (fetchINI and fetchPY) require HTTPS — plain HTTP is rejected. Downloaded profiles are parsed safely without executing arbitrary code. File access is restricted to specific virtual prefixes — no handler can reach outside its sandbox to touch arbitrary files on your system. The data is limited to 5 MB per response. These aren't limitations — they're the reason you can trust a community-made handler running on your machine. The bigger picture Static airport profiles describe a place. Handlers with live data make that place aware. An airport that knows the weather. A gate display that shows your live VATSIM squawk. A profile that keeps itself up to date. A handler that reads your SimBrief plan and reconfigures the entire turnaround — vehicle types, fueling method, boarding flow — based on the actual flight you filed. This is what the fetch API unlocks. And it's available right now, in the Handler Script Editor built into GSX, with full documentation and working examples to get you started.

🛫 GSX is about to get a whole lot more alive. Most of you know GSX as the tool that brings realistic ground handling to your flights. You’ve seen the fuel trucks, the jetways connecting, the baggage carts rolling in. Many of you have already built airport profiles — and that’s fantastic. But there’s a new layer that’s going to change what GSX can feel like, and we want to explain it in plain terms. What is a “Handler”? Every aircraft GSX supports has a hidden brain called a handler. It’s something that until today it has been inaccessible to end users, it’s the elusive “Internal profile”, that sometimes does quite a bit of job to adapt to some airplanes, think the automatic operation of the FMC on PMDG airplane: it’s performed by GSX internal handler. In more simple cases, the handler just set some settings that makes the airplane work better, such as the “salute” position for the crew at the end of the pushback, a customized eyepoint (some planes have it wrong), the amount of pitch up when the plane is raised by a towbarless tug, lots of small little things that couldn’t be customized before with the normal settings. Now, for the first time, you can write your own handler scripts — small Python files that extend or modify this behavior, without touching GSX itself. You only write what you want to change. Everything else keeps working as before. What is an “Airport Handler”? Think of it this way: aircraft handlers answer “how does GSX talk to this plane?” — while airport handlers answer “how should operations work at THIS airport?” An airport profile (the .ini file you already know) is static — it stores fixed gate positions and vehicle spots. An airport handler is living code that reacts to what’s actually happening: which airline just landed, how many passengers are aboard, what time it is, whether it’s raining. It’s the difference between a painted backdrop and a real operations coordinator. And the best part? Airport handlers integrate directly with the airport profiles that community creators already make. Every profile can have its own handler. The barrier to entry is low — you don’t need to write a handler to publish a great profile, but if you want to go deeper, the tools are right there. What could this actually look like? Some real examples: 🌙 Night curfews at noise-sensitive airports Imagine flying into Munich (EDDM) at 23:30. A handler for that airport knows the local time, and automatically forces all passenger movement through buses — no walking on the ramp. Stairs don’t deploy. A message appears: “Night operations active — ramp restricted.” Just like in real life. 🌧️ Weather-reactive ramps Landing at Amsterdam Schiphol (EHAM) in a rainstorm? The airport handler reads the simulator’s precipitation state and switches all boarding to jetway or covered bus — no open-air stair trucks in the pouring Dutch rain. Fine weather comes back, and normal operations resume automatically. ✈️ Low-cost airline rules at a busy European hub Flying a Ryanair livery into London Stansted (EGSS)? The handler reads the airline code from your SimBrief plan, sees it’s a low-cost carrier, and immediately sets the gate to stairs-only with no jetway — because that’s exactly how Stansted handles LCC operations. A legacy carrier on the same stand gets the jetway. ⛽ Underground fueling where it actually exists At Frankfurt (EDDF) Terminal 1, wide-body international gates have underground hydrant fueling — no truck driving up to the wing. An airport handler can check the aircraft wingspan and the destination type (domestic vs. international), and automatically enable the underground system for the right flights, while regional jets get the fuel truck as normal. 🏔️ High-altitude airports with special pushback rules Flying into Innsbruck (LOWI)? Remote mountain stands have no towbarless tug — a handler can detect the gate type and force towbar pushback, then optionally ask the pilot to confirm before anything moves. 🇯🇵 Japan’s legendary ground crew precision At Tokyo Haneda (RJTT), a handler could detect that you’re on a domestic ANA or JAL flight and automatically increase the passenger density, tighten the boarding time, and display a structured sequence of service messages timed like a real JAL turnaround — crew first, then passengers, bags loaded within a tight window. The VGDS display at the gate could show your squawk and destination if you’re flying on VATSIM. 🛫 Asking the pilot before services start Some aircraft — like the PMDG 737 — have a built-in ventral staircase. At a gate that has a jetway, a handler can pop up a menu before any vehicle decisions are made: “Do you want to use the aircraft’s own stairs, or the jetway?” If you pick stairs, the jetway is suppressed and the built-in animation takes over. If you’re on a budget airline route, that’s exactly what would happen in real life. Why does this matter for airport profile creators? Right now, the airport profile community is huge and growing. Hundreds of airports have been carefully configured by dedicated simmers. But profiles have always been static — the same experience every single time, regardless of the aircraft, the airline, the time of day, or the weather. Airport handlers change that. A profile creator who writes a small handler alongside their .ini file can now make their airport respond to the world around it. And it doesn’t have to be complex — even a simple script that shows a custom welcome message, or enables underground refueling at specific gates, makes a profile feel dramatically more polished and real. There’s even a built-in script editor right inside the simulator, with syntax highlighting, an interactive Python console, and one-button apply to test changes live without restarting anything. The future of GSX is community-driven operational intelligence. Aircraft developers can ship handlers inside their packages. Profile creators can layer airport logic on top. The systems stack cleanly — aircraft handler knows the plane, airport handler knows the airport, and they work together without getting in each other’s way. We’re incredibly excited to see what the community builds with this. The documentation is out — go read it, experiment in the built-in editor, and start turning your airports from static scenery into living, breathing operations. The ramp is yours. 🟡 Want to dive in? Check out the Handler Scripts Developer Guide here: https://update.virtualisoftware.com/Handler_Scripts_Developer_Guide.html

GSX cannot possibly affect the Fenix EFB, they are completely separate systems, and the communication exchange happens mostly by LVars (zero direct access between the two), with GSX being controlled by Fenix, not vice-versa. There isn't a single function in the whole GSX that ever changes the *state* of the airplane (any airplane), except for the brief moment during pushback, where the airplane is moved by GSX, and the only thing that is being changed is the airplane position using a standard and 100% safe Simconnect call, no other systems or variables in the airplane are touched by GSX, when you call refueling, the airplane is refueling itself: the GSX fuel truck it's just there for show to display various animations for the duration of the process (it's not actually filling anything), when you load pax/cargo, the airplane is changing its payload by itself, GSX is there just to show pax/cargo animations, but it won't alter the payload either. In brief, with an airplane deeply integrated with GSX like the Fenix, none of the things "happening" on the airplane are done by GSX, they are done by the airplane own automation code, that reacts to GSX events, and changes its status (fuel, payload, etct) exactly in the same way as if you were doing it manually from the EFB.

What's wrong with it ? We already supports all models, both 2020 and 2024 versions so, unless something is not working as expected, the support for all current models is there.