Community and data

The traffic you control is not invented. It follows real route patterns, real airline callsigns and real aircraft types, over navigation data published on the worldwide AIRAC cycle — and a lot of the airport detail is maintained by players.

Three sources feed a session. One of them is a loop you can join.

Where the data comes from

Navigation data. Airports, runways, waypoints, airways and procedures come from a Navigraph AIRAC cycle, which updates every 28 days. Navigraph subscribers can sign in and use their current cycle; everyone else uses the bundled offline cycle. Either way the game works with no network connection.

Traffic. Flights use real route patterns between real airport pairs, so busy pairs produce more traffic than quiet ones. The sliders on the New Session screen control how much of it appears.

Community content. Airport improvements — routes, runway configurations, sectors, minimum altitudes, colours and radar drawings — download automatically at start-up. There is nothing to install and nothing to subscribe to; Steam Workshop is no longer used for this.

Not in 0.6.1.24 Radar background lines, shaded areas and labels can follow the active runway configuration, so flow-specific markings stay out of other flows. In a MANUAL session, only general markings remain.

Published initial climbs. Community airport data can set an initial climb altitude for each runway configuration or SID. One entry can also cover every departure off a single runway, or every departure under one configuration. Not in 0.6.1.24 A departure on the runway starts cleared to that altitude. Without one, the first published SID altitude is used; if the SID has none, the clearance defaults to 10,000 feet rather than cruise.

The game matches community routes against the navigation cycle in use and repairs the route file before a session starts, so a route that has gone stale never breaks your session.

Not in 0.6.1.24 Route sync survives bad networks: downloads fall back to a mirror when the main servers are unreachable, a failed download keeps your current route file, and an AIRAC update switches only after its matching route data is installed. While the next cycle is being prepared, the cycle chooser continues to show the installed cycle. If a session is still blocked, the message offers Switch to bundled AIRAC — one click returns you to the offline cycle, which needs no network.

Two things you can fix from the website

No repository, no GitHub account, no command line: sign in with Google at voiceatcsimulator.com/contribute. Sign in sits at the top right of every page on the site.

Your account page shows the name the world sees on what you send: a generated handle such as contributor-a1b2c3d4. Your real name and your email address never reach the public repository. The site keeps a one-way fingerprint of your Google account and not the address itself, so it has no way to contact you — which is why outcomes are something you come back and read.

A maintainer checks each contribution before it reaches players, and Your contributions on the site shows what you have sent and how each one ended up. The closed-beta Main Menu’s Contribute button opens that website page.

Not in 0.6.1.24

Runway configurations

A runway configuration is one named way of running an airport — which runways take arrivals, which take departures. The game offers these when you start a session, and generated traffic flies them.

1. Pick Airport and search by name, city or four-letter code.
2. Open Runway configurations from the airport’s page.
3. Name the configuration — South flow, Night preferential, whatever the airport itself calls it.
4. On the diagram, click a runway end to land there or depart from there. Blue is arrivals, orange is departures.
5. Add more configurations if the airport runs more than one way.
6. Sign in and send it.

Order matters. The configuration at the top is the game default — what the game offers first and what departing traffic assumes. Drag to reorder, and put the airport’s usual setup first. That is a real change to how the airport plays, not a cosmetic one.

A maintainer accepts or declines what you send. Once accepted it reaches players in about two minutes, and the page follows it in and tells you when it is ready.

Missing airports and missing runways. You can add an airport the game does not have, placing it in a nearby area or creating a new one (TMA, FIZ, CTR…) — the new area stays under the same FIR/ACC as the nearest existing one. An airport too far from any covered area needs a maintainer. And where our reference data has no position for a runway, it appears as a button under the diagram and works the same way.

The site offers the same airports the game does: a hard-surface runway and at least one ILS, RNAV, VOR or NDB approach.

Flight routes

Every generated flight follows a route between its origin and destination. The game builds one from real traffic data, but that is a best guess — if you know what crews actually file, share it.

