openscope / openscope

openScope Air Traffic Control Simulator

openScope Air Traffic Control Simulator

Visit http://openscope.io to begin playing now!

If you're just getting started, try the tutorial and see the command reference for a full list of commands you can use. For information on each airport, see the airport guide.

Feel free to join us on slack if you have questions, comments or would like to contribute to the project. We can then add you to the organization so you can begin committing to this repo.

---

Developer Quick Start

Prerequisites: In order to successfully complete this quick start, you will need to have the following installed locally:

• Git
• Node

Installation directions are beyond the scope of this document. Instead, search the Google. Installing these two packages has been written about ad-nauseum.

From a terminal (or GitBash for Windows users), run the following commands:

1. git clone https://github.com/openscope/openscope.git
2. cd openscope
3. npm install
4. npm run build
5. npm run start

Once that finishes doing its thing, you should see something close to the following in the terminal:

> node ./public/assets/scripts/server/index.js

Listening on PORT 3003

Success!!

You you do not see this message and are having trouble getting set up, please join us on Slack and someone will be able to troubleshoot with you.

For more information on the available tools, please view the Tools Readme.

Contributing

We do not use forks. Instead, we add to add all contributors to the openScope organization. This way, we can keep all branches local to the organization, and use testing integrations on pull requests. If you are interested in contributing, please message Erik Quinn or Nate Geslin on slack so you can be added to the organization.

We use the GitFlow Branching Model for managing branches. If you would like to contribute, you will be expected to use appropriate branch names based on this methodology (and we can help if you have questions).

Don't know Javascript? That's cool, we're always looking for beta testers and/or airport contributors. If you would like to add a new airport, or help update existing airports, please read the Airport Format Documentation and Airport File Standards Documentation to get up to speed on what is expected in that file.

Privacy Disclosures

We use Google Analytics for gathering data about how our app is used. See Event Tracking for more information.

License

MIT License

openscope's Issues

Conflict Alerts persist after one aircraft is removed

If two aircraft are in conflict (whether warning or violation), and one is removed from the simulation, the conflict is not resolved, and will remain forever.

Originally reported in zlsa/atc#734.

Realistic flight progress strips

The flight strips are cool, but their utility (I think) is very limited. Since they are not of significant usefulness during the simulation, why not replace them with ones that are formatted the same as in the real world?

FAA Terminal-Style Flight Progress Strips:

This would resolve some other requests such as that in zlsa/atc#407 as far as exposing information that would be available to real-world controllers via the flight strip.

Procedures limited to certain aircraft types (turbojet/turboprop only)

There are often restrictions on certain procedures being "turbojet only" or "turboprop/piston only". Apparently at Dublin (EIDW), they even have different categories the aircraft are sorted into, and some procedures are limited to certain categories.

We don't need to go as far as the latter, but it seems feasible to limit the usability of certain procedures based on the content of each aircraft's AircraftInstanceModel.engines.type value to differentiate between jet and prop aircraft.

Originally reported in zlsa/atc#618.

Airport Layout Overlay

Add the ability to somehow show all runways/taxiways/buildings as an svg overlay on top of the airport. In the below reference, airport diagram pdf's were used, and the extra markings removed in order to yield the image to be used. This technique may be the most obvious, but isn't the most practical, as it is very labor intensive. May want to consider further research into how this might be achieved before taking the time to do this for all airports.

Some success was had with zlsa/atc#178.

FMS route functions errors & readbacks

Various commands related to internal fms route manipulations need to do more to provide useful feedback to the users when something doesn't work out, whether that is due to user error (mistyping fixes/procedures), using runways inappropriate for the selection procedure, a procedure improperly defined in the airport file, or for any other reason.

The time needs to be put in to figure out where exactly the giant stack of logic encountered something unexpected, and output a more useful message so the user can get some sort of information about what went wrong. Could be a problem with the airport, could be a problem with a typographical mistake, could be a problem of trying to use a procedure from a runway it doesn't apply to, etc... We should make the errors help the users understand why the command they've entered is impossible to execute properly.

