Please provide guidance for pilot phraseology; here's a good start:

https://www.faa.gov/air_traffic/publications/atpubs/aim_html/chap4_section_1.html#z282c6ROBE

Many are broadcasting as though they are talking to ATC, and it is just clutter.

Have you seen the Learning Center on MyVATSIM? Pretty much everything you are saying is already documented there.

https://my.vatsim.net/learn/frequently-asked-questions/section/140

BL.

A16 - many, many pilots using 122.800 as a chat line.  I remind folks and then I just wallop.

You're doing the right thing here in .wallop.

B8(a-c) - so many folks are unable to operate in the airspace with respect to following a /L or /Z flight plan.  Lots of wet nursing taking place on the part of the controllers.

Mandatory training for pilots please.

Ongoing issue on this one, as it has been an issue since RNAV was implemented over 20 years ago. Back then, those that filed RNAV were still waiting to be vectored, meaning that they had no clue about the concepts of RNAV or what was supposed to be done when it is filed. Now that RNAV is the norm, they still don't know..

Back then those who filed RNAV knew what they were doing and didn't need to be vectored. Now, those that do not file RNAV appear to be the ones that know what they are doing and respond properly when vectored.

Unfortunately, this may be an issue bigger than VATUSA can handle; the BoG has routinely stated that this is a learning environment, and as such, training for pilots has been optional, while training is required for controllers. This has resulted in some turnover of controllers which is a result/byproduct of being stuck in this position. I wish there were a solution for it, but until VATUSA and VATSIM come to an agreement for what should happen, this problem (pilot competency) will continue.

BL.

Hi folks,

It's been quite a long time for me. I did do a cursory search of the forum but am wondering if there's been an updated process or suggestion.

In an effort to return back to this hobby, I'd much prefer to not go out and buy a windows laptop. Currently have a 14in MBP that I'd like insight from folks on how best to use it for VATSIM. Appreciate your time.

JH

JH! yes, it's been a while!

Okay, here's the question.. Is your MBP an Intel Mac or an Apple Silicon Mac? If Apple Silicon, there is nothing you can really do that is native to the Mac for controlling. You may be able to get away with running a VM with Parallels and use Windows 10 for ARM, then you may be able to run something like vSTARs, vERAM, or CRC when it comes out. Ross would be able to chime in more on this to say which clients would work through that.

If you're running an Intel-based Mac, you could still use VRC via Crossover if you want to stay solely Mac Native. Otherwise, you can run anything like VMWare Fusion, VmWare Workstation, or use BootCamp and load Windows onto your Mac and use any client you'd like.

BL.

Wow.. and with no hint of sarcasm or cynicism, I have to say that here we go again with this thread. Not that it is tedious or to gather a ton of groans, but that if it is being brought up again, it is important and something needs to be done. What that something is is the question.

A lot of what was mentioned in this thread and in the other thread was visited a number of times over the past 20 years. The PRC. VATSTAR. Training Academies. Opinions vary on the successes of those, but if the problem still persists to where 20 years on we are still talking about the same thing, the  the same things we are trying and expecting a different result is what is known as Einstein's Definition of Insanity.

Now, not all is doom and gloom, as I've seen some ideas here that should be taken into consideration. With that, let's dig in:

Possible Solutions:
- Pilot Deviation Reporting - No brainier and everyone above has indicated exactly how I'd go about it. Pilots need to be able to see it so they can learn and grow. Should be managed by the Facility with the ability to be elevated higher if further action needs to be taken.

I really like this idea, as what we should be able to do is if there is a problem, ATC should have a way to log that problem and submit it to the top brass (SUP and above), who should act as the moderators of that. They then send a "please explain" or similar type message to the pilot, either allowing the pilot to explain their side of things or a "these are the rules, you need to be reminded to follow them", etc. In short, SUP and above are the FSDO.

- Pilot Rating System similar to Pilotege - Their system works. What I like most about their system is you don't have to use it, but you better be good. If you are not good, use this program to get good. Oh by the way, no exam, just get on the network fly and prove that you can perform with a entire network of people around basically 24/7 to help you understand complex concepts/material.

Keith expanded on what we already had here at VATSIM at the time (Keith was the ATM of ZLA here), so he already knew what he wanted to do, but took it more commercially. We could do similar here and should. The issue here is that the ratings system was relative to what the pilot was learning at the PRC, but apparently, the PRC wasn't taken seriously among the rest of the network; it was a recommendation rather than a requirement, because there has been the longstanding ... well.. "common knowledge" (lack of a better word) that anyone should be able to join the network as a pilot, regardless of experience, as this is a learning environment. And while I get that, understand that, and agree with that, we need to hold that learning environment accountable. There needs to be a way to validate that that learning is indeed happening.