Shared routes in your sessions. Community routes are preferred over generated ones, which stay as the fallback. Each generated flight picks one of the shared routes when available.

1. Pick Flight routes.
2. Choose the navdata lane: Current is the subscriber cycle, Offline is what everyone else plays on. Share to the one you play.
3. Enter origin and destination and load the pair. You see what the generator produces today and every route already shared.
4. Type the route and queue it — the field checks the format as you type.
5. Sign in and send. You can queue several pairs, or paste a list under Add many at once.

The format. Write it as filed, with two rules: it starts with the origin and ends with the destination, and it leaves and joins with DCT.

LEMD DCT PINAR UN870 DIPES DCT LEBL

Leave out runways, SIDs and STARs — the game picks those to match the runway configuration in use.

Several routes per pair. A pair holds up to eight. Each generated flight picks one, so a busy pair flies the same variety of routings you would see for real. A second route does not replace the first.

Up to date, or deprecated. Every night all shared routes are re-checked against the live cycle. One that still resolves is badged Up to date with the cycle it was checked against; one that no longer does is badged Deprecated with the reason, and the game simply stops using it. Nothing breaks in play, and nothing is deleted — if a later cycle makes it valid again it comes back by itself. A route that has just been accepted reads Not yet validated until that check runs.

Save your submission link. Sending and going live are not the same moment: a maintainer accepts or declines what you sent, and the nightly check runs hours after accepted routes go live. The link the send screen gives you follows the same list through both waits and shows every verdict in plain words, for 90 days or until you remove the submission. It matters most for a big list: send four hundred routes and a handful will usually be set aside for an airway that does not connect the way the filing suggests. The page groups them by reason and links each one back to its pair.

Your contributions lists everything you have sent — waiting, in the game, or declined with the reason where the maintainer gave one. You can withdraw anything still waiting, and Remove anything already decided; routes already in the game stay there.

A review is not a fact-check

A maintainer checks that what you send is sensible; they cannot check that it is what crews really file. Only share what you actually know to be true. In exchange, anyone can open the same page and correct it. Every change is credited and can be undone.

Charted visual approaches

Not in 0.6.1.24

Named IFR visual approaches are transcribed from current official charts. This is not a new Navigraph approach type.

Signed-in testers and administrators can open Visual Procedures from /contribute. Its TESTER chip names the minimum role. Each submission opens a review pull request for a maintainer; it never auto-merges one.

The workspace guides the author through Procedure → Route → Review. Procedure records the approach, runway and current official chart. In Route, choose Place waypoint before clicking the map, or choose Use coordinates for decimal or DMS input. Open path or restriction details only when the chart publishes them. Review shows one summary and links each blocking issue to the field to fix before Send for review becomes available.

Each airport contributes one visual_procedures.json file. A file can contain several named procedures and runway variants. Altitude and speed values are marked required or recommended.

Use a current chart

Do not draw from memory, a screenshot without provenance, or a Navigraph Z marker. Do not commit chart artwork. A maintainer checks the geometry and source before the review pull request can merge. The simulator supplies the runway threshold from its own navigation data, so it is not hand-authored in the community file.

The builder checks airport and runway identity, coordinates, leg types, arc geometry, source fields, file size and unsafe distances. A review changes one airport file and never auto-merges.

Everything else

Minimum vectoring altitudes, procedure options, constraints and the rest are community-maintained too, but go through the community repository. The stable release’s Mods button opens it. Closed beta removes that button from the Main Menu; use the link below instead. Not in 0.6.1.24 The Modding Wiki is the full format and validation reference.

1. Fork the community repository.
2. Add or edit the airport files in your fork.
3. Run the documented local validators.
4. Open a pull request named like [FIR/Airport] Updated/Fixed/Added….
5. Answer any automated-check or maintainer feedback.

After merge and release, players get the update on a later start.