Getting Started

The radar client interface that vice provides is based on STARS. For familiarity to VATSIM controllers, vice generally follows the keyboard command scheme implemented in vSTARS; see the discussion of vice's STARS emulation below for more information.

The first time you launch vice, a window is shown for configuring the simulation. (After the first time, the window can be brought up by clicking the "replay" button in the menubar: .) A number of scenarios are available, some departure-only and some including both departures and arrivals. Here is the configuration window for LGA:

(Each scenario usually offers multiple runway configurations.)

In the configuration window, you can set the average departure rate (ADR) for all of the airports that may have departures in the scenario as well as the average arrival rate (AAR) for all of the arrival airports. (The LGA scenario only includes Laguardia Airport, though other scenarios include both a primary airport as well as satellites.) Both of these rates are specified in terms of aircraft per hour, so an ADR of 30 corresponds to one aircraft departing every two minutes (on average). If you'd like an arrival-only scenario, for example, just set all of the departure rates to zero.

The "Sequencing challenge" slider controls how challenging the departure sequence is—the higher it is, the more likely it is that successive departures will be to the same gate or to the same fix. For arrivals, the "Go around probability" slider allows setting the probability that each arrival goes around.

After you have configured the simulation, click "Ok" and you will have a STARS scope and flight strip window to work with. Use the usual STARS commands as appropriate (to initiate track, accept handoffs, handoff to other controllers, etc.), and the additional ATC commands below to issue control commands to aircraft.

When the simulation starts, vice also displays a small window listing the active departures, arrivals, and approaches. For this LGA scenario, three arrivals are active but there is just one approach and one departure. Other scenarios may be more complex.

The approach code—here, "I22"— is used in vice's aircraft control commands like "expect approach" and "cleared approach".

To free up space, you can close this window by clicking on the "X" in the upper right corner. Clicking on the button in the menubar will show the window again.

To adjust the amount of space used for flight strips, right click the line separating the flight strips from the radar window and drag left or right with your mouse.

A number of buttons are available in the menu bar at the top of the window:

• / : pause or resume the simulation.
• : opens the window to select a new scenario and set its parameters.
• : open a window that allows changing various settings. The most useful one is the simulation rate: you can speed up time during slow times or to increase the challenge.
• : show the window that lists the available approaches.
• : open a window with controls for launching aircraft, either automatically or manually.
• : open this webpage to review vice's documentation.
• : display information about the version of vice you have installed.
• : join the vice Discord.

When you exit vice, it remembers everything going on—all of the aircraft in flight, the instructions they have been given, etc. The next time you launch vice, it loads all of that back in and you can continue where you left off. If you'd like to start something new, just click and configure a new simulation.

When vice is paused, you can hover the mouse above a radar track to see information about the instructions the aircraft has been given so far—for example, altitude and speed assignments, whether it has been sent direct to a fix, the approach it has been assigned, etc. An example is shown below. This information is especially useful when resuming a vice session after you have been away from it for a while.

Drawing Routes

vice can draw the active departures, approaches, and arrivals for the current scenario. This can be helpful when studying those for an airport, since they are drawn directly on the radar scope with annotations that give the fixes, any altitude or speed restrictions, and procedure turns.

To toggle whether a route is drawn on the scope, click the checkbox on the left next to it in the scenario information window that is shown at the start or after clicking on the button in the menubar. For example, here is how the HVN RNAV Runway 2 approach is rendered:

We can see the procedure turn at PEPER and that it is both the IAF and the IF; altitude restrictions at both SALLT and PEPER, that SALLT is the FAF, and that arrivals from KEYED will not fly the procedure turn.

Launching Aircraft

When a new scenario starts, vice automatically launches new departures and arrivals based on the departure and arrival rates set in the "New Simulation" window. During a simulation, clicking on the departing plane icon in the menubar opens a window that allows more control over aircraft launches. (Note that when vice is used with multiple controllers in the same simulation, then only one controller may have this window open at a time.)