There are a few spots where errors should be presented to the user, but they are merely returned and never show.

Commands where this is an issue: caf, cvs, sid, star

The following commands need to be worked on in this regard:

• runSid
• runStar
• runRoute
• runReroute
• runClearedAsFiled

It should be ensured that all possible uses of all of the above commands will:

• yield a response in the ui log
• not cause any errors in the console
• yield a red message in the ui log when it doesn't work properly

Originally reported in zlsa/atc#727, zlsa/atc#771.

Compass rose is misaligned

The compass rose displayed when an aircraft is selected is not aligned properly; it should be aligned relative to the position of the selected aircraft; instead it is relative to the airport.

Originally reported in zlsa/atc#718.

Saving and resuming gameplay

This would involve the capability of exporting the game state, and ingesting it into another simulator instance. This concept is already going to be required by multiplayer, so this and that could go relatively hand in hand.

Originally reported in #283.

Use external databases for aircraft characteristics/performance

Resources are available from eurocontrol and some other sources that could potentially be used instead of maintaining our own massive and ever-growing database of aircraft performance data. We aren't the first to want something like this, and we probably aren't the ones with the best data, so it's something to consider switching to.

Also see zlsa/atc#682.
Originally reported in zlsa/atc#298.

Adjustable Radar Update Rate

The rate at which the positions of the aircraft depicted on the scope are updated should be dependent on a user-defined value within the airport file (or eventually, the facility file, following further refactors).

Originally reported in zlsa/atc#741.

STAR landing runway transitions

In the USA, STARs can sometimes include two paths, of which the aircraft will follow depending on the runway configuration known to be in use (via listening to the ATIS), or the runway they are told to expect by air traffic control. We could inform the aircraft of the runway they could expect via #24, and then they would need to be able to fly the appropriate portion of the procedure.

Closely related to #24.
Originally reported in zlsa/atc#500.

Command for crossing restrictions

Issuing descent/speed instructions relative to a fix on an aircraft's flightplan is commonplace. For example:

"AAL482, maintain 190 knots to FINKA"
"UAL3185, cross LENDY at Flight Level 190 at 250 knots"

Adding a command that would allow for these types of instructions would do a lot for the enroute side of the simulation, whenever that comes along, and will still be very useful in the current version of the sim (especially in very large "super-TRACONs").

Closely related to #11.
Originally reported in zlsa/atc#315.

Altitude crossing restrictions already completed in #1080.

Autocomplete callsign by flight number

Select aircraft by matching a portion of the flight number (which should be globally unique). For further details, see the original bug report.

Originally reported in zlsa/atc#720.

Score controllers' efficiency

A baseline could be calculated on how long it should take for a given aircraft to land or take off. Then compare it against how long a player actually took to make it happen, and we can provide some info about how they did. Would be quite helpful from the training perspective.

Originally reported in zlsa/atc#355.

Scope Commands

There are various commands that the CONTROLLER themselves actually will enter into their scope. Includes things like:

• datablock offset direction and length
• handoffs to other controllers (see zlsa/atc#358)
• scratchpad entries

We need the ability to "toggle" between two different command bars. One that controls the simulation (airplanes), and one that allows us to manipulate our scope as a controller would. I'm thinking tab to switch between them.

Some commands will be simply typed, and others will have Q-messages (or similar) accessible through hotkeys.

---

Planned key mappings:

F1:  VCT DEC (Vector Decrease)
F2:  VCT INC (Vector Increase)
F3:  INIT TRK (Initiate Track)
F4:  DROP TRK (Drop Track)
F5:  ALT (Altitude)
F6:  RTE (Route Display)
F7:  HALO (Halo Display)
F8:  INT (Interim Altitude)
F9:  FR (Flightplan Request)
F10: PVD (Push Data Block)
F11: (none-- used for fullscreen)
F12: (none-- used for dev tools)

Simultaneous Independent Parallel Approaches

Allow for simultaneous independent parallel ILS approaches, such that they are not penalized (as if a final monitor position is staffed and simos are being conducted). Since this is an operation that is not commonly allowed, and each airport utilizing this will have to have appropriate documentation and proof that it is actually used there before allowing it to be enabled in the main repo, in order to maintain realism.

Originally reported in zlsa/atc#699.
Related: #913.

Separate "Airport" / "Facility" / "Sector"

Currently, everything that has to do with playing in a certain airspace is stored as properties of the "airport". But what about places where a single ATC facility is providing services to multiple airports? (aka just about everywhere)

Work should be done to move away from keeping things like navigational data (fixes/airways/procedures), video maps, etc under the airport, and make new classes called Facility and Sector which represents the given ATC facility and control position being simulated. For example, if I am working Miami Approach (consolidated to a single sector), I would work arrivals/departures to/from KMIA, KFLL, KOPF, KTMB, and others. My Sector within the Miami TRACON Facility has the stuff relating to my role in the simulation, and each of the airports are an Airport, which have their own runways and procedures defined within.

Here's what I'm thinking:

Facility
    └> SectorCollection
        └> Sector

In the following examples, we will use KSFO.

The Facility would be like the ATC facility we are emulating. This is NorCal Consolidated TRACON ("NCT"). It will have a collection of Sectors within SectorCollection that can be used, and will contain all information that is general to the area, but not specific to any particular sector.

The Sector will be each real-world (or simplified) sector are emulating. For example, SFO arrivals are handled by Area B of NCT, including the "Woodside", "Foster", "Boulder", "Laguna", "Niles", and "Cedar" sectors. Each has their own airspace boundaries, frequencies, etc.

In a given simulation, users can choose to work only a single sector within a given facility (perhaps Woodside, the 28L final sector), all the sectors of the facility combined simultaneously, or a combination of certain adjacent sectors (perhaps Woodside and Foster, the final sectors for the 28s).

---

And things will be divided up similar to this:

Facility:

• Fixes
• Airways
• Instrument Procedures (SID/STAR/TRXN)
• SectorCollection

Sector:

• Airspace
• Frequency, Callsign, Position Symbol
• Scope Layout
• Airports to load

Airport:

• Runways
• Taxiways
• Gates & Parking Spots

---

Originally reported in zlsa/atc#745.

Method for terrain file generation

It is not well-known how to create the GeoJSON files used for terrain data in the sim. See zlsa/atc#278.

I was able to come up with a method that would enable us to create something, in zlsa/atc#547, but it has some pitfalls.

Most notably, in cases where the terrain dips down, that is not preserved. For example, the south rim of the Grand Canyon has an elevation of about 7,000 feet. The entire grand canyon would be depicted as being 7000 feet. If we stuck a mountain in the middle that rose up above 7000MSL, it would be depicted as being of a higher elevation, but the reduced elevations would not.

For more information on the limitations of our current method, see zlsa/atc#666.

KMSP: Excessively low departure spawn rate

MSP needs to have its departure spawn patterns looked at, and the spawn rates adjusted to be more reflective of the actual traffic. They are currently set so low that there are almost no departures in the game.

Originally reported in zlsa/atc#737.

Require adequate wake turbulence separation

Require players to ensure adequate wake turbulence separation between aircraft in the simulation.

• Somehow store matrix of separation minima
  • En-trail radar separation: "following"
  • Subsequent approaches: "landing behind"
  • Time/Distance based sep for same-rwy departures
  • Time-based sep for departures when H/S departs intersecting rwy

Originally reported in zlsa/atc#326.

Illogical choice of runway

When using the taxi command without specifying a runway, the sim will sometimes make peculiar choices of runways to assign the departures, because it is using a randomized component. This should be investigated and made less bad.

Originally reported in zlsa/atc#525.

Add `*T` measuring

Using two clicks, the heading and distance between two points should be calculable and displayed to the user to aid in vectoring. In the STARS system, this is accessed via [*T (click) (click)], and in ERAM it's the "RNG BRNG" button, and click click. Need to figure out which to emulate or how else to most easily expose this functionality to the user.

Edit: this should include the ability to snap to aircraft or to a static position when no aircraft is within a specified distance. Includes aircraft to aircraft, aircraft to point, point to aircraft, and point to point.

Originally reported in zlsa/atc#740.

Overhaul KDFW

@doofus:
KDFW is in a SOUTH FLOW configuration. It would be nice to have 13L for SIDs.

Also see zlsa/atc#705.
Originally reported in zlsa/atc#735.

Flight strip bay scrollbar styling not applied in FF/IE/Edge

In Firefox ,Internet Explorer and MS Edge, the flight strip bay has an ugly scrollbar instead of the one intended. Works in Chrome, which is the recommended browser for many reasons. Nonetheless, it should probably be addressed somehow.

Originally reported in zlsa/atc#471.

Poor Localizer Interception

Aircraft intercepting the localizer is very clunky; the turns are not smooth, and frequently overcompensate. The math for the turn calculations needs to be improved and simplified (so it is more clear how it works).

Also see zlsa/atc#711, n8rzz/atc#66, n8rzz/atc#86

Originally reported in zlsa/atc#717.

Erroneously alphanumeric callsigns

Example file that is shown with alphanumeric flight numbers, and shouldn't have them (bad):

{
  "icao": "JBU",
  "name": "JetBlue",
  "callsign": {
    "name": "JetBlue",
    "length": 3,
    "alpha": false
  },
  "fleets": {
    "default": [
       ["A320", 130],
       ["A321", 27 ],
       ["E190", 60 ]
    ]
  }
}

Example of one that doesn't have alphanumeric flight numbers, and shouldn't have them (good):

{
  "name": "FedEx Express",
  "callsign": {
    "name": "Fedex",
    "length": 4
  },
  "fleets": {
    "default": [
      ["A306", 68 ],
      ["A310", 8  ],
      ["B752", 119],
      ["B763", 32 ],
      ["B77L", 32 ],
      ["DC10", 49 ], 
      ["MD11", 58 ]
    ],
    "feeder": [
      ["C208", 241],
      ["AT43", 26 ],
      ["AT72", 21 ]
    ]
  }
}

---

@n8rzz:
@erikquinn likely due to this line in the AirlineModel: this.flightNumberGeneration.alpha = _has(data, 'callsign.alpha');

Originally reported in zlsa/atc#748.

SpeechSynthesis not working on chromebook

The voice that reads back commands given to aircraft is not working on chromebooks. It's unclear whether or not perhaps the speech synthesis api (external) is not compatible with chrome on chromebooks. It is known to work on Chrome and Safari on full desktop machines.

Originally reported in zlsa/atc#758.

Add "transition" procedures

Add transition command to assign aircraft to clear them out of the hold at the end of a STAR (when applicable). This is something that is used in the majority of european air traffic control, but is not present in the United States.

Also see zlsa/atc#577, zlsa/atc#500.
Originally reported in zlsa/atc#652.

Scaling Traffic Volume

Present a slider-based UI that enables users to scale the volume of traffic being spawned, by category (arrival/departure/overflight), as well as per each spawnPattern (in order to have control over WHERE the aircraft are going to or coming from) in order to achieve various goals in skill enhancement exercises.

Also see zlsa/atc#306, zlsa/atc#677.
Originally reported in zlsa/atc#374.

Documentation & Charts

Some background information should be made available for each airport, in order for users to have access to the diagrams, explanations, and information required to understand how to effectively work in that particular airspace. This would be achieved through *.md files, as well as links to further readings, and charts, etc.

Originally reported in zlsa/atc#672.

Support for non-US keyboard layouts

Various issues have been encountered with use of hotkeys with users who don't use the US-QWERTY keyboard layout. Some effort should be made to ensure things still work with some other common layouts, like german, spanish, etc.

Originally reported in zlsa/atc#336.

Using runways not valid for assigned procedure causes crash

When either of the following are true:

• taxiing a departure to a runway, and then assigning them a SID that is not valid
• an aircraft is expecting to land on runway A, and is assigned a STAR only valid for runway B

...the game will crash.

Originally reported in zlsa/atc#573, zlsa/atc#519, zlsa/atc#580.

Scaling Traffic Volume/user specified spawnPattern rates

Present a slider-based UI that enables users to scale the rate at which traffic is being spawned; both by category (arrival/departure/overflight), as well as per each spawnPattern (in order to have control over WHERE the aircraft are going to or coming from) in order to achieve various goals in skill enhancement exercises. I'd love for them to be exposed in the UI with hierarchy, such that we can drag up and down "arrivals" / "departures", or I can expand those and scale up/down each spawnPattern individually for further customization of traffic.

@sixeyeco had some nice mockups: "options" and "options as a popup"

Also see zlsa/atc#306, zlsa/atc#677.
Originally reported in zlsa/atc#374.

Visual Approaches

Charted instrument approaches (see #2) are great and everything, but also great is the ability to clear aircraft for a visual approach to a given runway (or the runway of their choice if an uncontrolled airport) from any relative position, and have them enter the traffic pattern, and guide themselves to land in a realistic manner.

Command for delayed instructions untill passing a fix

This involves giving an instruction that the pilot is expected to execute AFTER passing a specified position (whether a fix, a distance from a fix, etc).

"KAP515, depart BOWAN heading 360, vector visual approach runway 28"

In this example, the aircraft should continue direct to BOWAN, and then fly heading 360. You can also apply altiudes and speeds:

"KAP515, depart BOWAN heading 360, then descend and maintain 3000 and reduce speed to 230, vector visual approach runway 28"

Closely related to #10.
Originally reported in zlsa/atc#315.

Command to inform arrivals of the arrival runway to expect

Need a command we can use to inform an aircraft of what runway they can expect for arrival. This would be used primarily to help them determine which branches of a given STAR they should be following, as there are often different paths to follow in the chart based on the runway they are to land on.

See zlsa/atc#500.

Command bar cursor not at end of line in MS Edge

The cursor should be at the end of the line, but in Microsoft Edge, it is at the far left instead.

Originally reported in zlsa/atc#489.

Also, per duplicate issue #1438, clicking aircraft will sometimes not put the command bar in focus, meaning the first keystroke is not shown in the command bar.

Score Summary

Some basic interface to show the user how they earned/lost points that results in their current score would be helpful. I'm thinking maybe hovering on the score would bring up a transparent thing with the appropriate events, and the subtotals of points from that category?

Originally reported under zlsa/atc#56.

Actually USE the suffixes of procedures

Given a procedure ANKER, users should be able to enter SID ANKER1Q and/or STAR ANKER1Q, depending on the type of procedure. Such was the intent of the suffix property, but it was never really fully hooked up, and airport creators have worked around it by creating individual procedures PIK27X, PIK27D, PIK23X, PIK23D, PIK21X, PIK21D, etc. Completing the functionality of the suffixes would eliminate the need for them to do this.

Originally reported in zlsa/atc#655.

Command Reference

Particularly as we get more and more commands, it would be nice to have a way to see a reference sheet that would remind you the parameters required under each command while in-game.

Idea from @sam-irl was an autocomplete-esque thing where the text box would show in faint color the arguments available for the given command (such as typing AAL123 turn and after that it showing a faint [L/R] [magnetic heading] to clue people in on what the parmeters are for the turn command).

Ideally, a full solution to this issue would include both the above behavior in the text box as well as a list of commands that users can show/hide when they need to see what commands are available, what the differences are, etc.

Originally reported in zlsa/atc#463.

Add capability for holds in procedures

SIDs/STARs/IAPs will often include vectors, with the intent of controllers assigning headings to get them to the next phase of their flight. And in Europe, most STARs will actually begin with a holding pattern; if the aircraft does not receive the clearances in time, they will automatically enter the holding pattern.

The ability to add these into procedures in the airport files would enable us to close a big gap in realism with these procedures.

Originally reported in zlsa/atc#439.

---

Related: #120.
Blocked by #193.

Minor variations in wind

Some degree of variation in the wind would be nice and realistic, rather than it being static, as defined in the airport's json file. The variations would be minor, but ranging in direction maybe 30 degrees, and in velocity about +/- 5 knots. Would add a nice bit of variety when takeoff clearances are read back, and generally make it feel more realistic.

Related: zlsa/atc#68.

Fly-over vs fly-by fixes

Allow for differentiation between fixes that must be flown over before beginning turn or not, as there are some instances where it can make a difference.

Originally reported in zlsa/atc#427.

Improve VNAV glidepath calculations

Right now, aircraft just descend to the altitude required by their next waypoint. They should be able to look further forward than just the next fix, and also calculate a smooth, constant rate descent rather than descending at full speed, leveling off, etc.

Related: #239.
Originally reported in zlsa/atc#654.

Adopt Gnomonic Projection

ATC scopes use gonomonic projection (see this link for details). In this style of map projection, all great circle tracks are depicted as straight lines, which is what we want.

Originally reported in zlsa/atc#746.

Airport Guide

Some background information should be made available for each airport, in order for users to have access to the diagrams, explanations, limitations on procedures, airspace boundaries, and other information required to understand how to effectively work in that particular airspace. This would be achieved through *.md files, as well as links to further readings, and charts, etc.

Additionally, each page should contain some links to relevant charts, diagrams, etc.

Related: #35.
Originally reported in zlsa/atc#612.

Runway Configuration Selection

Give user the ability to specify the active or primary runway(s) for departures, such that a taxi command with no runway specified sends the aircraft to the runway being utilized for departures. Some thought needs to be put in to whether this would be adequately achieved through manual means by the user, or if some conditions could also be set in the airport file (such as "when the winds are this, depart these runways").

---

Originally reported in zlsa/atc#658.
Related: #374.

Scope display profiles

Different profiles for scope colors, fonts, etc should be established in order to provide different themes that emulate the different radar systems used (STARS, ARTS, DSR/Host, ERAM, europe-things-i-don't-know-about).

Example items to be defined in a scope display profile (not all will be included in initial work):

• brightness of aircraft targets, data blocks, control symbols
• brightness of background color
• brightness and radius of range rings
• brightness of video map markings
• center of range rings
• default direction of data block leader lines
• default length of data block leader lines
• default length of PTLs

Related: zlsa/atc#371, zlsa/atc#395, n8rzz/atc#76.
Blocks: #115.
Originally reported in zlsa/atc#716.

Instrument Approaches

Instrument Approach Procedures (IAPs) should be added. They can be treated essentially the exact same as a STAR: a procedure that has an entryPoint, and a bunch of navigation instructions (fixes/altitudes/speeds), and ends at a runway.

Examples of different types that would be supported include ILS, RNAV, GPS, LDA, VOR, NDB and charted visual approaches (looking at you, River Visual 19 into KDCA!). Nothing would be different for our purposes in the codebase; they can all just be lists of fixes and whatnot, that come from the associated approach plate ("chart").

Also see #3 regarding visual approaches.

Originally reported under zlsa/atc#59 and zlsa/atc#653.

Multiplayer

Too big a topic for a single issue, but I'll add this here as a place to store the appropriate references for now.

See zlsa/atc#359, zlsa/atc#392.

Aircraft should be consistent with filed exitPoint when assigned a SID

Following work on spawnPatterns, this won't be a factor until the ability to randomly select an exitPoint of the SID is reestablished. At that point, we need to ensure that the exitPoint selected is always the same for a given aircraft, regardless of how many times we re-assign the SID.

Originally reported in zlsa/atc#632.