Community and data

The traffic that you control comes from airline data. It uses the route patterns, callsigns and aircraft types of airline flights. The navigation data comes from the AIRAC cycle, which all of aviation uses. Players make and update much of the airport data.

A session uses data from three sources. You can add data to one of these sources.

Where the data comes from

Navigation data. Airports, runways, waypoints, airways and procedures come from a Navigraph AIRAC cycle. This cycle updates each 28 days. Navigraph subscribers can sign in and use their active cycle. All other players use the offline cycle that is included with the game. With the two types of cycle, the game operates without a network connection.

Game updates replace old navigation data included with the game, even when the AIRAC cycle number stays the same. The game still uses a valid subscriber download first.

Traffic. Flights use the route patterns of airline flights, between airport pairs that airlines fly. Thus, an airport pair with many airline flights has more traffic than a pair with a small number of flights. The sliders on the New Session screen control the quantity of traffic that shows.

Community content. At start-up, the game downloads airport changes from the community. This download is automatic. The changes include routes, runway configurations, sectors, minimum altitudes, colors and radar drawings. You do not install a file, and a subscription is not necessary. The game does not use Steam Workshop for this content at this time.

When the game loads community procedure alternatives for the selected airport, the New Session screen shows Community procedures below the airport. To see if these alternatives came from the community download or from a local file, put the mouse pointer on it. If Community updates paused shows at the top, the local override switch for modders is on. While this switch is on, the game does not download merged community files. To receive these files, set the switch to off or use the local drop-in folder.

Radar background lines, shaded areas and labels can change with the active runway configuration. Thus, the markings for one flow do not show in other flows. In a MANUAL session, only general markings stay.

Published initial climbs. Community airport data can set an initial climb altitude for each runway configuration or SID. One entry can also apply to all departures from one runway, or to all departures in one configuration. A departure on that runway starts with a clearance to that altitude. If there is no initial climb altitude, the game uses the first published SID altitude. If the SID has no altitude, the clearance is 10,000 feet, not the cruise level.

Procedures for new traffic. Community airport data can select the SIDs and STARs that new traffic uses, for each runway or runway configuration. When a session uses two departure runways, the game examines each SID with the list for the runway that the SID starts from.

Published arrival filing rules. Community airport data can send arrivals that file to one fix onto a STAR that starts somewhere else, when the airport’s published rules require it. For example, at Singapore, traffic on airway A464 flies to ARAMA, then direct to TEBUN, and joins the TEBUN STAR.

Published departures for each runway and aircraft type. Community airport data can choose the SIDs that departures get by default. It can also give a SID to some aircraft types only. For example, at Madrid, departures to NANDO, PINAR and RBO use runway 36R, the other departures use runway 36L, and the heavy aircraft types that the Madrid AIP lists use the X SIDs. Not in 0.6.2.552

Before a session starts, the game compares the community routes with the navigation cycle that is in use. Then it repairs the route file. Thus, an expired route does not cause a problem in your session.

Route sync continues to operate when the network is bad:

• If the game cannot connect to the primary servers, it downloads from a mirror server.
• If a download is not satisfactory, the game keeps your route file.
• The game changes to a new AIRAC cycle only after it installs the route data for that cycle.

While the game prepares the next cycle, the cycle selector continues to show the installed cycle. If a session cannot start, the message shows Switch to bundled AIRAC. With one click, you go back to the offline cycle. This cycle does not use the network.

Community data for Bundled and Latest

Community aviation files can contain a shared default and separate Bundled and Latest data. The game selects the data for its loaded navigation database.

Loaded database	Community data
Database included with the game	Bundled
Installed subscriber database	Latest
No separate data for that selection	Shared default

Your subscription status does not select the community data. A session keeps its selection until it ends. A database change updates the choices for the next session.

The tier names follow future navigation cycles. Contributors must check the runway and procedure identifiers when those cycles change.

