Facility Engineering FAQ

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. The locations of runway thresholds are available via the syntax KJFK-22L where the airport name and runway specifier are separated by a hyphen.

Locations can also be specified via latitude-longitude positions, given as strings. For convenience, multiple latitude-longitude formats are supported.

(In all of the 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!

Running a Server Locally

If you're working on multi-controller support for a scenario, you may want to run a vice server locally to debug it. A few command-line options are useful:

• -runserver launches a vice server on your local system
• -server specifies the IP address and (optionally), the port of a vice server to connect to. Specifying localhost will connect to a local server launched via -runserver.
• -port allows specifying a custom port number for the server to listen to. If this is used, then the address supplied to -server should be of the form hostname:port.

Windows Example: Running a Local Multi-Controller Server

Here's a step-by-step guide for testing multi-controller scenarios on Windows:

1. Launch Command Prompt: Press the Windows key, type "cmd" in the search box, and press Enter.
2. Navigate to the vice directory: Enter cd "c:\Program Files (x86)\Vice"
   Note: The quotes are essential if the path contains spaces.
3. Start the multi-controller server: Enter enter vice.exe -runserver
   If there are errors in your scenario configuration, they will be displayed here. Otherwise, the server launches and will be running in the background.
4. Launch the first controller instance: Enter vice.exe -server localhost
   This launches vice connected to your local server. In the "New Simulation" window, you'll see the option to "Create multi-controller" simulation.
5. Launch additional controller instances: For each additional controller position, open another Command Prompt and enter: vice.exe -server localhost
   Each new instance can connect to the simulation created by the first controller. You'll be able to perform handoffs and coordinate between the different controller positions by switching between the vice windows.

Restarting after scenario changes: If you modify your scenario files, you must restart the server to load the changes:

1. Close all vice client windows
2. Press Ctrl+Shift+Esc to open the Task Manager
3. Click the "Details" tab and look for "vice.exe" in the list to find the server
4. Select it and click "End task"
5. Return to step 2 above to restart the server with your updated scenario

Routes

When an aircraft's route is given, vice allows airways to be used to describe the route, which simplifies the route specification when an aircraft is in fact flying along an airway. Airways are given as part of the route; for example "WHITE V1 DPK" has the aircraft join V1 departing WHITE and follow V1 until DPK. (The alternative, "WHITE DIXIE MOVFA JFK DPK", is more typing and more error-prone to enter.)

vice uses a custom syntax for specifying the routes of aircraft that allows giving additional information that is used in the simulation. 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 fixes along the departure runway are automatically provided by vice so the route starts with the specified fixes in the departure procedure. 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.

                "SKORR METSS RNGRR/h223"
              

A variety of such things can be specified along with a fix:

• /arestriction: for IFR routes, cross the fix with the specified altitude restriction (with altitudes specified in 100s of feet). For VFR, aircraft will be at a random altitude within a given altitude range. 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.
• /delete: the aircraft will be deleted when it reaches the fix
• /hheading: depart the fix at specified heading
• /lheading: turn left to the specified heading at the fix
• /rheading: turn right to the specified heading at 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). This must be specified for one fix in each approach.
• /flyover: indicates that the fix is a flyover fix (as opposed to the default, fly-by). Aircraft must pass directly over flyover fixes before turning to the next fix, while they may turn early with fly-by fixes.
• /ph: fly present heading (rounded to the nearest 5 degree increment) departing the fix.
• /sspeed: cross the fix at the given speed
• /caltitude: climb to the specified altitude (in 100s of feet, between 0 and 600) when passing the waypoint, as if the controller issued that instruction. Cannot be combined with /d at the same waypoint.
• /daltitude: descend to the specified altitude (in 100s of feet, between 0 and 600) when passing the waypoint, as if the controller issued that instruction. Cannot be combined with /c at the same waypoint.

A number of specifiers are intended for ambient traffic that's not under the control for a human:

• /clearapp: the aircraft will be cleared for the assigned approach passing the fix.
• /ho: the aircraft should be handed off from the virtual controller when it passes the fix. A TCP may be specified after /ho, in which case the aircraft is handed off to the corresponding virtual controller. If no TCP is specified, the aircraft is handed off to the appropriate human controller.
• /tc: "transfer comms": after passing a /ho fix, normally aircraft call in a few seconds after the human controller accepts the handoff. However, if /tc is specified at a later fix in the route, they won't contact the controller until reaching that fix. Additionally, this can be used in departure routes to signify a specific fix at which aircraft should contact the departure controller.
• /poTCP id: when the aircraft passes the fix and if it is under the control of a virtual controller, issue a point out to the controller identified by the given TCP id (i.e., the controller ID that would be used when doing a point out in STARS.)
• /radiusnum: rather than flying precisely to the fix, the aircraft will fly to a random point within num miles of the fix.
• /shiftnum: rather than flying precisely to the fix, the aircraft will fly along the route to the fix but will turn for the next fix at a random distance before or after the fix, up to num/2 nautical miles in each direction.
• /spspscratchpad: sets the aircraft's primary scratchpad to the given value.
• /ssspscratchpad: sets the aircraft's secondary scratchpad to the given value.
• /cpsp: clears the aircraft's primary scratchpad
• /cssp: clears the aircraft's secondary scratchpad

In addition to /radius and /shift, which are also useful for randomizing VFR routes, there's an additional specifier that can be used with VFR aircraft routes:

• /airwork: the aircraft should perform airwork centered around the fix. An altitude restriction must be specified using /a to give an altitude range for the airwork. By default, they will do so for 15 minutes and remain within 7nm of the fix; alternatively, the time or distance may be specified via /airworkradiusnm and/or /airworkminutesm. For example: /airwork30m10nm specifies 30 minutes of airwork within a 10nm radius of the fix.

If the aircraft should follow an arc leaving a fix, /arc can be given after the fix. It can be used in two ways:

• Both a radius in nautical miles as well as the fix at the center of the arc's circle can be specified. For example, HANAV/arc16OMN specifies a 16nm radius arc centered at OMN.
• Alternatively, just the length of the arc may be given. For example, WUPMA/arc7.5 ALABE has aircraft fly along the 7.5nm long arc between WUPMA and ALABE.

For both uses, 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/VOR/LOC 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/VOR/LOC) / 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

Departures, arrivals, and overflights all need to know about which airlines fly their routes and which aircraft they use for them. Airlines are specified via objects with the following members: for the database of possible airlines. In that file, each airline may have one or more aircraft fleets specified, in its "fleets" member.

If neither "fleet" nor "types" 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 or to specify aircraft types directly. 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.

Emergencies

Emergency aircraft can be configured to randomly occur during simulation sessions. The file resources/emergencies.json is used to store information about the possible emergencies, including what phase of flight they apply to, what radio transmissions pilots will make over the course of them, and what they will ask of ATC. That file contains an array of emergency specifications, each with the following members:

The emergency stages array in "stages" contains objects that define stages of the emergency. For example, this allows aircraft to ask for vectors to troubleshoot before either resolving a situation or going ahead and declaring an emergency. The objects have this structure:

Here is an example of an emergency with two stages: a departing aircraft will level off and ask for delay vectors. After 5-10 minutes, it will request to return to the departure airport.

{
    "name": "Landing Gear Retraction Failure",
    "applicable_to": "departure",
    "stages": [
        {
        "transmission": "we have a gear unsafe indication, requesting delay vectors to troubleshoot",
            "stop_climb": true,
            "duration_minutes": [5, 10]
        },
        {
            "transmission": "gear situation unresolved",
            "request_return": true
        }
    ]
}

Here is an example of an emergency that applies to multiple phases of flight:

{
    "name": "Medical Emergency",
    "applicable_to": "arrival,departure,approach",
    "stages": [
        {
            "transmission": "medical emergency, request EMTs at the gate",
            "request_return": true
        }
    ]
}

Speech