- Controller kill Pilot capability - Remove the problem child when they are a problem (even if not on purpose) and file the report. Maybe they didn't know, but now they do and everyone can learn and grow. The reality is SUP's (to no fault of their own) are poorly equipped to actually decide if a pilot is worthy of a kill as it relates directly to air traffic operations in a "timely" and fair manner. The best equipped people to decide that is the facility. Guy who's frame rates aren't cooperating, kill. Guy who spawns on runway, kill. Guy who leaves computer 20 miles from the field on final freq, kill. File the report. They learn, your scope is manageable again, everybody happy. I imagine the process of the ".kill" is probably more complex, but you get the idea.

I want to say that SUP and higher have that ability, but I can see where as a controller, that ability can be abused. For example, if you know of a certain person that is known to cause trouble on the network, hasn't done anything wrong, but you just don't want to deal with them, having the ability to boot someone off the network just because or out of spite can cause issues that VATUSA doesn't want to deal with, let alone VATSIM as a whole.

I see pros and cons to this, and why it is limited to those SUP and higher. In fact, I've only seen it used twice while controlling: once by Harv or Amy, and the other by GSM, when some idiot using FS2000 wanted to joke around and crash into the WTC.

I realize that in practice, this is a gross oversimplification of what would be required to establish such a system and VATSIM/VATUSA has come such an incredibly long way over the last year. Most of what needs to be said has already been said and I ultimately want to provide my +1 for this issue.

This wouldn't be that hard to do, as it basically requires a way at the controller client level to be able to log the session (this becomes "the tapes") so that if any pilot deviations occur, they can get sent to the SUPs to be handled. The only drawback with this is that that logged session wouldn't include any logging of voice comms, unless those could be logged at the voice server level (I haven't looked into AFV to see if that's possible). If it is, that's okay. Additionally, the handling of this would have to be at the division level, because a SUP at VATRUS, VATKOR, or VATSA wouldn't have a clue about what we are doing here.

Hey everyone,

*  Pilot fails to contact me in a timely manner.
* Pilot has a language barrier and is unable to contact me in English when the language of the air is English.
* Pilot fails to turn in a timely manner after requested to turn by a controller.
* Pilot fails to understand what "Hold for Release" means
* Pilot doesn't understand that PDC commands via PMs are NOT CPDLC systems and attempts to contact me via telex and uplink messages.

Daniel Kormendy

This brings up another good idea. Pursuant to the Pilot Deviation idea above, one thing that the VATUSA brass could also implement is a "suspension" (again, lack of a better word) of an offending pilot's use of the network pending a slight variation of an Operation Raincheck.

Seeing that all pilots have the OBS controller rating, should they commit an offense more than a couple of times (those offenses being reported; see above), they can not fly on the network until they've visited the ARTCC they've had the problem in, if not the staffed airport in particular to see what the SOPs are for that airport and seen them in action on the network, on the scopes. Yes, this would require them to have a simplistic ATC client installed (shout out to VRC for simplicity) so they can observe the controller and what they should be doing that conforms to SOPs and pilot expectations on the network. This could even be a Sweatbox session or something similar; it just has to be something where the pilot gets a crash course in the area they are having trouble in, and also so they can see how whatever problem they are creating cascades down to others having a problem, which in turn makes everyone's enjoyment of the network turn belly up.

Now, language barriers we may not be able to handle, and quite honestly, that isn't our fault, nor the fault of the network. I've controlled pilots from Japan and Malaysia who could understand English better than they could speak it, so I couldn't fault them for if they couldn't understand what I wanted them to do. All that could help that is patience and giving them the time to set up for what they need.

However, the others fall back onto training and being able to look over the controller's shoulder to see what should happen when it is done right versus what they are doing wrong. They can take that into account, apply it, and they are on the network again. Again, that's logged on a private part of their record (only SUP and higher would have access to that), so should they commit an offense again, they get a sterner warning from the brass; after that, suspension or sacking from the network.

Now, finally, the only other thing any of these (not just my) suggestions need to take into consideration, is that some of these changes would be global, across the entire network. So every division let alone the BoG would need to have buy-in on it, and that is even if their region isn't having such a problem. So it's a big undertaking for us here, but any suggestions would need to be run up to the BoG for those to occur.