The runway and visual-procedure editors have Shared default, Bundled, and Latest views. Select Customize this tier to copy the default for editing. Select Use shared default to remove that separate data.

EDDB uses 24s and 06s configurations. Each configuration includes both parallel runways for arrivals and departures.

Two items that you can correct on the website

A repository, a GitHub account and a command line are not necessary. Sign in with Google at voiceatcsimulator.com/contribute. Sign in is at the top right of each page of the site.

Your account page shows the name that other persons see on your contributions. The site makes this name for you, for example contributor-a1b2c3d4. Your name and your email address do not go into the repository, which all persons can see. The site keeps a one-way fingerprint of your Google account, not the address. Thus, the site cannot contact you. To see the results, come back to the site.

A maintainer examines each contribution before players receive it. Your contributions on the site shows the items that you sent and the result of each item. The Modding button on the Main Menu opens that page of the website.

Runway configurations

A runway configuration is a named configuration of the runways at an airport. It shows which runways are for arrivals and which runways are for departures. When you start a session, the game shows these configurations as alternatives. The traffic that the game makes uses them.

1. Select Airport. Find the airport by its name, city or four-letter code.
2. Open Runway configurations from the page of the airport.
3. Give the configuration the name that the airport uses, for example South flow or Night preferential.
4. On the diagram, click a runway end to use it for arrivals or for departures. Blue is for arrivals and orange is for departures.
5. If the airport uses more than one configuration, add more configurations.
6. Sign in. Then send the configurations.

The sequence is important. The configuration at the top is the game default. The game shows it first, and departure traffic uses it. Drag the configurations to change the sequence. Put the usual configuration of the airport first. The sequence changes how the airport operates in the game. It is not only a visual change.

A maintainer accepts or rejects the configurations that you send. After a maintainer accepts them, players receive them in approximately two minutes. The page monitors this procedure and tells you when the change is in the game.

Missing airports and missing runways. You can add an airport that is not in the game. Put it in an area near the airport. As an alternative, make a new area, for example a TMA, a FIZ or a CTR. The new area stays in the same FIR/ACC as the nearest area. If an airport is too far from all areas in the game, a maintainer must add it. If the site data has no position for a runway, the runway shows as a button below the diagram. This button has the same function as a runway end on the diagram.

The site shows the same airports as the game. Each of these airports has a hard-surface runway and a minimum of one ILS, RNAV, VOR or NDB approach.

Flight routes

Each flight that the game makes follows a route between its origin and its destination. The game makes this route from airline traffic data, but this route is only an estimate. If you know the routes that crews use in their flight plans, send them.

Community routes in your sessions. The game uses community routes before the routes that it makes. The routes that the game makes are the alternative. When community routes are available, each flight that the game makes uses one of them.

1. Select Flight routes.
2. Select the navdata lane. Current is the subscriber cycle. Offline is the cycle of all other players. Send to the lane that you use.
3. Enter the origin and the destination. Then load the pair. The page shows the route from the generator and all routes that players sent before.
4. Type the route and add it to the queue. The field examines the format while you type.
5. Sign in. Then send the routes. You can add more than one pair to the queue, or paste a list in Add many at once.

The format. Write the route as it is in the flight plan. Two rules apply:

• The first item of the route is the origin, and the last item is the destination.
• The route uses DCT after the origin and before the destination.

LEMD DCT PINAR UN870 DIPES DCT LEBL

Do not include runways, SIDs and STARs. The game selects them for the runway configuration that is in use.

More than one route for each pair. A pair can have a maximum of eight routes. Each flight that the game makes uses one of them. Thus, a pair with much traffic uses different routes, as airline flights do. A second route does not replace the first route.

Up to date or Deprecated. Each night, the site examines all community routes again with the live cycle. If a route is correct, it shows the Up to date badge and the cycle that the site used. If a route is not correct, it shows the Deprecated badge and the cause. The game then does not use this route. The game continues to operate, and the site does not erase the route. If a subsequent cycle makes the route correct again, the game uses the route again. A route that a maintainer accepted shows Not yet validated until the site examines it.