vice includes JSON files that map aviation terms to spoken pronunciations. These mappings are used for both speech-to-text recognition (understanding what a controller says) and text-to-speech synthesis (generating spoken responses from pilots). The files are stored in the resources/ directory.

Files with array values (airports, aircraft types) allow random selection among variants for more natural-sounding speech. Files with single string values have one canonical pronunciation.

Facility Configuration

Facility-wide settings are defined in separate JSON files, stored in the resources/configurations/ directory. They're organized by ARTCC and facility name (e.g., resources/configurations/ZNY/N90.json). When a scenario is loaded, vice automatically loads the corresponding facility configuration based on the scenario's "tracon" field.

Each facility configuration file may contain the following top-level elements:

[
    {
        "filename": "xyz001sgp.dat",
        "brightness": 0,
        "label": "XYZ RNAV",
        "title": "XYZ RNAV APPROACHES",
        "number": 1
    },
    {
        "filename": "xyz012smvagp.dat",
        "brightness": 1,
        "label": "XYZ MVA",
        "title": "XYZ AREA MVAS",
        "color": 3,
        "number": 12,
        "radius": 60
    }
]

> dat2vice manifest.json ZXX

> dat2vice -radius 40 manifest.json ZXX

Scenarios

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. The facility-wide settings (control positions, STARS configuration) are stored separately in facility configuration files.

These are the elements of a scenario group:

Airports

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:

                            "descent_distance": 0,
                            "descent_altitude": 3000,
                            "above_altitude_tolerance": 2000,
                            "below_altitude_tolerance": 2000

Approaches

The member names in the airport "approaches" object give the abbreviated name of each approach, as used in vice's ATC commands.

Approaches may be specified using data automatically loaded from the FAA CIFP or manually. To use CIFP data, run vice from the command-line and give it the argument -route KXYZ, where KXYZ is the ICAO code for the airport. vice will print identifiers for the available approaches and their associated fixs. For example:

                > ..\vice.exe -routes KMIA
                [...]  
                Approaches:
                I12  : DHP GLRIA/a3000+/lhilpt1.0min/pta3000/iaf PIANA/a3000+ VEPCO/a2000+
                [...]
                RY12 : WORPP/iaf GLRIA/a3000/if PIANA/a3000+ VEPCO/a2000+
                FOGSO/s210/iaf GLRIA/a3000/if PIANA/a3000+ VEPCO/a2000+
                [...]
              

Approach ids encode the type of approach—for example, I12 is an ILS approach to runway 27 and RY12 is an RNAV Y runway 12 approach. Given the id, the approach can be specified with:

Support for loading routes from the CIFP is new so please confirm that routes are correct and report any bugs you find. Note that not all approaches are included in the CIFP.

Alternatively, approaches can be defined manually using the following members:

Departures

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 in the airport definition 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,
                "sid": "JFK5",
                "waypoints": "KJFK-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 includes the following members:

Either "assigned_altitude" or "cleared_altitude" must be specified.

The other part 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",
                },
                ...
              

A few additional things must be specified with each departure:

It is optional to specify the final altitude for departures.

Arrivals and Overflights

Note: until recently, overflights were not supported and arrivals were specified using the "arrival_groups" variable, which is no longer available.

Arrivals and overflights are specified via the "inbound_flows" variable, which allows specifying the ways that aircraft from adjacent facilities enter the TRACON. "inbound_flows" has two members, "arrivals" and "overflights", each of which is an array of arrival and overflight specifiers, respectively.

vice allows specifying multiple arrival and overflight procedures together so that it can sequence them as a group. Thus, if an overflight route corresponds to a STAR, at least at the beginning, both should be specified together in the same "inbound_flow". Similarly, if multiple STARs have the same initial route, they should be together as well.

Arrivals

Each object stored in the "arrivals" 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.

