🛫 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

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.

I just wish it worked better with the PMDG 777. Random door openings on deboarding (where no jetways are present, particularly L1), wrong doors for catering vehicles (the catering vehicles arrive at one door and another empty door opens), wrong ZFW entered into the FMC (even though it's correct in SimBrief and appears throughout the rest of the simulator correctly).

Also bugs me that the VDGS shows FLTN instead of the correct airline callsign (BAW, VAA etc) regardless of aircraft used.

Hey, that’s pretty cool! Keep up the great job!

You have been cooking a fine meal again, Umberto.

5 minutes ago, BWBriscoe said:

I just wish it worked better with the PMDG 777. Random door openings on deboarding (where no jetways are present, particularly L1), wrong doors for catering vehicles (the catering vehicles arrive at one door and another empty door opens), wrong ZFW entered into the FMC (even though it's correct in SimBrief and appears throughout the rest of the simulator correctly).

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. 

 

Quote

Also bugs me that the VDGS shows FLTN instead of the correct airline callsign (BAW, VAA etc) regardless of aircraft used.

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.

Edited March 4Mar 4 by virtuali

This is brilliant mate.  Love your enthusiasm for the GSX project.

Jason

2 hours ago, BWBriscoe said:

I just wish it worked better with the PMDG 777. Random door openings on deboarding (where no jetways are present, particularly L1), wrong doors for catering vehicles (the catering vehicles arrive at one door and another empty door opens), wrong ZFW entered into the FMC (even though it's correct in SimBrief and appears throughout the rest of the simulator correctly).

Also bugs me that the VDGS shows FLTN instead of the correct airline callsign (BAW, VAA etc) regardless of aircraft used.

GSX works great for me with all the PMDG 777's. There are profiles on Flightto you can download and install.

 

2 hours ago, virtuali said:

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.

What if you're using historic weather in MSFS2024 tho?

A-CDM is now becoming more and more common in Vatsim. Will it be now possible to read the A-CDM data for being displayed on the VDGS?

@virtuali  Will this work for those who use historical weather data? 

49 minutes ago, keight said:

A-CDM is now becoming more and more common in Vatsim. Will it be now possible to read the A-CDM data for being displayed on the VDGS?

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.

26 minutes ago, JetClipperJR said:

Will this work for those who use historical weather data? 

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.

@virtuali, many thanks for the extra features especially for P3D. Looking through the fixes I couldn’t see anything regarding the removal of Ai at my chosen gate. It’s still not working.

1 hour ago, virtuali said:

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.

I always appreciate the work done by you Umberto, you have delivered an immersion changing addon with GSX. However, perhaps if I could offer some feedback, if I was asked for one single change to GSX, then it would be to see improved passenger animations! IMO there is scope for improvement. As I say, I appreciate your work with GSX, you have done a great job, but do you have plans in mind to address the animations in any way?

Edited March 5Mar 5 by Rocky_53