Planning ahead for retiring VRC

[Ross Carlson]

Hello all,

I'm posting to let everyone know with as much advanced notice as possible, that I have begun planning for the eventual retirement of VRC. I have not done any new feature development for VRC in many years, mainly because VRC was written in a programming language that I haven't used since 2004, and I simply don't consider myself fluent in that language. (I really never did ... VRC is the only application I ever wrote in C++.) As such, I have no desire nor motivation to work on it, and any development time that I have available gets put into vPilot, vERAM, and vSTARS.

So, as of today, we can all consider VRC to be EOL. (End Of Life.) It will still continue to function for the foreseeable future, but given the significant amount of tech development progress within VATSIM recently, it is only a matter of time before a change comes along that renders VRC incompatible. That will be the time that VRC is officially retired and will no longer connect to the network. I will give as much notice as possible once I know when that time is coming. I would love to give a more concrete idea of when VRC will be retired, but I really can't because it totally depends on other development progress. I won't retire VRC until I have to ... not until something changes with VATSIM's network infrastructure that makes VRC no longer function properly.

One thing I considered was to rewrite VRC in a language that I'm comfortable with, such as the language that I use for my other VATSIM software, which is C#. I decided against that option because I feel that we simply don't need VRC anymore. Since I released VRC, several far more realistic and full-featured clients have become available, including Euroscope, vERAM, vSTARS, and vatSys. I would rather put my time into further developing my other software, instead of rewriting VRC.

On that subject, I know that vERAM and vSTARS are not currently a suitable replacement for VRC, since they are designed to be high-fidelity simulations of the real ERAM and STARS radar systems. As such, they are great for working Center and Approach positions, but it can be cumbersome to use them for top-down controlling, or especially controlling tower cab positions (DEL/GND/TWR.) Therefore, my plan is to enhance vERAM and vSTARS so that they are more suitable for these scenarios. I don't know yet exactly what this will entail, but it will likely be a matter of adding a "ground" mode that shows all targets regardless of radar coverage and without having to initiate track. Similar to the top-down mode that these clients have now, but with even more functionality to make the Cab controller's job as easy as it is in VRC. This ground mode would probably include an arrival list and a departure list, and some of the other VRC tools like the wake turbulence timers, the reminder list, etc. It will probably end up looking very similar to VRC, in fact. The big difference is that it won't use sector files. It'll likely use the video map format that is currently used by vSTARS.

I would love to hear any suggestions that controllers may have for making vERAM and/or vSTARS more suitable for top-down controlling and controlling tower cab positions. Please post them right here in this thread.

[Owen Wang]

I already use vSTARS for GND and have no issues with it really. I'm not sure what it would be like top down though.

[Cian Ormond]

17 minutes ago, Owen Wang said:

I already use vSTARS for GND and have no issues with it really. I'm not sure what it would be like top down though.

