Skip to content

Latest commit

 

History

History
44 lines (29 loc) · 3.9 KB

File metadata and controls

44 lines (29 loc) · 3.9 KB

vacs Dataset Documentation

This dataset configures the relationships between stations, positions, and profiles, defining the communication setup for controllers in a centralized and structured manner.

This repository is primarily intended for NAV team members and contributors who want to define or maintain how controllers communicate within their FIR using vacs. It is not intended for end users, who should instead refer to the main vacs repository for information on how to use vacs.

Directory Structure

The dataset is organized by FIR code in the dataset/ directory. Each FIR has its own subdirectory named after its ICAO prefix (e.g., LO for Austria, ED for Germany).

dataset/
├── {FIR_CODE}/
│   ├── stations.{toml|json}          # Station definitions
│   ├── positions.{toml|json}         # Position definitions
│   └── profiles/                     # Profile configurations (one or more per FIR)
│       ├── {PROFILE_ID}.{toml|json}
│       └── ...
└── ...

Core Concepts

At a high level: a controller connects as a position, which controls one or more stations, and is presented with a profile defining their UI and available calls.

The dataset consists of three main components:

  1. Stations: Represents a specific frequency, service, or sector (e.g., LOWW_TWR, LOVV_N1, LOVV_N2). On VATSIM, it is common for a single controller to control multiple stations simultaneously, especially on APP/CTR positions where real-world sector granularity is often simplified.
  2. Positions: Represents a position, directly tied to a controller login (e.g., LOWW_TWR, LOVV_CTR). A position is what a user connects as, similar to the positions defined in sectorfiles, and represents the controller’s identity on the network. One position can control multiple stations.
  3. Profiles: Defines the UI layout and available stations to call for a specific position or set of positions. Depending on the position they connect as, a user is automatically served the appropriate profile and will have the defined stations available to call.

File Formats

Configuration files can be written in either TOML or JSON. The examples in this documentation will primarily use TOML for readability, but JSON is fully supported and often preferred (e.g., for complex profile layouts). TOML is generally recommended for simple configurations, while JSON may be more convenient for complex or deeply nested profile layouts.

Various tools exist to help you create and edit TOML files, with Visual Studio Code being a popular editor of choice with good support for both TOML and JSON.

If you are using Visual Studio Code, you can use the Even Better TOML extension to get syntax highlighting and validation for TOML files. JSON support is built-in natively.

If your tool of choice supports JSON Schema, you can find the schemas for all dataset configurations in the docs/schemas directory or on GitHub: