openscope
openscope copied to clipboard
openscope
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.
@erikquinn I'm just gravedigging a little to see what has been discussed before, sorry about that...
A problem that needs to be discussed is spawnPatterns. Every playable sector (and combination of sectors) would need to have their own spawnPatterns to simulate controllers of adjacent sectors transferring aircraft to the player in a believable way.
Maybe the problem can be solved by introducing a new concept for each sector called flowPattern (or another better name), which specifies how an "AI" controller should make traffic flow through their sector and into the adjacent sectors.
Another cool thing that would come from this (the issue as a whole, not my discussion) is that it enables the addition of automatic or manual (selectable?) "[callsign], contact [ATC callsign] on [frequency], bye!" when aircraft are leaving a sector.
Now that would be awesome!
I'd be interested to see what this sort of thing could look like. Work up a plan and lets go from there, nothing here is really set in stone so if you have ideas for a path forward by all means present them!
Now that would be awesome!
I'd be interested to see what this sort of thing could look like. Work up a plan and lets go from there, nothing here is really set in stone so if you have ideas for a path forward by all means present them!
I don't think I understand the sim as a whole good enough to make any good design proposals yet. I think I'd better try some smaller issues first to get used to the design, and maybe revisit this later.
For now, think of the above as me just throwing some ideas around to spark discussion.
@erikquinn This would be fun to work on. The big problem I see is that it would require updating/refactoring all existing airport files. Is there a preferred strategy for rolling out this sort of breaking change?
Short of adding tests for new work and verifying existing (and still needed) tests continue to pass, no. Historically we've used a long running feature branch that we deploy by itself so we can test it in an env
In short, we just disable the airports it breaks if we can't get them all compatible with the change. Would love to avoid it, but sometimes you can't!
This is a HUGE one with a lot of nuances that will need to be done in a very specific way to avoid trapping our future selves into corners. So if you plan to try it, be ready for weeks of intense collaboration! 😜
In short, we just disable the airports it breaks if we can't get them all compatible with the change. Would love to avoid it, but sometimes you can't!
This is a HUGE one with a lot of nuances that will need to be done in a very specific way to avoid trapping our future selves into corners. So if you plan to try it, be ready for weeks of intense collaboration! 😜
I'm game... where is the best place to have a discussion? This issue? or Slack? I am initially trying to think of how I might break it down into smaller things. It seems their may be some prequisites that might need to be taken care of first. I think stepping up to handling a single combined sector with multiple airports is doable. Going the extra step to supporting multiple sectors, or playing as only a single sector like final would require some better handling of aircraft prior to entering the airspace. So some kind of pseudo-controller that handles adjacent sectors that feed in. I think there may be an existing issue for that, I'll have to look for it, that might be a good place to start.
Before starting, here is good. Once work starts, should open a PR while it's a wip, and collaborate there. 😃