There are two ways to specify a STAR's waypoints: automatically using data loaded from the FAA CIFP or manually. To use CIFP data, ensure that the STAR is available by running vice from the command-line and providing the -routes KXYZ argument, where KXYZ is the name of the airport. vice will print the available STARS with their transitions. For example,

                > ..\vice.exe -routes KLGA
                STARs:
                APPLE3.SHLBK: SHLBK LOUIE/a13000 BACKY ODESA DQO RUUTH WNDYL BRAND/a8000 KORRY DEPDY TYKES MINKS JERZY RENUE APPLE PROUD/flyover/h45
                APPLE3.SWANN: SWANN GATBY KERNO ODESA DQO RUUTH WNDYL BRAND/a8000 KORRY DEPDY TYKES MINKS JERZY RENUE APPLE PROUD/flyover/h45
                APPLE3.ALL  : RUUTH WNDYL BRAND/a8000 KORRY DEPDY TYKES MINKS JERZY RENUE APPLE PROUD/flyover/h45
                [...]
              

If the STAR specified in the "star" parameter is present, vice will automatically use the available routes to define the STAR's transitions and runway-specific waypoints. In that case, one additional parameter must be specified:

Alternatively, the waypoints may be specified manually using one required and one optional member.

The "runway_waypoints" member can be used for STARs that have different routes depending on the arrival airport and 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/ho 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 into KPHL, the only active airport in the scenario. Note that all start with JIIMS, the same fix at the end of "waypoints".

                "runway_waypoints": {
                "KPHL": {
                "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"
                }
                },
              

Overflights

An overflight is an aircraft that enters the TRACON already airborne, and flies through it without landing. Overflights are also specified in "inbound_flows" in the "overflights" member, which is an array of overflight specifiers. Each specifier may have the following members.

Each overflight specification includes one or more "airlines" in an array of objects that specify the airlines and aircraft that should be included in the overflight. In addition to the "icao", "fleet", and "types" members documented in Airlines and Aircraft, the following members may be specified:

VFR Aircraft

vice allows the specification of VFR "distractor" aircraft in scenarios; this provides realistic extra clutter in the scope and sometimes aircraft that need to be accounted for when vectoring IFR aircraft. If "vfr_reporting_points" are specified in the Scenario Group, then VFR aircraft will periodically call asking for flight following. For now, vice ensures that VFR aircraft remain clear of B and C class airspace.

VFR aircraft are specified using the "vfr" field in an airport's specification object in a scenario JSON file. They can either be specified with a specific route to fly, or it is possible to specify that they should fly a random route that ends up at one of the other airports that has VFR departures. In practice, it works well to have VFR departures both from class D and uncontrolled airports inside a TRACON but also from such airports up to 30-50 miles outside the TRACON; this gives good variety of both flights within the TRACON but also overflights, departures that land outside the TRACON, and arrivals that land within it. The following values can be specified in an airport's "vfr" object:

As discussed in Routes, there are additional specifiers that can be included with VFR routes that are useful with the "routes" option; adding /radius to fixes along routes is an easy way to add randomness to VFR routes. /airwork can also be used to have aircraft go out and do practice airwork from an airport.

Altitude restrictions in VFR routes are also handled specially: if a range of altitudes is specified using /a at a waypoint, VFR aircraft will select a random altitude within that range.

When defining VFR routes, it's a good idea to be mindful of class B/C airspace. When vice wants to create a VFR departure, it generates a random route, either fully on its own if "random_routes" is used, or using the route given in "waypoints" if "routes" is used. It then simulates the aircraft's flight and checks to see if it enters B/C airspace. If it does, it discards the route and generates a new one. It keeps doing this until it finds a valid route, but eventually it will give up if it's not being successful. Thus, feel free to define routes that are close to the boundaries of such airspace, but give vice some space to work with via /radius and altitude ranges so that it has a chance of finding a valid route.

Two other useful tools when working on VFR: in the STARS scope, if you type .VFR and press enter, vice will show all of the VFR departure airports by drawing a circle around their location and displaying their name. Entering .VFR again hides them.

Second, if you enter .DRAWROUTE in the STARS scope, you can click on a series of points to define a route. After each click, the clipboard is updated to have the lat-long coordinates of the entire route. Pressing [Backspace] removes the last point from the route. Here is an example of specifying a route along the south shore of Long Island and then North along the Hudson River for a N90 scenario.