The rates for automatic launches can be adjusted in this window. Alternatively, aircraft can be launched manually. If manual launches are selected, the window shows all of the available departure runways and exits as well as all of the arrivals, as shown below. Clicking the aircraft icon for a departure or arrival causes the aircraft shown to be launched. If you'd like a different aircraft for the next launch (for example, to have a heavy aircraft), click the redo icon until you're happy with the selection. The window also shows the elapsed time since the launch of each type as well as how many miles in trail (MIT) there would be if the next aircraft was launched. To clear out all of the current aircraft and restart, click the trash icon: .

Multiple Controllers

With vice you can also have multiple controllers working aircraft together. Select "Create multi-controller" in the "New Simulation" window and you can select a scenario and set its parameters in more or less the same way that you do with a single controller. Here is the top part of the multi-controller configuration window; all of the settings that are the same as for single-controller aren't shown.

Each multi-controller simulation has a name associated with it; vice chooses a random one by default (above, it's "following-nature"). You're welcome to choose a different name if you prefer. These names can be used so that you can tell other people which simulation to choose in order to join you.

Selecting "Join multi-controller" shows a list of the simulations that are currently available, including how many controllers are signed into each one. Note that the simulation names are shown in the first column. After selecting one, you can choose one of the available control positions and join. vice also allows you to join a simulation as an observer, in which case you have no control capabilities.

ATC Commands

In order to issue control commands to aircraft, type the appropriate command from the table below and click on an aircraft's track. After you issue a command, the virtual pilot's readback is shown at the bottom of the window. The aircraft will then start following that instruction, to the best of its abilities. Unlike VATSIM, the pilots will always do exactly what you tell them to.

If you'd like to issue multiple commands to an aircraft, enter the commands one after another with a space between them and then click on the appropriate aircraft.

Airspace

vice is able to indicate when aircraft are outside of the departure or approach airspace, if it has information about the airspace boundaries. (This information is not available at all airports.) If an aircraft is outside of its assigned airspace, a red "AS" error will be printed at the top of its datablock, as shown below. The valid altitudes for the aircraft are shown as well, if there are any valid altitudes at its current location. For example, the aircraft below is at 5,000' but should be between 10,000' and 12,000' (or should be at a different location!)

Two commands are available to draw the boundaries and altitude ranges of the departure and approach airspace. (Note that the placement of the drawn altitude labels is not always ideal.)

STARS Emulation

vice attempts to present a reasonably accurate representation of the Standard Terminal Automation Replacement System. Its focus is to provide the STARS functionality that is useful for regular TRACON controlling; thus, obscure features like military operations area commands are not supported. If you are familiar with the actual STARS system, suggestions about how to improve vice's accuracy would be happily accepted! Head on over to the vice discord...

vice mostly follows the keybindings used in vSTARS; the vSTARS Command Reference provides a summary.

Differences from vSTARS

vice supports the following features from STARS that are not present in vSTARS:

• vice supports the STARS "FUSED" mode, which features updates of aircraft positions every second (rather than every 5 seconds) and round markers for primary radar tracks.) Select FUSED mode via the "SITE" menu from the primary DCB.
• vice supports the STARS "dwell" mode, which draws the datablock and leaderline of track under the mouse more brightly when it is enabled. Dwell mode can be configured by choosing "SHIFT" from the main DCB menu and then selecting the "DWELL" button, or via the following keyboard commands:
  • [multifunc] D E: enable dwell mode.
  • [multifunc] D L: lock dwell mode—the selected aircraft remains highlighted even if it or the mouse cursor moves.
  • [multifunc] D I: inhibit (disable) dwell mode.
• To quicklook a controller, vice does not support entering the controller id and hitting enter to toggle quicklook. Rather, the [multifunc] Q [id] command must be used.
• vice supports the "plus" specifier for quicklook: if a plus sign is specified after a controller id when enabling quicklook, the datablocks for that controller's tracks will be white, not green. (Similarly, ALL+ can be specified to quick look all controllers' traffic in this way.)
• vice allows placing DCB at the top, left, right, or bottom of the window using the "DCB TOP", "DCB LEFT", "DCB RIGHT", and "DCB BOTTOM" buttons.
• vice supports displaying the current weather radar for the selected location (though not yet with shading that matches STARS.)

