Airways, Legs, Rerouting, & So Much More

[erikquinn]

This is finally pretty much ready to go!

Includes a lot of back-end work to improve the way the fms handles route logic, so that routes can be manipulated in a way that is similar to real flight management systems, thus making it easier to achieve more complex routing operations, moving things around, and just overall enabling us to achieve a higher level of capability.

Basically, here's the jist of what happened to the fms:

The current fms is set up to navigate between "waypoints", which are manually created objects, not associated with a particular class, that are made in the fms's addWaypoint() member function. You can add a whole bunch of these waypoints to the fms, and it will tell the aircraft to aim to each waypoint. As it passes each one, that waypoint is removed from the fms, and the others shift over, and the a/c goes to the next one. The process repeats until no waypoints remain, and then the aircraft will pass through the last waypoint and maintain its altitude/speed/heading when it passed its last waypoint.
In this proposed pull request, the fms has a modifiable flight plan route, which has corresponding "legs" that tell the fms where to steer the airplane. Each leg contains a series of waypoints. The purpose of doing it this way is to condense and clearly group together waypoints when they are part of an instrument procedure; for example, a SID or STAR will be maybe 5-10 fixes long, and may have specific altitude/speed limitations at each fix. By having these 5-10 waypoints contained within a Leg, you can clearly differentiate these fixes from the rest in the fms. If you wish to change to a different SID (perhaps because the one the aircraft had filed for is invalid from the runway you've taxiied them to), and all the waypoints were just loose in the fms, you wouldn't know which ones (or how many) to remove. Here, you just find the route that has route.type == "sid", and replace it with a new leg, as simply as saying fms.insertLegHere(new zlsa.atc.Leg({type: "sid", route: "KSFO.MOLEN7.ENI"}));. Boom. The existing logic builds EVERYTHING else for you, as long as MOLEN7 is a valid SID at KSFO, and ENI is a valid transition of that SID. If not, it'll throw an error and let you know the route is invalid. This is a better way to handle is because you can add/remove things easier, and better recognize when an aircraft is able to climb/descend via a SID/STAR, or whether they are on an airway, etc, which can be useful in many other applications.

In Reference to Active Issues:

• Resolves Taxi/Wait puts flights on the runway causing incursions/collisions.  #350, via making a/c on ground invincible to all collisions (temporary solution)
• Resolves Airways #461, by adding capability to parse, understand, use, and manipulate routes to accommodate airways
• Resolves Aircraft taxiing to runways not approved by SID #430, by moving the departure runway member variable from fms to Aircraft
• Enables us to easily add a fix for Instrument Procedures with Vectors & Holds #439.
• Enables us to easily add a fix for Issuing a "heading" command after "fix" (vice versa)? #379.
• Enables us to easily add a fix for Previewing/Showing list of assigned fixes in strip #407, and partially addresses the topics discussed by adding a sr command, for "say route"

Technical Changes:

• Added class zlsa.atc.Waypoint, based on old waypoint format
• Added class zlsa.atc.Leg, which is a functional part of the flightplan route, and contains a series of Waypoint objects
• Set up straightforward framework for stuff like vector/RNAV hybrid SIDs (Instrument Procedures with Vectors & Holds #439), departing/crossing fixes on certain headings or at certain speeds (Issuing a "heading" command after "fix" (vice versa)? #379, Further supported behaviors for waypoints #315)
• Fixed math error with offset calculations (used to be member fxn of Runway. now in util.js and set up to be more abstracted and versatile (this could help runway intercept weirdness and lays groundwork for intercepting radials or airways as if they were ILS localizers)

Notable Features/Changes Included:

• route, rr ("reroute"), and sr ("say route") commands
• Taxi time set to 3 seconds, and aircraft in the queue no longer are waiting around for days if you taxiied a bunch back to back. As long as each has had their 3 seconds, they will appear on the runway as soon as the departure ahead of them takes off. Note: All conflicts/crashes disabled while on ground (temporary fix).
• removed proceed command, as it is made moot by introduction of the more powerful and real-world accurate methods of rerouting aircraft via route or rr (reroute) commands

---

I have tested it pretty thoroughly, and continue finding small things that have broken, and I am sure there are more, but nothing that will hinder the gameplay, and nothing that can't be very easily fixed... It's just tough to track down them all, and I think I have just about everything running properly. There may be issues with something like rerouting, then assigning a fix, then clearing for an approach, then adding a hold (or something crazy like that that I didn't test), but I'm sure we will come across any such issues eventually if they exist, and we can deal with them then. This should be a really big step forward though, and enable some really cool stuff.

Testing on this is appreciated; let me know if you find anything broken!

Airways available in demo (not included in this PR) include:
"V87": ["POPES", "SGD", "REBAS", "SFO", "OSI", "SANTY", "MOVER", "SNS"]
"V107": ["BOARS", "PYE", "MICRA", "COMMO", "OAK", "DECOT", "IMPLY", "MISON", "MABRY", "VINCO", "CATHE", "PXN"]

Note: Aircraft can be made to follow airways via the route command, which adds a new Leg. Format your input with single-dots for airways, or double-dots for fixes. Alternatively, do rr instead of route to replace the aircraft's route entirely with a route of your own making (same format). An example of proper route format is KSFO.OFFSH9.SXC.V458.IPL.J2.JCT..LLO..ACT..KACT

Testing: erikquinn.github.io/atc/b/airways

[erikquinn]

Anybody have a chance to play around with this? When it is merged, it will open a bunch of doors for things that can be improved/fixed, but I don't want to merge it until there is a consensus and it is certain that it doesn't break anything for anyone. I've tested it thoroughly myself obviously, but still would like a confirmation, because it is quite a big change... I have a few items on my list of things to do next but work on them cannot begin until this goes in. Anybody willing to try to break it? 🔨 🔥 💻

[Fechulo]

I'm a bit confused. At the moment, what is the use of airways for a player? I understand they will be extremely useful if we have a center control, but right now, the player should be happy by just routing the aircraft via the sid's. Am I missing anything? What exactly would you like me to test?

[erikquinn]

Correct, it doesn't really make a difference at this stage, but in addition to adding capability for airways, it reworks the fms in a way that could break just about every single individual thing. I'm just looking for a few people to verify that whatever they usually do at their usual airport of choice has not been broken by anything in here. All I really need is to make sure it looks like NOTHING has changed to the user. No need to go in-depth with each function, as I've tested all of them thoroughly. It's just that when I get in that mindset, I'll rarely miss a small detail, but (believe it or not) I could easily overlook something like "when you clear somebody for an approach and then change the speed, the game crashes".

So I am just looking for a verification that nothing totally obvious is totally broken, because otherwise this change shouldn't make the slightest difference to the users.

[Fechulo]

Thanks, I understand now. I'll definitely take a look at it and tell you if I find anything.

[erikquinn]

@Fechulo Thank you!! 😄

[Fechulo]

First bug: In some airports (most noticeable in EGLL) the arrival aircraft spawned at the start of the session will try to go back to the first waypoint in the STAR, instead of flying directly to the closest waypoint. It can be easily seen if the aircraft projected path is set to show always.

[Alpi-no]

So based on this can we program stars?

[erikquinn]

@jakobeng1303 Not yet, this just makes it easy to add logic for stars. They will work with EXACTLY the same format as SIDs, so if you were getting anxious you could always have a look at a few SIDs, and get some STARs ready for your favorite airport(s). I suspect it will be 7 days or less until we can do stars AND hybrid RNAV SIDs (aka 'vector departures')

[Alpi-no]

Nice! I will check out the data format and get some ready!

[erikquinn]

@Fechulo is that the only issue you've encountered? Just FYI, I'm targeting tomorrow afternoon (~2000z) for merging this if no other bad stuff is found, so stuff like STARs can start getting some attention.

[Fechulo]

I'll do some more testing now, but I haven't found anything else.

[Fechulo]

I found another bug, Instead of explaining it, here's a video! (it should be HD in a few minutes)

[erikquinn]

@Fechulo Thanks for the video, it's super helpful! In fact, I actually decided to follow suit to show the slightly different intended workflow that would avoid this issue, and it's one I wasn't seeing because I was playing differently... I'll have a look at the bug and get it fixed.

Here's an explanation and demo of the intended way to achieve the control instructions you were giving.

[Fechulo]

Thanks, I wrongly assumed the aircraft wouldn't remember their original route so that's why I gave them the fix command.

Regarding the 10 dme arch numbers, they are just the number in the 10 dme arch, not a heading. I basically paste the coordinates for the entire arch, number them from 1 to 200 (or however many coordinates there are) and then I delete the ones I don't need. Instead of renumbering them I just leave them like that, resulting in nonsensical numbers. This "behavior" of mine can also be seen in EDDT.

As soon as I get back home tomorrow (~1700z) I'll do some more testing. I'm really looking forward to this being merged and expanded.

[erikquinn]

Fixed the issue with the fix command in 11cdb27. It apparently wasn't that there was no altitude at the previous waypoint, it was as simple as the currentWaypoint() function returning null because fms.current was not updated correctly after inserting a leg before the current one, which resulted in an out-of-range error if the aircraft was at the (n+1)th waypoint of the original leg if the inserted leg had n waypoints or fewer.

[Alpi-no]

@erikquinn can I add the stars now?

[erikquinn]

@jakobeng1303 Not quite yet, the sim still doesn't know what a STAR is. This pull only changed some things about the way the fms thinks. Now that it is a little smarter, we can teach it to read STARs in a matter of a few hours work, which is forthcoming. I'll create an issue to track the progress on that.

[Alpi-no]

@erikquinn Ah now I think I got it :D