Controller Airspace

Airspace volumes representing areas that particular controllers are responsible for may optionally be specified using the "airspace" object in the scenario group. If specified, vice will show an alert when aircraft owned by a controller are outside of their 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 the following members:

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.

Element	Type	Description
"airspace"	Object	Each member in the object defines the airspace associated with a control position. The object key is a controller id and the value is an array of strings, each of which corresponds to an airspace volume defined in the "airspace" section of the scenario group.
"arrival_runways"	Array of objects	Each object specifies an airport, one of its runways, and an optional go-around procedure. The specified airport must be present in the "airports" member of the scenario group, and the specified runway must be one of its runways.
"arrival_runways" members Element Type Description "airport" String An airport name. "go_around" Object (Optional) Defines the go-around procedure for this runway. "go_around" members Element Type Description "altitude" Number Altitude in feet (e.g., 2000, 3000). "handoff_controller" String (Optional) TCP that should handle the go-around aircraft. "heading" Number Heading in degrees (1-360). If omitted or 0, runway heading is used. "hold_departures" Array of strings (Optional) Runways on which departures should be held for one minute after a go-around. "runway" String A runway at the given airport.
"center"	String	(Optional) If specified, this gives the initial radar scope center (as a latitude-longitude position.)
"configuration"	String	A short identifier (maximum 3 characters) that references a configuration defined in "configurations" under "facility_adaptations". The referenced configuration provides the inbound and departure assignments and the default consolidation hierarchy for this scenario. The selected configuration must have assignments for all of the scenario's active arrivals and departures.
"default_map_group"	String	(ERAM only, Optional) The name of the default video map group to display when this scenario is selected.
"default_maps"	Array of strings	The names of the initial video maps that should be displayed when this scenario is selected. Note that "default_maps" may not be used if "video_maps" is specified in "controllers" or "areas"; in that case controller- or area-specific default maps can be specified there.
"departure_runways"	Array of objects	Each object specifies information about departures at a runway at an airport in the scenario.
"departure_runways" members Element Type Description "airport" String The airport's name. "category" String (Optional) Exit category. If present, only departures with an exit associated with the category will be launched from this runway. "rate" Number Number of departures per hour. "runway" String One of the airport's runways.
"inbound_rates"	Object	Each member specifies an inbound flow group and is an object that is a map specifying default rates for corresponding flows. Each entry should either be the name of an airport, in which case it specifies the rate of arrivals to that airport along arrivals in the flow, or the string "overflights", in which it gives the rate of overflights. It can be useful to specify a rate of zero—in this case, the inbound flow will still be included in the UI shown to the user, which allows the user to enable it.
"range"	Number	(Optional) If specified, gives the initial radar scope center range in nautical miles. This overrides the range given in the scenario group.
"vfr_rate_scale"	Number	Scale factor to adjust the rate of distractor VFR launches in the scenario. Set to 0 for none.
"wind"	Object	Specifies constraints for selecting wind conditions for the scenario. When a scenario is loaded, vice will randomly select historical weather data that matches the specified wind. If no wind specifier is provided, vice will automatically select weather compatible with the scenario's runway configuration. The wind can be visualized in STARS by typing ".WIND" and pressing [Enter]. The wind direction and speed are shown using arrows. "WIND" and an altitude will be shown in the preview area; the altitude can be stepped up and down using the up and down arrow keys. Pressing [Escape] clears the wind display.
"wind" members Element Type Description "direction" String (Optional) Wind direction range in degrees. Ranges must be less than 180 degrees wide and can wrap through north (e.g., "340-20" for a 40-degree range). "flight_rules" String (Optional) "VMC" for Visual Meteorological Conditions or "IMC" for Instrument Meteorological Conditions. "speed" String (Optional) Wind speed constraint in knots. Formats: "N+" for greater than N knots (e.g., "5+"), "N-" for less than N knots (e.g., "10-"), "N-M" for between N and M knots (e.g., "5-15").