Windows

To install vice on Windows, download and launch the installer below. After installation, vice will be available in the Windows Start menu and a shortcut will be added to your desktop.

Macintosh

On a Mac, download the zip file below; it contains a universal binary that runs on both Intel and Apple CPUs. Note that MacOS Big Sur or a more recent version of OSX is required. After opening the zip file, drag Vice.app to your Applications folder to install it.

Linux

On Linux systems, it is necessary to install vice from source. See the directions on building vice on Linux in the source code distribution for details.

Reporting Bugs

If you encounter bugs in vice, apologies! It would be of great help if you would send in a report if vice crashes or if you see mistakes in how it simulates aircraft or the STARS interface.

The best way to report bugs is via the "bugs" channel on the vice discord. Alternatively, if you have a github account, you can file bugs directly in vice's issue tracker.

Release History

0.10.10 (1 October 2023)

• Fixed a bug in the Windows installer that caused new scenarios (AAC, SAV, SDF) to not be installed locally.
• Added the ability to draw active departure, arrival, and approach routes on the radar scope.
• Facility engineering updates related to the above:
• When specifying fixes in approaches, you can add /iaf, /if and/or /faf to specify that a fix is the initial approach fix, initial fix, or final approach fix. This is then drawn on the scope when the approach is shown but isn't used otherwise.
• For arrivals under "arrival_groups", there is an optional string "description" field that will be shown in the UI. Similarly, for departures in "departure_routes", you can also give a "description" string.

0.10.9 (28 September 2023)

• Many improvements to the AAC scenario's accuracy:
• Added turboprop and piston departures and arrivals for AAC.
• AAC jet arrivals now come in on the TULSA4; turboprops and pistons pass through their approach gate (at lower altitudes) and are routed direct TUL.
• AAC departures now follow headings after takeoff (props 010 or 190, jets/turboprops 260/310, depending on departure gate.)
• Inbound handoffs are now 45 miles out.
• Fixed a bug where arrivals would sometimes climb after being cleared for the approach.
• Facility engineering: when exits are specified in "departure_routes", additional text can be included after a period. This text is ignored when determining which exit an aircraft uses. This can be useful if for example piston aircraft and jets have different departure procedures; "COLIN.P" and "COLIN.J" departure routes could be specified with the used for piston aircraft and the second used for jets.

0.10.8 (26 September 2023)

• When altitude and speed instructions are given, aircraft now do both at once. To give consecutive commands (e.g., "descend and maintain xxx, then reduce speed to yyy"), there is now a TS command for "then speed", and TA for "then altitude", or TC for "then climb", or TD for "then descend". (See the ATC command reference for details.)
• Updates to the JAX, C90, and F11 scenarios and a new D01/KSAV/KSDF scenario (Thanks to Mike D and Samuel Valencia!)
• Added a new scenario for KAAC/KJKE.
• Facility engineering changes:
• DME arcs can now be specified with approaches.
• Scratchpads may be specified individually with departures.
• Fixes can now be specified with respect to a distance along a radial from another fix.
• Various small bugfixes related to aircraft navigation and clearing approaches at fixes.

0.10.7 (8 September 2023)

• Fixed a bug where arrivals would disappear in some scenarios (KJAX, KDAB, ...)

0.10.6 (not released)

0.10.5 (6 September 2023)