BL.

Is the sector file located at ZDC's site? I still have Crossover running on my Mac (OS X Sierra), so I can give it a try and see if it is what you are doing, or the file that is the problem.

BL.

Really good post here, Shane!

One thing I will say, however, and this is completely tongue in cheek, is that at ORD, you have it easy!  Let me explain.

With how ORD has changed so much to keep nearly every runway parallel in an east/west configuration (I think barely the 14/32s and 4/22s are still there), you've increased effeciency for the number of arrivals and departures that can come in, as they are all based in a single flow. The downside to that, as you've mentioned, is the in-trail separation needed for departures with the same SID.

When you have simultaneous converging runway operations with parallel runways, you can get that separation implicitly applied, while splitting the cramming of so many arrivals down the same runway by offloading them to the other set. For example, KLAS.

When in configuration #1 (landing 26L, departing 26L/R and 19L/R; we have 4 different setups there) there is one particular SID that only departs 26R and requires a right turnout (STAAV8), whereas everything else departing 26R requires a left turnout. That means you can implicitly get that in-trail separation for two STAAV8 departures by having a departure launch from the 19s after the first STAAV8 departure is airborne. It takes sequencing this at the ground level for this to be accomplished, otherwise every other aircraft would be waiting for that same in-trail separation to take off, creating that delay. So the sequencing at that level is very important. Also, the good part about that, is that while that departure off the 19s is on its takeoff roll, any arrivals that just landed on 26L can safely cross 26R, so they aren't waiting either. Now, this isn't to say to just send all departures except STAAV8 to 26R and all other departures to the 19s, as you'll still have in-trail separation on the other SIDs, wake turbulence, arrivals crossing, etc., to deal with.

Another example. In Configuration #3 (landing 1L/R, 26L, departing 1L/1R; 26R is closed/taxi only, owned by GND), we're limited the most by the airport layout for most taxi instructions. If you're on the GA side of the field (west of 1L), you'll have easy access to the runways, but the main terminals are east of 1R, so they will all have nearly the same taxi instructions, including crossing 26R. But because of this configuration, you're going to have more in-trail separation to deal with, as well as the parallel runway ops we see at JFK, ORD, LAX, and the like. So what we can do in this case is separate the departures by the turnout they have off of the departure end. For example, all of our southwest/northwest departures (BOACH,SHEAD,MCCRN) can be given 1L for departures, while everything southeast/northeast/east (TRALR, HOOVR,COWBY/LAS) can be given 1R, and both 1L and 1R departures (especially if RNAV) can be simultaneously launched. This way, you're maximizing runway efficiency for both arrivals and departures, instead of having only one runway for arrivals and one  for departures.

It's in a setup like this that I'm actually happy that LAS isn't going to a single flow setup for traffic, because we wouldn't have all of these different ways to organize traffic (I'll save Configs #2 and #4 for another post).

BL.

Will anyone mind if I grin evilly while stroking the back of the purring cat sitting in my lap and remind everyone of the time that we completely closed KLAX (left it unmanned and completely unstaffed) during California Screamin' II? We actually outdid our numbers between ZOA, ZLA, and ZAB compared to the first CalScream held the year prior, and since everyone only thought it was a huge LAX fly-in, we closed it, and denied any services to/from the field. Pilots treated LAX as closed (with full on CTAF), canceled their flight plans with us in the air or on the ground, and picked up IFR in the air with us should they have needed it. Anyone wanting IFR practice approaches or services went to the next closest Class C or D airport.

Ahh yes... Good times there indeed... now.. can someone put a cucumber on the floor behind this cat so it can get the heck off my lap? 

BL.

Very good topic! I was taught that an APREQ is required if you amend an aircraft's flight plan and it affects the next controller. I look forward to hear if this is actually the case since I haven't been able to find any official rule.

This brings up another question: does APREQ for a shortcut really modify an aircraft's flight plan? For example, let's say I have the following plan from KOMA-KONT:

CATTL2.LNK J60 NATEE.JCKIE2

If the aircraft is already on J60 (which they will be when they cross LNK), would sending them direct NATEE amend their flight plan? NATEE is on J60. I ask, because a shortcut could be sending them directly to a fix that is already on their flight plan, or covered by an airway that is in their flight plan. That is different from say, needing to send them to a new transition to a new arrival to a field that is different from what they filed. That would require an amendment.

BL.