Planning ahead for retiring VRC

[Gunnar Lindahl]

VRC has been a stalwart of the VATSIM community for many years and I fondly remember doing all my training with it. Thanks Ross for making it such a fundamental part of the network.

I still use VRC to supervise on the network and will continue to do so until the very end!

[Dave Mayes]

I too couldn't agree with Ryan more.  I am here for the total enjoyment of "THE GAME".  Moving on to a radar client that would require a lot of training to become proficient at being an "real world" type atc controller, is not my idea of having fun.  My opinion is the KISS rule.  Having said all of that, I would be remiss in not thanking Ross for all his time and dedication to our community.

[Alistair Thomson]

25 minutes ago, Dave Mayes said:

I am here for the total enjoyment of "THE GAME".

Total enjoyment, yes. Game, no, if that implies that we don't need to take VATSIM seriously. I think that taking it seriously involves a lot of learning.

[Ross Carlson]

2 hours ago, Dave Mayes said:

Moving on to a radar client that would require a lot of training to become proficient at being an "real world" type atc controller, is not my idea of having fun.

I don't want people to get the wrong idea from this thread. vSTARS and vERAM have a little bit steeper learning curve, but it's not like riding a tricycle versus flying the space shuttle. If you can do VRC, you can do vSTARS and vERAM with just a tad more effort learning the command syntax. Many of the F-keys are the same. The main thing is that you don't have the convenience of the right-click dropdown, and that's something I might even add to the "tower cab mode" if that's the way things move forward.

[Isaac Tan]

On 5/8/2021 at 8:01 PM, Gunnar Lindahl said:

VRC has been a stalwart of the VATSIM community for many years and I fondly remember doing all my training with it. Thanks Ross for making it such a fundamental part of the network.

I still use VRC to supervise on the network and will continue to do so until the very end!

I couldn't agree more. It has and always be a charm for supervisor duties! 🙂

[Gerardo Rodriguez]

One thing I would like to add is that VRC gives members (more specifically on events) the ability to load in Sector Files from other ARTCCs to be efficient at traffic management (TMU). I have a VRC profile that utilizes all of my 3 screens with the layouts of airports inside/outside my ARTCC which are important when I'm on that role which vERAM wouldn't allow me to. The ability to look at untracked planes and see their full flightplans is extremely helpful as well. When running training sessions on TwrTrainer or EuroScope I always have VRC open just because it simplifies my life. 

 

Don't get me wrong, I tasted vSTARS and vERAM and I hate controlling on VRC for terminal and above, but I still love the simplicity of running cab on VRC. There's so much that it's still used for that I don't feel it should be "thrown to the trash". I understand if it's not worth it to be further developed, but at least leaving it for non-active-controlling functions it's fine with me. 

[Patrik Yngver]

I've had many, many fun hours in VRC and it is where I learned the ATC gig for VATSIM! We have now moved to primarily EuroScope over here, but a big thank you to you Ross for creating and maintaining a software that has lived this long!

[Owen Wang]

On 5/2/2021 at 9:34 PM, Cian Ormond said:

(also linux support lol, owen would agree with me, it's the only client i can't get to work)

Yes! If you can get both Linux and MacOS support that would be wonderful! I bet there are many people out there who can't control just because they aren't using Windows. This is especially for MacOS users.

[Ross Carlson]

31 minutes ago, Owen Wang said:

Yes! If you can get both Linux and MacOS support that would be wonderful! I bet there are many people out there who can't control just because they aren't using Windows. This is especially for MacOS users.

It is highly unlikely that I will make a cross-platform client. vSTARS and vERAM are very much tightly integrated with Windows as far as the UI is concerned, so it would require a complete rewrite of the UI using a cross-platform UI toolkit. Plus, I have no Mac to test on, and no desire to own one. 

I will leave it to other developers to make a Mac client.

[Charan Kumar]

Have spent the better part of the last decade on VRC, still my go to client. While it mayve unrealistic, and I can totally relate, as a casual hobbyist, I prefer the use of a mouse, especially for the topndown  we do here on VATSIM.
enroute only, I use vERAM, high traffic between only a couple of airports, or low traffic at local, I use Euroscope top down and a couple windows, high, traffic full ARTCC, I switch to VRC, like finisher in the events, I gotta use VRC. Respect to those who t able to do that on vERAM.

 

Totally respect the decision to retire clients and maintain less, and as a software developer, it makes perfect sense to not go back and fix something that old, when newer  tech is available. If vERAM had mouse capability tho, I might not miss VRC much. Really that’s the only thing stopping me from going full time to vERAM, at the moment. 
 

A huge thanks to you Ross, for all the clients, the continued support, and the future mods u r already planning. 
 

cheers!!!

[Tim Simpson]