Save your link. Your routes do not go into the game at the time that you send them. First, a maintainer accepts or rejects the routes that you sent. Then the nightly check occurs some hours after the accepted routes go into the game. The send screen gives you a link. This link monitors the same list during the two periods. It clearly shows each decision for 90 days, or until you remove the contribution.

This link is most important for a long list. If you send four hundred routes, the site usually rejects a small number of them. The usual cause is an airway that does not connect as the flight plan shows. The page puts these routes into groups by cause. Each route has a link to its pair.

Your contributions shows a list of all items that you sent. Each item waits for a decision, is in the game, or a maintainer rejected it. A rejected item shows the cause if the maintainer gave one. You can remove an item that waits for a decision. You can also use Remove on an item that has a decision. Routes that are in the game stay there.

An inspection does not examine the facts

A maintainer makes sure that the data that you send is possible. The maintainer cannot make sure that crews use these routes in their flight plans. Send only data that you know is correct. Also, all persons can open the same page and correct the data. The site shows the person who made each change. It is possible to cancel each change.

Charted visual approaches

Named IFR visual approaches come from approved charts that are in effect. These approaches are not a new Navigraph approach type.

All persons can open Visual Procedures from /contribute. To send a procedure to a maintainer for inspection, sign in. You do not have to be a tester. Each procedure that you send opens a review pull request. A person must merge this pull request.

The workspace has three steps: Procedure → Route → Review. Procedure records the approach, the runway and the approved chart that is in effect. In Route, select Place waypoint before you click the map. As an alternative, select Use coordinates to enter decimal or DMS values. Open the path data or the restriction data only if the chart shows them. Review shows one summary. It gives a link from each problem to the field that you must correct. Send for review becomes available only after you correct these problems.

Each airport has one visual_procedures.json file. A file can contain more than one named procedure and runway variant. Altitude values and speed values have the label required or recommended.

Use a chart that is in effect

Do not make a procedure from memory. Do not use a screenshot without a known source. Do not use a Navigraph Z marker. Do not commit chart artwork. A maintainer examines the geometry and the source before the review pull request can merge. The simulator uses the runway threshold from its own navigation data. Thus, you do not write the threshold in the community file.

The builder examines the airport and runway identity, the coordinates, the leg types, the arc geometry, the source fields, the file size and distances that are not safe. A review pull request changes one airport file. A person must merge it.

Other community data

The community also makes minimum vectoring altitudes, procedure alternatives, constraints and other data. But you must send these data through the community repository. The Main Menu does not have a button for this repository. Use the link below. Refer to the Modding Wiki for all of the formats and the validation rules.

1. Fork the community repository.
2. Add or edit the airport files in your fork.
3. Do a check with the local validators from the documentation.
4. Do a test in your game first. Copy the file to the related local drop-in folder: %APPDATA%\VoiceATCSimulator\community\<kind>\local\<ICAO>.json. For procedure alternatives, this is community\procedure_options\local\LEBL.json. Start the game again. Make sure that the airport card shows Local file procedures. If you changed SPAWN marks in PROCS for that airport, your changes apply over the file. At the start of the session, a message tells you which procedures your changes make different. Not in 0.6.2.552 A STAR with spawn_enabled: false in the file, or a STAR that you set to off, follows the same three steps as a SPAWN mark that is off. Refer to PROCS. Not in 0.6.2.552 A SID or an approach with spawn_enabled: false, or one that you set to off, is not used by new departures or new arrivals. A departure with no SID that is on at its exit, and an arrival with no approach that is on for its runway, follow the steps in PROCS. The controller can still clear any SID or approach. Not in 0.6.2.552
5. Open a pull request with a name in this format: [FIR/Airport] Updated/Fixed/Added….
6. Read the comments from the automatic checks and from the maintainer. Do the necessary changes.

When the merged change is in a release, players receive the update at a subsequent start. If the local override switch is on, this update does not occur.