I'm inclined to agree. I used it for GND for a while and since getting my S2 have used it for TWR every session I've had (except my first lesson, that was vERAM and wasn't very fun). Last night I utilised the Tower View system with X-Plane at a non-radar airport with GND below me in virtual reality and it went swimmingly, minus X-Plane's somewhat buggy SteamVR system. The only complaints I have is the window system with the comms panel and the like. It can't be captured as a separate window, which means I have to use my desktop view for a release request, checking a flightplan, etc. Furthermore, whenever the mouse hovers over the side toolbars without vSTARS focused, any window in front of vSTARS gets sent behind it, including any of vSTARS' own windows. The ASDE-X could be further worked on as well, from what I've seen there's not even documentation. I of course am not an FE, so take my views on that with a grain of salt. The client is fully functional and has no major issues that can't be easily worked around for my usage and I hope to see this theme continuing on.

 

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

Edited May 3, 2021 at 01:35 AM by Cian Ormond

[Kyle Sanders]

I am very happy to hear that VRC is now entered EOL and that you have decided to incorporate more functionality for TDM with your other clients!

 

I would think that the only things we would really NEED for the other clients standard across both of them is when in TDM:

 

1. Remove the restrictions for TDM data to show when only a certain distance and speed from the filed DEP and ARR airports. Reason: VFR aircraft without any filed flight plan or transition a Class D airspace, the TWR would need to be able to simulate looking out the window and seeing that actual aircraft and the altitude.
2. Ability to see any aircraft callsign. (we aren’t RW controllers nor do we usually have flight strips to write down the callsigns like RW).
3. Aircraft type, if filed.
4. Altitude (if airborne).
5. Ability to see if they are squawking Mode-C or not (for ASDEX airport simulations) along with if they are squawking the correct assigned code.

Edited May 3, 2021 at 01:29 PM by Kyle Sanders

[Emma Pollak]

I'd say there's just a few small things that make me use VRC over vSTARS for tower and ground.

- Being able to open a flight plan from the flight strip for easy editing (maybe I just need to change my habits to edit the flight plan on the strip)

- Being able to toggle datablocks for aircraft not squawking mode C in the ASDE-X. It creates a whole bunch of clutter which is more difficult to clean up than in VRC

- The option for sequential squawk codes when amending flight plans or flight strips, maybe with a different squawk bank. It allows approach to continue to assign random codes via the F9 hotkey, while tower and ground can assign sequentially from their squawk bank. I know not every ARTCC would use it, but it would be a big help. This implementation might be too specific to my use case, though.

- Auto-adding flight strips when they are filed, which I'm sure you know about.

 

TDM definitely leaves a lot to be desired. I worked tower at an airport without ASDE once, and it was rough. I had to zoom way in to see where aircraft were on the taxiway, and aircraft in the pattern were below the radar floor, so I had to go in and move the radar site to be on the airport. This was ACK, and I believe the nearest radar site is around FMH, if you're wondering. Some way to work an airport without ASDE would be on my wishlist. It's definitely hard to balance realism with usability, though.

I know that tower controllers working an airport like that in the real world would just look out the window, and tower view definitely provides a way to do that, but I don't feel like booting up my sim every time I want to control, and some people don't even have a sim installed. I think a separate ASDE-style window for airports like that would be helpful, in addition to TDM for approach controllers to get a quick peek at the airport. Maybe if you want to keep the spirit of realism around, don't show callsigns.

[Liesel Downes]

An excellent but sad decision

[Nick Saffari]

I think all the things you mentioned are good. The way I would like it is vSTARS and vERAM having features like VRC in its top down mode. Features like, seeing if targets are squawking mode C and the correct code on the ground at non asdex fields, right click options, being able to draw a ruler by double clicking and dragging, seeing primary targets callsign in GND and TWR radar modes, and more. If these things were in vSTARS and vERAM currently, I would definitely use them more today. All in all, I will be sad to see VRC go someday. However, I am optimistic that the new vSTARS and vERAM TDM modes will be perfect!

[Ryan Parry]

I'll be a little blunt, this is disappointing. 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.

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. I think the other things mentioned in this thread are all good also. That'd make me happy to use vSTARS and vERAM. Honestly, you could just put all the nice unrealistic features inside of an "easy mode" setting in the options, check the easy mode box if you're not as cool as the other controllers and you'll have VRC like goodies at your disposal.

I appreciate the work you've done for the network, so thank you! Looking forward to checking out the updates done to vSTARS and vERAM.

[Robert Shearman Jr]

I'd like to echo Ryan, word-for-word.  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.  That being said, I know Ross has spent thousands, maybe tens of thousands of hours developing for VATSIM and I certainly don't want my sentiment to sound like ingratitude.  I am hopeful that another developer will pick up the torch when it comes to developing a "beginner's client" and/or a client that is more geared toward the basic flightplan and flight strip manipulation, ground movement, and runway control that a Local controller is focused on.

Any thoughts on handing VRC off to another programmer?  I know that there would be time invested in the transition (i.e. some hours devoted to getting a new project manager up to speed on the ins-and-outs of the code) but it might be better than scrapping it altogether.

[Ross Carlson]

1 hour ago, Ryan Parry said:

Honestly, you could just put all the nice unrealistic features inside of an "easy mode" setting in the options, check the easy mode box if you're not as cool as the other controllers and you'll have VRC like goodies at your disposal.

Thanks for the excellent feedback, Ryan. What you describe here (an easy mode) is pretty much what I mean when I talked about the "ground mode" in my original post. I think that's likely to be the way to go. Perhaps "tower cab" mode would be a better name, implying that it is designed for any position below approach.

1 hour ago, Ryan Parry said:

I really wish VRC would just be open sourced, but I know that's been shot down in the past.

 

1 hour ago, Robert Shearman Jr said:

Any thoughts on handing VRC off to another programmer?

Handing VRC off to another programmer isn't totally outside the realm of possibility, but it is very unlikely. VRC is the only app that I have ever written in C++, and it was one of the first large object-oriented apps I wrote, and the code is just difficult to maintain. For the coders reading this thread, the main issues are way too much coupling between classes, classes with way too many responsibilities, and no dependency inversion. That being said, the code is "clean" in the sense that class names, method names, and variable names are all very descriptive, and the code formatting is clear and consistent. So, maybe some brave soul would be willing to take it on, maybe refactor it to follow modern best practices, but I'm not hopeful, and I really don't think it would be the best use of that person's time.

[Liesel Downes]

3 hours ago, Ross Carlson said:

Handing VRC off to another programmer isn't totally outside the realm of possibility, but it is very unlikely. VRC is the only app that I have ever written in C++, and it was one of the first large object-oriented apps I wrote, and the code is just difficult to maintain. For the coders reading this thread, the main issues are way too much coupling between classes, classes with way too many responsibilities, and no dependency inversion. That being said, the code is "clean" in the sense that class names, method names, and variable names are all very descriptive, and the code formatting is clear and consistent. So, maybe some brave soul would be willing to take it on, maybe refactor it to follow modern best practices, but I'm not hopeful, and I really don't think it would be the best use of that person's time.

If you'd be willing to open source it (while of course removing code that would come under the VATSIM NDA - as xpilot does on Git), you could perhaps attract someone that way. I agree it's probably not worth that persons time but thats their problem

[Nathan Cox]

One VRC feature that is very dear to me when I control a busy cab position is the ability to pass a flight strip using just keyboard commands (F6 <sector ID> ASEL).  During busy events, this is much faster than having to right click on a strip and scroll through a list of a couple dozen callsigns.  It's especially useful when you take into account shift changes.  Over the course of an event I may have to pass to ATL_1_TWR, ATL_5_TWR, and ATL_3_TWR at various times.  It's a lot easier to just pass to the "L3" sector ID than keep track of changing callsigns.   This one feature is the thing that keeps me using VRC instead of VSTARS for controlling Atlanta ground and local.

Edited May 3, 2021 at 08:40 AM by Nathan Cox 1179253

[Ryan Parry]

10 hours ago, Ross Carlson said:

Thanks for the excellent feedback, Ryan. What you describe here (an easy mode) is pretty much what I mean when I talked about the "ground mode" in my original post. I think that's likely to be the way to go. Perhaps "tower cab" mode would be a better name, implying that it is designed for any position below approach.

Well, the reason I thought "easy mode" or whatever you want to label it, is because it is my hope some of the less realistic, ease of use VRC features would also be available when controlling a radar position with vSTARS or vERAM, not just ground or tower. 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!

[Justin Blakey]

Unlike what some others have said, I'm not sure I'd like a modification of vSTARS or vERAM to "replace" VRC. I like these 2 clients as what they are - as close as possible to the real systems, possibly with a few modifications to better facilitate top-down controlling.

However, since we're talking about future improvements to these clients, here is my wish list:

vSTARS:

• An "omniscient mode" that displays callsigns and altitudes of all aircraft, regardless of transponder status or radar coverage

vERAM:

• The SU (shortcut) command would be very nice to have
• Omniscient mode as described above
• Ability to assign squawk codes in the flight plan editor as with vSTARS

I don't think that vSTARS and vERAM should be "dumbed down" or "made easy" to be more suitable for cab positions. If VRC's days are numbered then perhaps it is time that facilities look towards other clients that can be configured to have the same functionality (such as Euroscope). I think that the 3-client dynamic (one built specifically for VATSIM, 2 to closely replicate real-world systems) works very well and I would like to see it continued into the future.

One final note - I, like others, don't mean any of this to be ungrateful or disrespectful. Ross, I am extremely grateful for the excellent software you have provided us and I understand your decision to retire VRC. However, (and I recognize this might be an unpopular opinion) I think that a configuration of Euroscope would be a much more suitable replacement than a modification or "easy mode" of vSTARS or vERAM.

[Nate Johns]

Ross,

One area of concern is beacon code allocation. 

In the past, I have designed POFs to allocate increased and differentiated beacon code sets for tower controllers signed on separately from TRACONs.  However, with vSTARS only allowing a VFR and IFR code set on a per-facility basis (as far as I'm aware anyway), I don't necessarily want to have individual vSTARS files for every tower facility.   I was just discussing with ZAU staff last week about philosophy of sector file use based on this, with consensus on our end being we only wanted to support separate vSTARS files for ORD/MDW/MKE as ASDE-X sites, and encourage use of VRC for the other smaller towers thanks to built-in beacon code assignments in the POF.

As well, while there is a VATUSA Beacon Code allocation program that loosely emulates the real-life 7110.66 Nat'l Beacon Code Allocation Program (NBCAP), the system logic VATSIM and clients use is far different than ERAM code allocation techniques. It appears to be, practically speaking, unreasonable to implement the real allocation program on the client side as the software exists today.

Some thoughts/questions:

Would it be possible to integrate the existing POF format such that ABC_TWR is allocated a different beacon code set than ABC_APP even if both are using the ABC_APP imported file (i.e., perhaps vSTARS differentiates someone logged in at ABC_TWR vs ABC_APP for beacon code purposes).

For the US in particular, since the codes are well-defined in the NBCAP, can that information be coded and utilized in some manner?

Could the VATSIM servers potentially be the source of beacon code allocation instead of the clients?

 

I'm sure there are some potentially steep challenges here, but I think some modification of beacon code allocation and assignment is necessary to minimize chances of running out of codes or causing duplicates.

Willing to discuss further if you'd like.

Nate

[Kyle Sanders]

Justin, “Shortcut” as in “cleared direct ABC”?

If so, RW ERAM does that via the QU command (then draws that route).

 

Ryan, I acknowledge that we all do this for different reasons but this is an Air Traffic Control simulation. If we aren’t simulating the realistic way they do this, then what are we even doing?

 

Why not just use the same UI as the mobile “Planes Control” app? Lol I’m being sarcastic to show a point. Where do we draw the line between realism and VATSIM RADAR client UI?

 

To find that line, I would ask “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 and I think we could all do with a little less of that mentality on this network.

 

It’s worth noting that ZLC has started teaching vSTARS to all of our new students and they have never touched VRC and they are doing just fine. You never hear these guys complain about the amount of commands there are to learn or how they wish there was a “right click option”. They are also not reliant on Ruler type features, but instead they learn basic ATC skills that allow them to find a heading and distance using range rings and 2nd grade geometry skills.

 

I find the “learning curve” argument to be a little invalid because it is coming from those that learned how to do this on an “easier” software and set in their ways.

 

I recognize that everything I said here is my OPINION and it will be treated as such.

 

A good point about the ability to have color profiles in these clients is a good one for those with sight issues. Also RW even has the ability to draw certain colors for MOAs, Restricted areas, etc… but this topic was suppose to be focused on making vERAM and/or vSTARS more suitable for top-down controlling and controlling tower cab positions so we should probably stick to that.

Edited May 3, 2021 at 04:44 PM by Kyle Sanders
A little humor

[Nate Johns]

With ADS-B being nearly-ubiquitously in use throughout the USA, we've very nearly come full circle away from the idea of radar coverage swaths.

For typical VATSIM traffic, I believe it would be more realistic to implement filters to not display aircraft on the surface of airports (in a manner similar to the current arrival filter volume) and show all other traffic, rather than have holes in radar coverage.

I have can expand on the concept in a separate conversation if you'd like.

[Justin Shannon]

• Allow multiple display windows in vSTARS (similar to vERAM's .newdisplay command)
• Support taxiway labels for ground maps
• Ability to save profiles in vERAM
• Alphabetically sort altimeter list by station in vERAM
• Ability to assign beacon code from flight plan window in vERAM
• Inbound/Outbound aircraft list in vERAM
• Option to display all callsigns, regardless of transponder state
• Be able to easily differentiate between mode c and standby targets in the ASDE-X view
• .trackatis command in vSTARS
• Some sort of "request list" like VRC

Edited May 7, 2021 at 03:46 AM by Justin Shannon

[Ross Carlson]

1 hour ago, Nate Johns said:

One area of concern is beacon code allocation. 

I was thinking about this just last night ... we would definitely need FEs to be able to define code ranges by facility, for the cab positions. I think this could just be a matter of importing the code ranges from the POF file that FEs already have.

Regarding the discussion of realism versus ease-of-use, it's definitely hard to find the right balance there. When I originally wrote VRC, I was of the mind that unrealistic features (like the right-click menu) were a good idea if it helped get more controllers on the scopes. However, I have since leaned far more in the direction of realism. I tend to believe that we should strive for realism in all aspects of our operations. We are, after all, simulating the real world. That being said, we do still want to make the process of becoming a controller as obstacle-free as possible. To me, this means having good documentation, tutorials, and training.

For those reasons, I would like to keep the fidelity of vERAM and vSTARS as high as possible, and only introduce the unrealistic features when the user opts into them, by putting the software in "tower cab" mode or "top down" mode. (Notice I didn't call it "easy mode".) I think it's okay to diverge from realism in those situations, because it's already very unrealistic to have a single controller covering radar and cab positions at the same time. It's also unrealistic to have a tower controller working a tower solely from a 2D radar screen when the weather is clear.

[Nickolas Christopher]

vSTARS and vERAM are my primary clients. I welcome the change and agree with the "tower" mode.

What does this look like from a facility engineering perspective? Creating a vSTARS facility for every single towered airport is going to be cumbersome and overwhelming. Could there be a way to allow FEs to import an SCT2 into a combined "all minor airports" vSTARS facility on "easy/towered" mode?

 

[Ross Carlson]

6 minutes ago, Nickolas Christopher said:

What does this look like from a facility engineering perspective? Creating a vSTARS facility for every single towered airport is going to be cumbersome and overwhelming. Could there be a way to allow FEs to import an SCT2 into a combined "all minor airports" vSTARS facility on "easy/towered" mode?

I'm not sure yet. One thing I'm considering is having a new facility type, which would be called something like "Tower Cab Facility" or just "Tower Facility". FEs would manage the facility file just like they do vSTARS or vERAM facilities. Managing a tower facility would be much simpler, since it wouldn't need radar sites, or tons of video maps. Perhaps you would just import a handful of video maps, import a POF file, import an alias file, and you're done.

Another option would be to have a single facility file that included data for ALL towered airports in a given ARTCC. The user would then choose which airport they're working when they open a display for that airport. (Top-down controllers could open multiple such displays.) This one single facility file would have a video map (or multiple video maps) for each airport, and a single POF file and alias file import that would cover all the airports.

[Ross Carlson]

4 hours ago, Ryan Parry said:

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!

Since I first wrote vERAM and vSTARS, I've wanted to do something to make it easier for controllers to set up new profiles, and something to make it easier for FEs to distribute updated facility files. My thinking is to have a central registry where FEs could post a URL to a JSON file that lists all of the facility files that they maintain, with a version number and a download URL for each. The client would then check this JSON manifest to see if an update to any of the installed facility files is available, and if so, automatically update it. FEs could store the files anywhere they like, including a github repository. Only the JSON manifest file would need a stable, unchanging URL, since it would be kept in the central registry that would live on my server or on a VATSIM-controlled server.

Edited May 3, 2021 at 06:54 PM by Ross Carlson

[Kyle Sanders]

27 minutes ago, Nickolas Christopher said:

Creating a vSTARS facility for every single towered airport is going to be cumbersome and overwhelming.

 

We recently did this with ZLC and thought it was going to take MUCH longer than it did. A good majority of our fields don’t have a radar display so I would make a new facility, define the airport location, create a fake radar site there, import the airports diagram and the airspace diagram… then you’re done. Took maybe 2-3hrs total.

 

The pain came later when updating the alias  for each of these .gz (which we do every AIRAC and sometimes more) to open, import, export each facility. One of our members wrote a script to help do this automatically and now it only takes like 7 seconds to do all of them with a simple lunch of a script. Hope to make this public soon.

[Nate Johns]

1 hour ago, Ross Carlson said:

I was thinking about this just last night ... we would definitely need FEs to be able to define code ranges by facility, for the cab positions. I think this could just be a matter of importing the code ranges from the POF file that FEs already have.

The primary issue with this, combined with attempting to follow the NBACP (real or VATUSA), is the discontinuous code sets.

While each ARTCC theoretically has many hundreds of codes available at any given time thanks to Prim/Second/Terti-ary blocks, not to mention differentiation between Internal and External assignments, it get too chopped up among the potentially dozens of child facilities if we're trying to eliminate potential for dupe codes.  Point being, the current client structure (nor POF) simply does not allow for a reasonable number of codes for departure-heavy events without artificially deviating from the code plan.

I don't want to get too in the weeds on the forum here, but a solution that does not restrict an individual controller to a necessarily- limited code set would be preferable.  If some flying group wants to have a couple dozen planes depart from a smaller towered field, there's a potential to run out of codes even with a POF code set written to segregate out a block of codes for each facility.

Some methodology for centralized beacon code assignment a la ERAM would be ideal, it would simultaneously allow access to all possible codes within a center for all child facilities.  That said, I'm sure there's a host of obstacles related to that.

Edited May 3, 2021 at 07:40 PM by Nate Johns

[Nate Johns]

Implementing Continuous Range Readout (CRR) in vERAM would go a long ways in replacing the anchor function in VRC, which is a valuable tool for TMCs and controllers alike for spacing and sequencing purposes.