Most ARTCC's don't allow new controllers to learn with vERAM because of its complexity.  Ending support for VRC, raises just one more barrier in front of people that are considering controlling.  

[Brad Littlejohn]

17 hours ago, Owen Wang said:

Yes! If you can get both Linux and MacOS support that would be wonderful! I bet there are many people out there who can't control just because they aren't using Windows. This is especially for MacOS users.

With some workarounds, I am able to control with VRC on a Mac. Now granted that I am working on what will be a 10-year old Mac (I'm holding out for the next M-series), it's stil a Mac and works. 

Initially to get back into them, I built a Hackintosh out of old leftover parts I had from tearing down my Linux box (I had been on a Linux box for all personal work and a separate Windows box for ATC/simming for a good 10 years prior to doing this) just to try it out, then went all in and bought a Macbook Air. While Bootcamp works, if I wanted to dual boot a full copy of Windows, I'd have just built a box and dual booted. Plus, I'd have to eat the cost of an additional windows license. Same with Parallels. I also didn't want to run a VM, which would have been the same issue. So instead I went with CrossOver, which allows me to run VRC natively on MacOS. It still works to this day.

 

It looks like the latest version supports Apple Silicon, so I wouldn't be surprised if VRC works there as well. I don't see anything listed for compatibility for vERAM or vSTARS (but then again, I don't know if they have been tested). But there are avenues for that if an ATC client isn't developed natively for the Mac.

BL.

[Eric Oosting]

There is alot of this conversation that seems to boil down to "if you don't use one of the more realistic tools, why are you even here?" ... people can recognize that this is a simulation, prefer one tool over another, and be extremely serious about the services they provide at the same time. What tools people use to maintain that goal is up to them.

Kyle, it is fantastic that you've had good luck teaching new controllers to step directly into vSTARS and vERAM. This is your experience, and we can use it as an existence proof that it is possible. Maybe more mentors and trainers will take this step, but it's no less valid to teach VRC to new student controllers.

I'm sure it is not your goal to suggest that students using VRC are by definition less capable, or that mentors and instructors that choose to teach VRC to new students are incorrect in their choice, but your words are sort of coming off as an indictment of committed and serious controllers and students, people who in part make this platform amazing, because they don't control exactly like you do. Again, I don't think this is your intention, but this is how it's coming off.

I'd like to reinforce that imo:

1) while it's important to maintain realism, vSTARS and vERAM in the twr/gnd/del positions would actually be a departure from realism. So before we get in some battle over precision, recognize that fidelity in the cab is a challenge were a new tool to be written or existing tools extended to support what is essentially a non-realistic mode of operation.

2) It's important to support how many students learn and become aquatinted with the network, and also how many mentors and instructors want to train on the network. While it's demonstrably possible to jump into vSTARS and vERAM, it's the preference of many students, mentors, and instructors to utilize VRC today.

3) A huge portion of this network is built on the back of supervisors and other individuals that need to flit around the network monitoring and checking up on operations and flow. Many use VRC for this today, so it is desirable to try to support these modes of operation for the good of the network.

Ross, I'm new here, but I'm impressed with your dedication to the community. Thank you for your contributions. I personally value your time and future efforts to maintain and improve the tools and deeply appreciate the decisions and tradeoffs you're faced with. I've heard it said that he or she who writes the code generally gets their way. But that is a double edged sword. And I recognize that you do not have unlimited efforts to support unlimited tools.

Whatever choice you make, whatever tradeoffs you take, you will have my full support, and the full support of the community. 

[Kyle Sanders]

1 hour ago, Eric Oosting said:

Kyle, it is fantastic that you've had good luck teaching new controllers to step directly into vSTARS and vERAM. This is your experience, and we can use it as an existence proof that it is possible. Maybe more mentors and trainers will take this step, but it's no less valid to teach VRC to new student controllers.

I'm sure it is not your goal to suggest that students using VRC are by definition less capable, or that mentors and instructors that choose to teach VRC to new students are incorrect in their choice, but your words are sort of coming off as an indictment of committed and serious controllers and students, people who in part make this platform amazing, because they don't control exactly like you do. Again, I don't think this is your intention, but this is how it's coming off.

Eric, you may be right.

I would like to apologize to all if my comments were at all leading to the fact that I think if you are using an unrealistic software that you are "less capable" of being a skilled ATC.
However, I believe I have made it perfectly clear throughout this thread that I don't think that, as I have even made mention a couple times about how I have used VRC for almost 10 years and just recently switched, and I would like to think my skills as an ATC are at least 'OK'.

To comment on the Supervisor use of VRC, it is my understanding that VATSYS has a really great UI for Sups. I may be wrong but what is wrong with that software? Same with TMU type stuff... ES and VatSYS seem to do just fine with these positions.

 

Let me reclarify all of my responses and make sure my intent is clear:

 