• Added support for STARS fused mode (updates every second, round markers for radar tracks; choose "FUSED" in the "SITE menu.)
• It is no longer allowed to issue control commands to departing aircraft before they have checked in.
• Added multiple new ATC commands:
• EC/ED: expedite climb/descent.
• I: intercept the localizer (of the approach previously given with "expect approach").
• SMIN: maintain slowest practical speed
• SMAX: maintain maximum forward speed
• Afix/Capproach: at the specified fix, cleared for the given approach.
• More flexible altitude crossing restrictionsCfix/A100- is cross FIX at or below 10,000, CFIX/A120-150 is cross FIX between 12,000 and 15,000, etc.
• Facility engineering changes:
• Removed the "elevation" field for airports; it is no longer needed.
• Radars must have an "elevation" value specified, unless their location is given using an ICAO airport code, in which the airport's elevation is used.
• Minor fixes to the ABE scenario.

0.10.4 (16 August 2023)

• Added support for STARS Converging Runways Display Aid (CRDA).
• Made multiple improvements to aircraft flight modeling, including more accurate climbs at departure and better handling of wind.
• Tuned up pilot radio communications, including adding initial contact messages.
• Fixed a bug where after quitting and later resuming a simulation, some aircraft would forget their routing.
• Added support for the STARS Maps system list.
• Facility engineering changes:
  • Added "reporting_points" to scenarios: fixes aircraft may use when reporting their current position.
  • Added support for specifying volumes of space where collision alerts are inhibited.
  • Altitude restrictions at fixes are now more flexible: rather than just "at", they may be "between", "at or above," or "at or below."

0.10.3 (1 August 2023)

• Added "quick look" support to the STARS implementation.
• Added support for STARS dwell mode.
• Fixed a rare crash when manually adjusting launch rates.
• Various small improvements to the JAX and CLT scenario files.
• Many additional small cosmetic and functionality improvements to the STARS radar scope.

0.10.2 (28 July 2023)

• Added scenarios for the A80 (ATL) and A80 (BOS) TRACONs (thanks Mike K!).
• Fixed a bug with drawing *J cones in the STARS scope.
• Many improvements to the STARS DCB, including better rendering of the buttons, more support for configuring font size and brightness, as well as the ability to position the DCB on the top, bottom, left, or right edge of the screen.

0.10.1 (25 July 2023)

• Updated the font used in the STARS radar scope.
• Fixed a few bugs with drawing radar tracks in the STARS scope.
• Fixed a rare crash with incorrect command input to the STARS scope.

0.10.0 (22 July 2023)

• Vice now supports multiple controllers working in the same simulation. In the "New Simulation" window, choose "Create multi-controller" to create a new simulation or "Join multi-controller" to join an existing one.
• Facility engineering changes:
  • Removed "default_controller" and renamed "callsign" in scenarios to "solo_controller". Scenarios now take an optional "multi_controllers" object to specify a multi-controller scenario. Added "full_name" to controller specifications for better radio readback text.
• Launches of arrivals and departures can be controlled manually; click on the departing aircraft icon in the menu bar to open a window with launch controls. Alternatively, launch rates can be controlled during a session via that same window.
• Various improvements to the accuracy of the STARS radar scope simulation.
• Available approaches are now shown by vice at initial connection time and via the button in the menu bar.
• Many small bug fixes to aircraft flight modeling.
• New scenarios and improvements:
  • Added C90, including O'Hare East and West ops, MDW all configs
  • Added CLE TRACON, including final, feeder, and North/South scenarios
  • Added CLT TRACON, North and South configs
  • JAX: added DAB and the TEBOW1 arrival
  • N90: added multi-controller scenarios at JFK and PHL

0.9.2 (3 July 2023)

• Fixed the behavior of *T to better match STARS/vSTARS: the line is now drawn to the mouse position after the first point is selected, without waiting for the second point.
• Added more checks when loading scenario descriptions; in particular, misspellings and unused JSON objects are detected and an error is issued. This led to numerous small fixes in all of the the scenarios.

0.9.1 (20 June 2023)

• Fixed a bug where arrivals wouldn't obey altitude restrictions in STARs(!).
• Improved navigation: crossing restrictions beyond any at the immediately upcoming fix are now considered. Aircraft are now much better at starting altitude and speed adjustments in time to meet the crossing restrictions.

0.9.0 (15 June 2023)

• All new flight modeling engine supports procedure turns (both racetrack and standard 45/180) and more accurate turns to intercept localizers, etc. The approaches in the existing scenarios have been updated to include their procedure turns, where appropriate.
• A number of new aircraft control commands have been added:
  • Cancel speed restrictions
  • Cleared straight in approach
  • Cross fix at altitude and speed
  • Depart fix at heading
  • Fly present heading
• When a departure is handed off to a virtual controller, the other controller won't climb it further until after it is clicked by the user to acknowledge the handoff.
• Fixed very small fonts being used on Windows systems with high-DPI displays
• Numerous other small fixes and improvements, including in the wind modeling and fixing a case where arrivals would fly faster than the aircraft is capable.
• Facility engineering: In addition to new directives to specify procedure turns, there are a number of changes to how routes are specified.

Earlier Releases

• 0.8.1: fixed a bug where the STARS window wouldn't show anything.
• 0.8.0: When you quit vice, now it remembers all of the aircraft; when you launch it again, you can resume right where you left off. When the sim is paused, hovering the mouse on a radar track displays information about its routing and assignments. Many additional small bugfixes.
• 0.7.0: Added LGA scenarios (thanks to Arya T!), and various small bug fixes.
• 0.6.6: Small JAX scenario fixes and added ISP and HVN arrivals/departures to the JFK scenario.
• 0.6.5: Fixed another bug with intercepting the localizer.
• 0.6.4: Fixed a bug with intercepting the localizer that occasionally led to aircraft hanging in the air for a while before proceeding.
• 0.6.3: Added JAX scenarios for F11. Updated PHL scenarios for arrival changes.
• 0.6.2: Added go arounds and ABE TRACON scenarios.
• 0.6.1: Fixed a crash related to handed off aircraft and sped up launching vice.
• 0.6.0: Added scenarios in the F11 TRACON (MCO, SFB, ISM, ORL...). Thanks to Mike K!
• 0.5.1: Fixed bug with RNAV approaches not descending, improved JFK arrival spawn and route details.
• 0.5.0: Added new scenarios for EWR and LIB departure (thanks to Adam Bolek!)
• 0.4.3: Allow specifying JSON config on the command line, to make it easier to develop new scenarios.
• 0.4.2: Fixed a crash at first launch, updated syntax for "turn left/right X degrees" commands.
• 0.4.1: Fixed bugs in datablock positioning, added "turn left/right X degrees" commands.
• 0.4.0: Added PHL scenarios, airspace warnings, and FRG arrivals and intra-TRACON arrivals for JFK.
• 0.3.1: Added JFK approach scenarios, improved aircraft flight model, routes, and airlines.
• 0.2.1: Initial release

Specifying Locations

Throughout the vice configuration files, it's often necessary to specify various locations on the Earth. vice has a built-in database of all of the airports, VORs, NDBs, and fixes in the United States (courtesy of the FAA), which allows using these directly for specifying locations. Locations can also be specified via latitude-longitude positions, given as strings. For convenience, multiple latitude-longitude formats are supported.

(In all three examples above, the location specified is the same—the JFK VOR.)

In vice, if you hold down the control and shift keys and click on a point on the video map, the corresponding latitude-longitude position is copied to the clipboard—this can be very useful when developing new scenarios!

Routes

vice uses a custom syntax for specifying the routes of aircraft, both for arrivals and departures. In addition to the lateral positions along the route, it is possibly to specify speed and altitude restrictions, handoff points, and headings to fly.

Here is an example route from a JFK departure. The first two waypoints are custom fixes at the start and end of the KJFK 31L runway, specified via the "fixes" object in the scenario group, while the next three are standard fixes. The "/h223" after "RNGRR" specifies that the aircraft should fly a 223 heading as departing RNGRR. It will maintain that heading until it is further vectored by the controller. If there are further fixes after such a heading, the aircraft may be sent direct to one of those fixes by the controller.

  "_JFK_31L _JFK_13R SKORR METSS RNGRR/h223"
            

A number of items like headings can be specified with a fix:

• /arestriction: cross the fix with the specified altitude restriction (with altitudes specified in 100s of feet). The following options are available for specifying altitude restrictions:
  • low-high: cross at an altitude between low and high.
  • alt-: cross at or below alt
  • alt+: cross at or above alt
  • alt: cross at alt
• /hheading: depart the fix at specified heading
• /sspeed: cross the fix at the given speed
• /ho: the aircraft should be handed off from the virtual controller to the user when it departs the fix
• /iaf: indicates that the fix is an IAF (initial approach fix)
• /if: indicates that the fix is the IF (intermediate fix)
• /faf: indicates that the fix is the FAF (final approach fix)

If the aircraft should follow a DME arc leaving a fix, /arc can be given after the fix. It takes both a radius in nautical miles as well as the fix at the center of the arc's circle. For example, HANAV/arc16OMN specifies a 16nm radius arc centered at OMN. The direction of the arc is automatically determined based on the position of the following fix.

For approach fixes that have procedure turns, a number of additional items can be specified:

• /hilpt: there is a hold in lieu of procedure turn (i.e., a racetrack procedure turn) associated with the fix. The default is right turns and a 1 minute limit for ILS approaches and a 4 nm limit for RNAV approaches. Different limits can be specified directly; for example /hilpt6nm gives a procedure turn with a 6 nm limit and /hilpt2min specifies a 2 minute limit. For left turns, add a l after the slash, like /lhilpt.
• /pt45: specifies that there is a standard 45 degree procedure turn at the fix. (This has the same defaults— right turns, 1 minute (ILS) / 4 nm (RNAV)—as HILPTs. Alternative values are specified the same way.)
• /ptaaltitude: if the aircraft should descend during the procedure turn, this can be used to specify the final altitude it should have at the end of the turn. (The altitude should be given in 100s of feet.)
• /nopt180: specifies that aircraft approaching the fix in the 180 degree semicircle of directions aligned with the final approach course should not perform the procedure turn. (As an example, see the KJAX RNAV Z 8 approach; this applies for aircraft between heading 346 and 166 arriving at UDAQI.)
• /nopt: when specified at a fix prior to one with a procedure turn, indicates that aircraft that pass that fix should not fly the procedure turn.

Airlines and Aircraft

Both departures and arrivals need to know about which airlines fly their routes and which aircraft they use for them. Airlines are specified via their ICAO strings (e.g., AAL for American Airlines). See the file openscope-airlines.json for the database of possible airlines. In that file, each airline may have one or more aircraft fleets specified, in its "fleets" member. If no fleet is specified, vice randomly chooses an aircraft type from the "default" fleet, but if a particular fleet's aircraft is a better match to a route, you may want to use it. For example, AAL's "long" fleet would be a good choice for trans-Atlantic flights.

For reference, the available types of aircraft and their performance characteristics are available in the openscope-aircraft.json file.

As is probably obvious, both of these databases are by way of openScope, which kindly made them available under the MIT license.

Video Maps

Video maps are specified separately from the rest of the configuration since they require fairly large files and are not normally edited by hand. Video map files are simply JSON files with a series of members, each one of which stores an array of strings giving latitude-longitude positions. Each successive pair of positions specifies a line to be draw when rendering the video map. The following shows an excerpt from the ZNY video maps file that gives a sense of the format.

{
  "ABE": [
    "N041.00.05.616,W075.32.00.217",
    "N041.00.01.277,W075.32.29.551",
    ...
  ],
  "ABE - MVA": [
    "N040.31.00.726,W076.31.35.993",
    "N040.30.09.063,W076.31.21.985",
    ...
  ],
  ...
}
            

There is a utility program for extracting video maps from VSTARS configuration files; it is available from the vstars2vice releases page. Binaries for both Windows and Mac are available. It is a command-line program: the first argument should be the path to a VSTARS configuration file and the second a path to an output file.

Scenario Groups

vice offers users a variety of ATC scenarios, where a scenario consists of one or more airports being controlled, a control position (departure, approach, etc.), and airport configurations—the runways that are active at each airport. Scenarios are organized in scenario groups, which generally collect multiple control scenarios at a single airport. Each scenario group is specified by its own JSON file; see the resources/scenarios/ directory in the vice source code distribution for examples.

These are the elements of a scenario group:

Airports and Departures

The airports in a scenario group are specified via the "airports" member of the scenario group. Each airports is a separate member, named according to the airport's ICAO code (e.g., "KJFK"). The airport object then has the following member variables:

There are two pieces for specifying departures: their initial route leaving the airport, which depends on the active departure runway, and their subsequent route out of the TRACON, which does not. These two parts are specified separately.

The "departure_routes" object gives the initial routing for departures, based both on the runway they are departing as well as their exit fix. Here is an excerpt from the KJFK departure routes:

  "departure_routes": {
    "13R": {
      "ARD,DIXIE,RBV,WHITE": {
        "cleared_altitude": 5000,
        "route": "JFK5",
        "waypoints": "_JFK_13R _JFK_31L/h185"
      },
      ...
            

The members of "departure_routes" are strings identifying the departure runway; each departure runway's routes are then represented by an object with one or more members that specify comma-separated lists of exit fixes. (Thus, the specification above applies to departures with exit ARD, DIXIE, RBV, or WHITE, departing runway 13R.)

The exit fix specifiers may include additional text after a period to allow specifying situation-dependent exits. For example, we might specify one route for "RBV.PISTONS", another for "RBV.TURBOPROPS", and a third for "RBV.JETS". vice treats all of these as going to the "RBV" exit. When departures are defined in "departures", they can then refer to the appropriate exit in their "exit" specifier.

The departure route specification has three required members:

• "cleared_altitude": the initial altitude that aircraft are cleared to
• "route": a string naming the route that is added to the start of aircraft's route as shown in flight strips, etc.
• "waypoints": the initial series of waypoints that the aircraft follows. (Here, the first two are custom fixes specified at the ends of the runway.

It also takes an optional "description" member, which is string-valued. This description is shown in the UI for choosing routes to draw on the radar scope.

On departure the aircraft will fly the specified waypoints and then the waypoints specified in the route to its destination. In this case, aircraft will remain on a 185 heading until vectored by the controller (as explained in Routes, above.)

The other half of specifying departures is the array of objects stored in "departures". Each one describes a departure to a particular destination. Here is a JFK departure to Paris Charles de Gaulle:

    {
      "airlines": [
        {
          "fleet": "long",
          "icao": "AFR"
        }
      ],
      "destination": "LPFG",
      "exit": "HAPIE",
      "route": "HAPIE YAHOO WHALE N251A JOOPY NATZ MALOT NATZ GISTI LESLU M142 LND N160 NAKID M25 ANNET UM25 UVSUV UM25 INGOR UM25 LUKIP LUKIP9E",
      "scratchpad": "HAP",
    },
  ...
            

Four things must be specified with each departure:

• "airlines": The airlines that fly the route and which part of their fleet of aircraft is used; see airlines and aircraft below for more information
• "destination": the ICAO airport code for the destination. This is only used in flight strips and for the aircraft's datablock on the radar scope; it does not affect its routing.
• "exit": the exit fix for the departure. In conjunction with the departure runway, this is used to determine the aircraft's route leaving the airport using "departure_routes".
• "route": the aircraft's route to the destination. This is mostly used so that flight strips have plausible routes, though vice does its best to have the aircraft follow the given route after it reaches the exit fix.

The "scratchpad" field is optional; if specified, it gives the aircraft's initial scratchpad. Otherwise, the scratchpad is set based on the exit, using the "scratchpads" dictionary in the scenario definition.

Arrivals

Arrivals are specified via the "arrival_groups" variable, which allows specifying one or more STARs that bring aircraft to the TRACON. Members of "arrival_groups" give the names of arrival groups; each one stores an array of one or more arrival objects.

Because arrival rates are specified per-arrival group rather than per-STAR, vice can simulate center controllers sequencing multiple STARs into a single arrival flow rather than spawning arrivals on two STARs that follow nearby routes and thus should be sequences.

Each object stored in an "arrival_groups" array corresponds to a STAR. These objects have the following members:

STARs are sometimes able to deliver aircraft to multiple airports. Therefore, the "airlines" member is an object with airport names as members. Each of the airports is associated with an array of objects that specify departure airports, airlines, and (optionally) airline fleets. Here is an excerpt from the CAMRN4 arrival group at KJFK:

  "airlines": {
    "KFRG": [
      {
        "airport": "KDCA",
        "icao": "EJA"
      },
      ...
    ],
    "KJFK": [
      {
        "airport": "MMMY",
        "fleet": "long",
        "icao": "AMX"
      },
      ...
    ]
  }
            

We can see that CAMRN4 applies to both the KFRG and KJFK airports, though with different airlines and different departure airports for the arrivals. The specified departure airports (here, KDCA and MMMY) are only used so that flight strips and data blocks on the scope are realistic, but the specified airlines are used to select the type of aircraft from their fleets. As elsewhere, a value for "fleet" may be specified to limit which types of aircraft may be chosen.

The "runway_waypoints" member can be used for STARs that have different routes depending on the runway. When the user instructs the aircraft to expect a particular approach then the corresponding waypoints are added to its route. As an example, the specification of the KPHL JIIMS4 arrival starts with the following string for "waypoints": "HEKMN N039.27.43.645,W074.56.38.400 @ JIIMS@a8000". (The second point is used to set the handoff point to be between HEKMN and JIIMS.) It then has the following "runway_waypoints", corresponding to the runway-specific routes. Note that all start with JIIMS, the same fix at the end of "waypoints".

  "runway_waypoints": {
    "27L": "JIIMS@a8000 ZMRMN CHPMN PSOUT MKORD/h087",
    "27R": "JIIMS@a8000 ZMRMN CHPMN PSOUT MKORD/h087",
    "17": "JIIMS@a8000 SNEDE/h312",
    "35": "JIIMS@a8000 SNEDE/h312",
    "9L": "JIIMS@a8000 WUDRR WEVVE ERNYY/h268",
    "9R": "JIIMS@a8000 WUDRR WEVVE ERNYY/h268"
  },
            

Airspace

Airspace volumes may optionally be specified using the "airspace" object in the scenario group. These volumes may be assigned to controllers in scenarios, in which case vice will show an alert when aircraft are outside of the controller's airspace. The airspace object has two members:

Each member in "boundaries" names a polyline of one or more line segments. Polylines are specified by arrays of locations. The first and second points specify the first line, the second and third points specify the second line, and so forth. Here is an example from the KPHL airspace:

  "PHL_DQO27_33": [
    "N039.21.58.949,W075.28.55.977",
    "N039.25.56.240,W075.29.47.255",
    "N039.26.20.204,W075.27.28.196",
    "N039.22.24.699,W075.26.48.535",
    "N039.21.58.949,W075.28.55.977"
  ]

Note that the first point and the last point are at the same location and thus, "PHL_DQO27_33" is a closed polygon. Airspace boundaries do not have to be polygons like this; because boundaries are generally shared between different volumes of airspace, it's often useful to define boundaries just as polylines and to assemble multiple boundaries to define the lateral extent of a volume of airspace.

Given the boundaries, "volumes" specifies full 3D volumes of airspace. Airspace volumes have three members; "boundaries" is an array of strings that names the boundaries that give the airspace's lateral extent, and "lower" and "upper" specify the altitude range of the airspace. Here is an example from KPHL that uses the boundary defined above:

  "PHL_DU_APP27": [
    {
      "boundaries": [
        "PHL_DQO27_33"
      ],
      "lower": 5000,
      "upper": 6000
    }

Scenarios

Scenarios pull together components from the definitions in scenario groups in order to present specific control scenarios to the user. The scenarios object's members are the names of the scenarios. Each of these scenarios may have the following members: