Openscope: Update scope-commands.md

[felixscheffer]

scope-commands.md refers to commands that are not implemented yet.

We should

1. check if we still intend to implement them
2. if not, remove the text from scope-commands.md
3. if so, create an issues on GitHub for each command

The commands:

• [x] Toggle halo
• [x] Set Scratch Pad
• [ ] Propogate Data Block (and Point Out)
• [ ] Display Route
• [ ] Initiate Handoff
• [ ] Amend Altitude
• [x] Accept Handoff

@erikquinn

[felixscheffer]

@erikquinn @n8rzz
how do you feel about adding handoff code for arrivals? The basic idea is that we automatically initiated the handoff process and the user has to accept the aircraft before he is allowed to control it. And maybe in a second step, we could add the ability to amend the altitude. It's not super sophisticated but hopefully gets us closer to a proper handoff system.

[erikquinn]

The first part we can do. But it has to be at least slightly complicated:

• We need to show track ownership so you can see when an a/c is owned by you, in handoff status to you, in handoff status from you, or is owned by someone else. This includes flashing of the data block and position symbols (a letter over the radar target)
• We need to ensure that commands (both aircraft and scope commands) are disabled when you do not have track control (when you have not yet accepted the handoff)
• We need to have the aircraft check in only after accepting the handoff (preferably about 5-10 seconds afterwards)

That would basically be the bare minimum to get it going temporarily without waiting to properly set up Sector/Facility/User stuff.

[felixscheffer]

@erikquinn Do we still need toggle halo? Is this the same as #1032?

[n8rzz]

@felixscheffer to answer your initial question, I love the idea! It's been something we've wanted to do for a long time. I see you've added an initial issue for this, awesome! I think what we'll want to do from there is create an epic in Zube (I'll be doing that tonight) and then start filling out the requirements and actionable stories. I fell like this, if done with some thought, could be doable relatively quickly. But, on the other side, I would like for us to take out time and think about all the things on this one so we are setup for success in the future. I don't want to be tied to an implementation that backs us into a corner.

[erikquinn]

The 3-bullet bit above shouldn't back us into a corner, it'll be quite minimal to backtrack I think.

@felixscheffer The halo is _very_ different from the range rings linked in #1032:

It's used to judge separation, most often in conjunction with PTLs involving crossing traffic. So if you've ever heard the phrase "bubble scraper", this is the bubble they're talking about :wink:

[felixscheffer]

@erikquinn Okay, now I get it. Thanks for clarifying. My understanding is that we already show halos when aircrafts get close to each other.

So with halo 'on', we would constantly show the circle around the aircraft?
And with halo 'off', we would never render the circle even when there is a separation violation?
The radius would be defined in the airport file?

[erikquinn]

With a halo "on", it is showed regardless. When it's off, irl, it is never shown.

The issue is that we show a dim halo when two aircraft are "in conflict", when that is actually shown by flashing irl. The change to a flash during conflict doesn't need to happen now, but one important distinction is that the halo turned on by the user should be fairly bright (much brighter than the current "conflict halo" currently appears). So the answer to your second question is that the two are unrelated.

The radius should be definable in a _scope command_:
HALO draws a 3nm ring (or removes it if one is present)
HALO 5 draws a 5nm ring
...etc. If an aircraft has a ring of one dimension and receives a command specifying a new dimension, the old halo is replaced with the new one.

See #14 for the planned key mappings for these commands as well.