On 5/2/2021 at 10:28 PM, Ryan Parry said:

I do not like using vSTARS and vERAM in their current form, I'm not after the most realistic environment. I have no ambition to be a real controller, I do it on this network as a hobby for entertainment. While I understand the desire to trim the fat from the projects you maintain, this also feels like a move that says we either have to be uber realistic or gtfo. For me, if the mentioned changes to the clients don't mimic VRC enough, I'm unfortunately out. I really wish VRC would just be open sourced, but I know that's been shot down in the past.

  "UBER REALISTIC" is NOT what these software are. There is a long road ahead before I would consider them to be "UBER REALISTIC" and I would even caution Ross from trying to attempt that level of realism at all. You can do SO MUCH in vERAM (going to use vERAM as my frame of reference for any future discussions) that you can do in VRC and most of the time, you can use the SAME F-KEY shortcut to do it. Do you have to read the manual?-Yes... does it require about 30min of sweatbox time to get use to the SLIGHTLY new syntax?-yes. It is worth the move... trust me.

 

On 5/2/2021 at 10:28 PM, Ryan Parry said:

As far as VRC features to move to vSTARS/vERAM, give me right click-ability (I just made all the vSTARS/vERAM guys puke a little 😄) and the ability to change the colors in client. I'm not vision impaired, but over the years I've met a number of people who struggle to use these newer clients because they are. VRC gives them the ability to set things to colors they can see, I'd hate for them to be alienated off the network because they can't see everything on the radar. It'd be nice to have *T a double click like the ruler tool in VRC.

Right-Clicking is a feature in Real World that is often used to assign speeds, altitude temps, etc... I would welcome these type of right-clicks but in the same format as RW instead of the game-like mode they are in VRC.
Changing colors is also a feature we could use but again, they have it in RW. Ryan-you are making a case to make it more realistic lol.
The Ruler argument... IDK... how often are you really needing to use this? Don't you have RVMs with 1 mile dashes all over the place for reference? The Ruler function is a real world tool but it isn't needed all the time because you have reference points all over the place, which one reason that a quick Double-Click really isn't needed.

 

On 5/3/2021 at 10:40 AM, Ryan Parry said:

Personally speaking, I have zero desire to use the current version of these clients because it is more complex than I want to be. In my opinion it was fine for them to be more realistic because VRC existed for those not wanting that, but with the eventual retirement of VRC those people are left out in the cold.

I opened up vSTARS to remind myself what I do and do not like, and a few more things came to mind. I do not like that everything is done through some sort of key command, string of characters, or combinations of key commands. Of course it is useful to use key commands when working traffic, but it is the other things not related to working traffic that make it cumbersome. I need a key command just to move the various lists on the screen, a simple hold control and drag with the mouse makes it easier.

The maps button shows a limited amount of maps I can toggle (which is fine), but when somebody loads in more than what can be shown I have to use yet another macro to enable and disable a map (the NCT file has 100+ maps in it). I think it would be nice if we could click the GEO MAPS button and then scroll down the list and click the one we want, instead of using the map id and a command. I know, none of that is realistic, but refer back to the easy mode in the options. 

Unrelated to the VRC features, vatSys can pull profiles from github which I think would be huge if it could be done with vSTARS and vERAM. It's makes is much easier to distribute profiles, easier for people to load profiles, and from an administrative perspective it would help prevent the loss of a profile because somebody got mad and yoinked it from existence. While you're in there tinkering, I hope this is a feature you keep in mind!

I would like to retract my previous responses to this^ response. I think what Ryan is asking for here is reasonable. The ability to move some menu items around in an easier fashion has nothing to do with the rules written in the .65 and have zero affect on your controlling ability. Would be nice.

 

On 5/2/2021 at 10:34 PM, Robert Shearman Jr said:

As someone who enjoys working Local with absolutely zero aspiration to advance to Radar or Enroute controlling, being forced to learn a realistic Radar or Enroute client is annoying.

I recognize the 'Corner' we are in when it comes to trying to simulate the CAB environment, as we don't have a Window to look out of (except with the Tower-View feature), nor do we have a good way to actually WRITE on flight strips and pass them to our other Local Control ATC next to us.
Logistically speaking, it seems like it is almost easier to create a RADAR Client than it is to create a realistic CAB sim for VATSIM.
The suggestions I put forth here in the following link, I believe would at least allow a direct transfer of VRC usability in this environment, which would near-seamlessly allow VRC controllers to come over to vSTARS and vERAM with no real problems and not have to learn a lot of new commands (you already don't have to learn a lot but, this would just make things easier anyways).

  

On 5/3/2021 at 4:39 PM, Robert Shearman Jr said:

Before simply writing off controllers who want to provide ATC services on VATSIM but aren't interested in learning ultra-realistic radar tools as "wanting to play video games" (paraphrased), keep this in mind: right now, the ratio of pilots to controllers is much, much higher than it has been in the past, due to the influx of many, many new users this past year.  So decisions made which will tend to weed out controllers is probably a bad idea right now.

I still stand by what I said before on this. If these controllers aren't willing to learn a new realistic software when the developer of the previous unrealistic software decided they are done with it, even though the new realistic software is NOT a difficult change over, then I would question those controllers actual desire to provide ATC services on the network.
Again, the term "Ultra-Realistic" is a grossly misapplied descriptor when it comes to vSTARS and vERAM.

 

On 5/3/2021 at 5:39 PM, Jason Cochran said:

Although I do find it funny that we want to emulate real-world systems that themselves have some poorly designed interfaces.

I do find this humorous.
However, as the RW continues to update their UI's, hopefully Ross will do the same with his software to match the RW ways of doing things.
This is a good time to mention again that the .65 and other regulations that we teach are heavily based on the Real World software UI and general capabilities (including those that are limiting) and it is easier to teach these students these concepts whenever they too, have to deal with those limitations of the software.

 

On 5/3/2021 at 5:44 PM, Will Wright 1252554 said:

Why should you care how realistic other controllers’ clients are? At the end of the day, we’re providing a service to pilots. They can’t tell what client we’re using if we follow the .65. If a controller wants to make it easier on themselves to provide this service, when why should we decide that that isn’t right? It’s 100% your decision whether you want to make this more realistic for yourself or not.

I agree 100% with this but you have completely missed the point.
I am responding to the complaints directly and their reasons for not wanting to use a more realistic software. Maybe I can use REASON to counter their statements and then they can take another look into the true reasons they are hesitant to switch (like someone did for me last year) or I could learn something that changes my opinion about VRC all together. It is a discussion. 
I have made it VERY clear that these are opinions and it ultimate doesn't matter at all what I say.

  

On 5/4/2021 at 1:05 AM, Robert Shearman Jr said:

All across this network we have to balance the degree of realism we want, from both pilots and controllers, with the degree of inclusivity we want.  Why is this any different?  Are we eradicating default aircraft next? 

What is wrong with this process then?:

“Are you making this ‘easy mode feature’ to resolve a problem that is fixed in RW with procedures and equipment that simply CAN’T be simulated on the network?

• If the answer is yes, then implement it.
• If the answer is no, then you are catering to someone that wants more of a video game atmosphere.

 

On 5/4/2021 at 10:57 PM, Ryan Parry said:

This is ludicrous. I could fly the default FSX 737 and you wouldn't know, outside of maybe the equipment suffix but it'd be a toss up between default 737 or simulating deferred FMS. I'm much more experienced and I know how to use the tools, or lack thereof, the default 737 has. There are many pilots on this network that can say the same. There are also a lot of pilots on this network with the NGXu, Zibbo, whatever, and they have no clue what they are doing and usually end up destroying an event. The plane a pilot chooses doesn't matter so much as the skill of the pilot. The same is true for the controllers radar client. Whether or not somebody uses VRC, vSTARS, or vERAM really does not matter, the skill of the controller using the client is the only thing that truly matters. 

I choose the NGXu when I fly because I enjoy the realism, not because it makes me a better pilot. I like VRC when I control because I don't have interest in the complexity of a realistic radar client, I just want to move the blips, and I'm not a worse controller because of that preference.

If I can "tell" that you are using an unrealistic software from the opposite or adjacent side isn't the point.
And what if I could? Many times I can tell that the pilot or controller is using an unrealistic feature and it deviates from the simulation for ME, so now MY emersion is affected.
VRC vs vERAM for example: 4th Line Coordination is not possible between these two clients when more than 3-4 characters are needed. Example: "DL/CONUK" meaning: "Deviation Left of course approved with an instruction to return direct CONUK when able" would not be seen by the one accepting that track as they would only see DL/C at most and now they have just approved that deviation without their knowledge.
There are more examples that I could start making a list of as they come up if you wish.
Unrealistic software limits the user at times even when it isn't the skill of the controller in question. My idea of "Banning Default" aircraft was a bit of a over exaggeration in hopes to draw attention to this without having to type out everything I just did. Sorry for the miscommunication.

 

On 5/8/2021 at 9:59 AM, Dave Mayes said:

I too couldn't agree with Ryan more.  I am here for the total enjoyment of "THE GAME".  Moving on to a radar client that would require a lot of training to become proficient at being an "real world" type atc controller, is not my idea of having fun.

This is a perfect example of what each individual wants out of the network.
Dave here wants a Game... I want a Simulation.
Dave's (and in general everyone that shares his desires) are completely in the RIGHT to want that, however these are not compatible goals with each other and maybe there should be multiple networks that cater to these different desires. The question is, what is VATSIM going to do?

 

On 5/11/2021 at 10:28 PM, Charan Kumar said:

as a casual hobbyist, I prefer the use of a mouse, especially for the topndown  we do here on VATSIM.

Using the Mouse in vERAM is absolutely able to be done, ESPECIALLY in Top-Down Mode.

 

On 5/12/2021 at 11:02 AM, Tim Simpson said:

Most ARTCC's don't allow new controllers to learn with vERAM because of its complexity.  Ending support for VRC, raises just one more barrier in front of people that are considering controlling.  

VATUSA is now requiring all ARTCC to not limit students to learning one software but MUST be allowed to utilize VRC, vERAM, and/or vSTARS at the students request.

 

---

I am going to go act like I have a life now.

[Robert Shearman Jr]

In the meantime, I have to back off on some of my earlier comments, too.  Seeing the writing on the wall I've started to familiarize myself with vSTARS and it indeed has not been the quantum leap I made it out to be (or should I say, feared it would be), very much in line with comments from Kyle and several others on this thread.  I still think it'll take more of a learning curve than VRC but I look forward to seeing Ross's plans for making it more "cab-friendly" going forward.

[Andreas Fuchs]

We had the same happen yeeeeeeeears ago when we switched from ProController to VRC to ASRC and finally to Euroscope. "Ooooooooh, this is soooooooo complicated, nobody will be able to learn this!" 😄 It's just different, that's all. I just made my personal step from using a plugin called "TopSky" in Euroscope: "Oh, it is sooooo complicated!". Err, no, it is just different. Should have started using it much earlier.

After all, we are humans...

[Ross Carlson]

Everyone, thanks very much for the feedback and productive discussion so far.

Regarding the balance between realism and ease-of-use, I still lean strongly in favor of realism when it can be achieved under the unique constraints imposed by our virtual world. When it comes to providing straight-up radar services, we can reach a high degree of realism in terms of the fidelity of the radar display, the syntax of keyboard/trackball commands, and the available tools such as bearing/distance measuring tools and the like. As such, I think we should keep clients like vSTARS and vERAM somewhat pure in terms of realism, and not "dumb them down" just for ease of use.

As for the argument that realistic ATC clients drive away the more casual controllers, I'm not convinced that this is a real problem. In order to make my point, I'm going to talk only about providing radar services, since that's all that vSTARS and vERAM were designed for. They weren't designed for top-down controlling (the top-down mode was mostly an afterthought) and they certainly were not designed for controlling tower cab positions. So if you compare vSTARS/vERAM against VRC for the purpose of radar controlling, then vSTARS/vERAM are a little more complicated in that they don't have things like the right click menu, or the double-click-and-drag measuring tool, but for the vast majority of functionality that a radar controller needs, all three clients are similar when it comes to learning curve and ease-of-use.

If I had to quantify the extra degree of difficulty of using a realistic radar client like vSTARS/vERAM above that of VRC, I would say it's probably something like 10 or 15 percent more difficult. Obviously we can't put a real number on something so subjective and nuanced, but I do feel confident in saying that the difference is small enough that it's not worth worrying about. In this thread, we've heard from some VRC users that aren't concerned with the realism of the tools, and they just want to provide ATC services, and I think they would be just fine with vSTARS/vERAM had they been using them from the start.

Put another way, I think that if vSTARS/vERAM were the only option, I don't think we would have any significant number of student controllers saying "this is too hard, you need to develop an easier ATC client or I won't be continuing to learn ATC." I stress the term significant here because I do think there might be some students turned off by the complexity of vSTARS/vERAM, but not enough to worry about. (And some considerable percentage of that minority probably wouldn't even be happy with VRC anyway.)

All that being said, we obviously don't just provide radar services, and thus a 100% realistic radar client simply cannot do the whole job effectively. Indeed, the realistic aspects of a radar client can even get in the way of providing services other than radar. Therefore, in order to retire VRC, we need a suitable replacement that works for delivering tower cab services, and full top-down services, and that brings us back to the original purpose of this thread.

I've been putting a lot of thought into how best to make vSTARS and vERAM more suitable for top-down controlling and tower cab controlling, and I am closing in on a plan that I think will work well for 99% of our use cases.

What I'm considering is essentially a new client where you can create profiles for different purposes, similar to VRC. When you create a profile, you choose which emulation mode and facility definition you would like to use for your primary display. The emulation types will include ERAM, STARS, ASDEX, and Generic. Facility definitions are similar to the existing vERAM and vSTARS facility files. FEs will create facility definitions for their ARTCC, any TRACONs within the ARTCC, and any towered airport. Each facility definition will contain a "type", which is one of ARTCC, TRACON, or Tower. These facility definitions will all follow a common format rather than the separate formats that we have now (one for vERAM, one for vSTARS.) The facility definitions will contain the vis center(s), frequencies, radar site locations, position info (POF file data), and aliases for the facility. Some facility definitions will include data that is only applicable to one type of facility. For example, the position relief and emergency checklists that ERAM has, or the CRDA definitions that STARS has. Also, Tower facility definitions will not contain radar sites.

It may sound like a lot of work to create facility files for every towered airport in the ARTCC, but doing so will be very quick ... a tower facility definition is just an airport ID and some frequencies, that's it.

Note that not all combinations of emulation mode and facility type will be available. For example, you wouldn't be able to open an ASDEX display using an ARTCC facility definition ... that just wouldn't make sense. ERAM displays will only be able to load ARTCC facility definitions. STARS displays will only be able to load TRACON facility definitions. ASDEX displays will only be able to open Tower facility definitions. Generic displays will be able to open any type of facility definition.

After opening the primary display, users can also open additional displays using any emulation mode and facility definition for each. The vis centers for these additional displays would be ignored ... only the vis centers for the facility definition you chose for your primary display will take effect. The same would likely apply for frequencies. The only frequencies that would be available to select as your primary frequency would be the ones included in the facility definition you selected for your primary display.

In terms of functionality, the ERAM and STARS modes would work just like they do now in vERAM and vSTARS, and the top-down mode would be removed. These modes would be for the user that is looking for realism in the client.

The ASDEX mode would work like it does now in vSTARS, but it would be enhanced with more functionality for tower cab controllers (DEL/GND/TWR) to be able to easily pull up and edit flight plans, assign beacon codes, view a list of arrivals/departures, etc. It would have the right-click menu from VRC, a way to show the METAR for the field, wake turbulence timers, etc. It would still be limited to a single video map and it would still use the white and orange aircraft icons to represent aircraft positions and orientations. Unlike the ASDEX displays that vSTARS currently has, this new ASDEX mode will be fully usable as a standalone display, providing all the functionality I listed above, so a DEL or GND controller could provide full services with just a single ASDEX display. TWR controllers could probably use it standalone as well, but they would likely want to have an ASDEX and a STARS display together. (And in case there is no applicable TRACON facility definition for the tower's airspace, the user could use a Generic mode display to show their airspace, instead of STARS.)

The Generic mode would be similar to VRC. It would have a right-click menu for working with targets, a double-click-and-drag range/bearing tool, arrival/departure lists, on-screen METARs, and wake turbulence separation timers. The Generic mode would not use sector files. (I really hate sector files and I want them to go away forever. /rant) It would instead use video maps similar to vSTARS. There would be a simple pop-up window where the user would select which video maps to display, and set their brightness. The user would be able to choose from a set of data block formats, just like you can in VRC using the radar mode selection list. (I wouldn't include ALL of the types that VRC has, just the ones that make sense for providing services in the US. So I wouldn't need the Park Air or TAATS types. Euroscope and vatSys provide much better emulations of non-US radar systems.) I would probably include the Ground, Tower, STARS, and VRC types. Generic mode displays would not make use of radar site definitions ... they would show a data block for all targets at all times, similar to VRC in its simplest modes. Generic mode displays would have altitude filters like in VRC, so that you can suppress the display of aircraft above and/or below your airspace.

After setting up the primary and secondary displays, the user would be able to save the profile with a name, just like you can in VRC. It would behave like VRC in that your changes would only be saved if you deliberately activate the save feature. They would not be saved automatically when you exit the client. This way you can mess around with display locations and sizes, and other settings, without worrying about clobbering the profile that you spent so much time perfecting. I'll probably have it prompt you to save the profile if you have changed anything, just like VRC does currently.

Regarding video maps, vERAM and vSTARS currently each have their own proprietary format. I'm planning to unify them into a single format that would be used for all facility types (ERAM, STARS, ASDEX, and Tower.) I may use an established format such as GeoJSON, which should allow FEs to use existing GIS tools for creating new maps. The final version of the map that the client would use might be something compiled into a binary format in order to keep the downloads smaller. This is because I would build an auto-update feature into the client where it keeps the facility definitions and video maps updated automatically when FEs publish a new version on their web site. I might even be able to keep all the maps used by all facility definitions for a given ARTCC in one big file that is stored and downloaded in a compressed or binary format so that updates will be very fast. Updating the facility definitions and maps will happen when you first run the client and it will be mandatory, not opt-in. That way everyone knows that everyone is using the same information.

FEs will manage all their video maps as one big collection of maps, and each map can be marked as being applicable to one or more facility definitions. That way FEs can avoid duplicating a map that is used in more than one facility definition, such as a map that shows center sector splits which might be relevant to multiple TRACONs in the ARTCC, or a class B/C/D airspace diagram that is relevant to the tower facility as well as the overlying TRACON facility and ARTCC facility. Each map will be assigned to a brightness control group and filter number so that it can be assigned to buttons in the ERAM/STARS/Generic user interfaces.

I will likely set up a way to make it very easy to import the facility definitions and video maps for the first time. This will probably work similar to Discord server links. FEs will be able to place a special link on their web site which will launch the client and download the facility data. From that point forward, the client will keep the data updated automatically.

The waypoints and airports files will also be kept up to date, using the free FAA NASR data as the data source. If facilities outside of the US want to use the new client, I would probably add a way to load custom waypoint and airport data from local files that their users would download manually. However, I don't think that'll be necessary as Euroscope and vatSys provide much better options for non-US controllers.

This client will also support tower view in the same way that vSTARS does currently. If you have an ARTCC or TRACON facility loaded, you will need to specify which airport you want to use for the tower view, and your primary vis center will be moved to that airport. That way your tower view will get the high-speed position updates once the Velocity project is released. (High-speed position updates are only sent for aircraft within 10 NM of your primary vis point.) This could cause issues for CTR controllers if moving their primary vis point to an airport will cause gaps in their airspace coverage. In such situations, tower view probably won't be a viable option. I may talk to the tech team about adding something to the network protocol that lets controllers create a new type of vis center that is only applicable for tower view and high-speed position updates, while leaving the conventional vis centers untouched.

Regarding communications, this client will have a text communications window similar to what vERAM and vSTARS have currently. The client will not have any sort of voice comms panel like the VSCS and RDVS panels that currently exist in vERAM and vSTARS. This is because all those panels are used for these days is selecting your primary frequency. Everything else is done through the AFV client or third-party tools like Discord or TeamSpeak. (I may eventually integrate AFV, but that will come later, if at all.) For selecting your primary frequency, I will add a new tab to the text comms window with a list of frequencies with a checkbox next to each, similar to the comms panel in VRC.

Regarding flight strips, this client would have the same flight strip functionality that vSTARS has currently.

As for the name, I'm thinking about calling it CRC, for "Consolidated Radar Client."

Anyway, there it is. It'll be a lot of work and testing, and probably will take at least a year, maybe longer. None of this is set in stone, and I would appreciate any feedback.

TL;DR: I like tacos. (Sorry, there just isn't a good way to summarize this post.)

P.S. Many thanks to Nathan Rankin, ZBW FE, who helped me out with some of the design decisions regarding the handling and structure of facility definitions and video maps.

Edited May 21, 2021 at 02:29 PM by Ross Carlson

[Alistair Thomson]

Superb! A significant amount of work, but all US controllers will be better off as a result.

6 hours ago, Ross Carlson said:

I really hate sector files and I want them to go away forever.

[Helmet on, head below parapet, stack of tacos safely stowed] :)

 

[Kyle Sanders]

edit: (wrong place to post)
 

Edited May 21, 2021 at 02:36 PM by Kyle Sanders

[Kyle Sanders]

 Ross,

I think what you are working on here is absolutely the BEST thing you could have done to satisfy the needs of all. I really enjoy that it is going to be all one client all sharing a single format for data and management.

With you creating a completely new client and with "Facility Definitions" becoming a thing, this may be a good time for VATSIM to consider updating the data that they collect and transfer between clients.

• You could now transfer the VFR, OTP, Block altitudes to other appropriate facilities (for example, a TRACON wouldn't get that data from an ERAM facility but another ERAM facility would).
• Same with pointouts, ERAM to ERAM... or ... STARS to STARS but never between the two.
• Scratchpads (4th line data) would not transfer between ERAM & STARS.
• Quick Looking another same-facility type would allow you to see their FDB in the position that that person has it in. (this is actually used as an LOA-Pointout method in places like ZSE)
• Matching CID information? (that might be a little harder to do as it would require simulation of an actual ERAM CPU per ARTCC)

I am sure there are more compatibility functions that could be simulated like RW with this new client and hopefully a VATSIM data update.

 

The name "Consolidated Radar Client" is good but considering that you are designing this not completely around RADAR, maybe Triple C "Consolidated Controller Client" would be more accurate.

 

8 hours ago, Ross Carlson said:

Regarding video maps, vERAM and vSTARS currently each have their own proprietary format. I'm planning to unify them into a single format that would be used for all facility types (ERAM, STARS, ASDEX, and Tower.) I may use an established format such as GeoJSON, which should allow FEs to use existing GIS tools for creating new maps. The final version of the map that the client would use might be something compiled into a binary format in order to keep the downloads smaller. This is because I would build an auto-update feature into the client where it keeps the facility definitions and video maps updated automatically when FEs publish a new version on their web site. I might even be able to keep all the maps used by all facility definitions for a given ARTCC in one big file that is stored and downloaded in a compressed or binary format so that updates will be very fast. Updating the facility definitions and maps will happen when you first run the client and it will be mandatory, not opt-in. That way everyone knows that everyone is using the same information.

FEs will manage all their video maps as one big collection of maps, and each map can be marked as being applicable to one or more facility definitions. That way FEs can avoid duplicating a map that is used in more than one facility definition, such as a map that shows center sector splits which might be relevant to multiple TRACONs in the ARTCC, or a class B/C/D airspace diagram that is relevant to the tower facility as well as the overlying TRACON facility and ARTCC facility. Each map will be assigned to a brightness control group and filter number so that it can be assigned to buttons in the ERAM/STARS/Generic user interfaces.

I will likely set up a way to make it very easy to import the facility definitions and video maps for the first time. This will probably work similar to Discord server links. FEs will be able to place a special link on their web site which will launch the client and download the facility data. From that point forward, the client will keep the data updated automatically.

This is possibly one of the best things I think you have come up with for FE's and facilities to manage their data and member resources!

 

8 hours ago, Ross Carlson said:

The waypoints and airports files will also be kept up to date, using the free FAA NASR data as the data source. If facilities outside of the US want to use the new client, I would probably add a way to load custom waypoint and airport data from local files that their users would download manually.

I am sure you have your own logic setup for this but if not, I have been helping with an FE Automation tool that grabs not only the waypoints and airports, but also the airways and DP/STAR procedures. It does a few other things with weather stations and all too. Feel free to check it out and pull whatever logic you want from the resource files!
https://github.com/Nikolai558/NASR2SCT

 

8 hours ago, Ross Carlson said:

Regarding communications, this client will have a text communications window similar to what vERAM and vSTARS have currently. The client will not have any sort of voice comms panel like the VSCS and RDVS panels that currently exist in vERAM and vSTARS. This is because all those panels are used for these days is selecting your primary frequency. Everything else is done through the AFV client or third-party tools like Discord or TeamSpeak. (I may eventually integrate AFV, but that will come later, if at all.) For selecting your primary frequency, I will add a new tab to the text comms window with a list of frequencies with a checkbox next to each, similar to the comms panel in VRC.

Last I knew, AFV was working on a landline simulation to be built into their client but that project seems to be one that doesn't release a lot of information about the status of their progress and a LandLine system is something we desperately need on VATSIM. My own FE can't even seem to get the beta of their new client.
The TeamSpeak/Discord method and Text-Based communications is something we use because there is no better method available. I think you would find the opinion popular that ATC would rather have a landline system that actually makes realistic calls to the sector/position they are trying to reach and have it function as close to RW as possible rather than having to keep up to date with several different TeamSpeak/Discord servers, finding the person working the position you want to reach, and then interrupting their 'Canes vs Zaxby's vs Chick-fil-a' argument to do some official coordination.
My FE and I have even started the idea-board for how we could possibly build this to meet our needs on VATSIM but considering that you are already building a new client, would this not be something you would want to build into it? Or at least as a future feature release?
Reference: 

 

Edited May 21, 2021 at 02:47 PM by Kyle Sanders

[Ross Carlson]

Thanks for the feedback, Kyle.

For now, I will not be exploring any changes to the features and functionality of the ERAM/STARS modes, especially any that would require server and protocol changes. That would add way too much to a project that is already going to be a heavy lift.

Same goes for any voice comms stuff. This client will not have any voice functionality in version one. My hope is that someone will pick up the ball with AFV development and add land line support, ideally with an API/SDK for clients like CRC to integrate with it and be able to keep the list of frequencies and landline candidates in sync with the ATC client.

I know it seems like creating a new client is the perfect time to make these changes, but it doesn't really work that way. That's like saying that if you're building a new car, it's the perfect time to build new roads.  In software development, it's known as "scope creep" when the scope of the project grows beyond the original design goals. Sometimes that's a good thing, but usually it just means the complexity grows and the release date keeps getting pushed back. For this project, the design goal needs to be kept to just the consolidation of vSTARS, vERAM, and VRC with a unified facility definition and video map format. Anything that doesn't serve that goal will be deferred to a later phase.

25 minutes ago, Kyle Sanders said:

maybe Triple C "Consolidated Controller Client" would be more accurate

I like it. And it reminds me of my favorite aircraft, the triple 7. 

[Kyle Sanders]

That makes perfect sense! Thanks!

[Manuel Manigault]

Thanks Ross!  This is exciting news.

[Karl Mathias Moberg]

This sounds like a fantastic solution, Ross, really looking forward to trying it out! 

On a side note: with CPDLC being more and more adopted on VATSIM with multiple aircraft now supporting the Hoppie CPDLC client and quite a few our European collegues using it through Euroscope: any chance for this new client to either support it natively, or allow for others to build a plugin at a later point that could allow for that functionality?

[Gunnar Lindahl]

Sounds great!