VATSIM Updates the Code of Conduct effective October 1, 2024

We are pleased to announce that the VATSIM Code of Conduct has been updated. These updates will officially take effect at 0001z on October 1, 2024.

Most of the changes in the new Code of Conduct (CoC) are designed to clarify existing practices on the network, ensuring that both pilots and ATC operate in a more structured and prepared manner. Key additions include prohibitions against providing false information to VATSIM staff, improved instructions for pilots regarding code usage during flights, and an emphasis on familiarizing oneself with local airspace procedures when flying in foreign regions.

A few significant updates include new controller suffixes, changes allowing observers to use towerview, and updates to surveillance codes for flight plans. Additionally, there’s now a requirement for pilots to ensure they understand local procedures, particularly when flying in unfamiliar territories. For instance, if you’re a US pilot flying in the UK, it’s your responsibility to understand the procedural differences.

Other terminology updates have been made, such as replacing “unicom” with “advisory frequency,” and clarifications about pilot behavior, like avoiding distractions while connected to the network. Additionally, pilots are now expected to monitor and use the guard frequency for emergency communications or when out of radio range.

Find the summary of the upcoming changes: here.

1 Like

Is the word “ramp” official in FAA docs, or is it really just a US colloquialism? The word “apron” seems more official, and is used outside the US. Also, outside the US (at least in the UK to my certain knowledge), the words “guard frequency” are simply not used.

hmmm, all my European colleagues know the term “guard”, as we always hear someone meowing on the emergency frequency and then someone else yelling “you are on guard!”. Every single day.

PS: it would not hurt mentioning 121.500 as the guard frequency.

With the expectation of pilots monitoring guard (121.5MHz) will vpilot be enhanced with a 2nd PTT and the ability to work both radios at the same time (aka w/o the cli switching)?

1 Like

Tbh I don’t know if ICAO refers to guard.

It would have been nice to see a draft a few weeks ago for consultation and feedback rather than seeing the final version only 3 days before it takes effect.

“pilots are now expected to monitor and use the guard frequency for emergency communications or when out of radio range.”

However the linked post says “Pilots and controllers are encouraged to monitor Guard when possible” and the actual CoC says “may be utilized in accordance with real-world procedures. Pilots and air traffic controllers should monitor Guard if able.”

Please clarify as these are contradictory.

Also ICAO does not use the term “guard”, it uses “emergency frequency”. The CoC should be corrected to reflect ICAO terminology.

There should also be a clause that meowing on any frequency may lead to disciplinary action.

1 Like

It doesn’t. It’s called “aeronautical emergency frequency” in ICAO documentation.

2 Likes

To be fair, this has unfortunately been a constant theme with recent policy changes: the general membership (and even (sub-)division staff, to a large degree) is completely excluded from any discussion with the new/revised policy afterwards being presented to them as a fait accompli with little to no willingness on the side of leadership to make any further changes for the time being - usually with way too little time to implement all necessary changes and/or inform at least the majority of the membership by the time it becomes effective.

In the new CoC alone, there are so many seemingly arbitrary, unnecessary, or overly restrictive changes while other things that are regularly causing issues on the network are not being addressed - and don’t even get me started on GCAP or TVCP…

  • The definitions section does not include a definition what an “account holder in good standing” is, but instead defines a bunch of basic English vocabulary such as “not” or “may”.
  • A4(c) would really have benefited from a change to give actually useful tips on how to inform ATC that you are a new user because the last thing you’ll look at as a controller is the name the person logged in with; many places (at least here in Europe), however, have ways to check item 18 of the flight plan for words like “new”, “newbie”, “rookie”, etc. and then automatically display an icon above the tag to indicate when one of these words has been found - and of course adding a quick “new pilot” or similar to your initial call with a new station would invariably convey that message to ATC.
  • A12 would have benefited from some form of description what types of callsigns/identifiers are being talked about
  • A13 would certainly also have benefited from additional clarification, seeing how the question whether certain types of operations or aircraft are permitted crops up once or twice every week.
  • A14 should also have been updated. Particularly in the increasingly busy areas of the network, it’s becoming more and more of an issue to provide equal service to text pilots. It really should have been clarified if controllers are expected to always provide equal service to text pilots (and as a consequence log off if they are not able to do so) or if it is permissible to, e.g., put a text pilot in a hold somewhere until voice traffic numbers have reduced to a point at which the additional workload of controlling via text can be accommodated. Likewise, a note to inform pilots that text communications are a significant increase to controller workload certainly also wouldn’t have hurt here.
  • B4(b) is really unfortunately worded. On the one hand, it uses “should” which makes the entire rule a suggestion and thus technically makes it permissible for pilots to arbitrarily change their squawk, on the other hand it doesn’t acknowledge cases where pilots are required to change their squawk without being instructed to do so (apart from changing flight rules, although at least here in Germany, you still have to get an appropriate instruction from ATC before you are allowed to change your squawk code), such as squawking 2000 30 minutes after entering NAT. A wording along the lines of “A pilot shall maintain a previously assigned squawk code unless otherwise directed by ATC or a procedure” would have been more apt.
  • B5’s interpretation relies heavily on how the word “or” is interpreted (both an inclusive and an exclusive interpretation of “or” are possible, as is so often the case with this word). I assume it is meant as an exclusive or, i.e. pilots have to figure out whether there is a designated advisory frequency and only if there isn’t use 122.800; however, it would also be perfectly reasonable to read it as an inclusive or which would allow pilots to use 122.800 everywhere at all times while not under ATC and make use of a designated CTAF optional. With how many complaints about pilots being on a bunch of different frequencies since the start of the CTAF trial, B5’s wording should really have been revised to something unambiguous.
  • B7 could have benefited from clarification whether ATC can dissolve a formation whenever or only when the formation is under ATC (e.g., what about a VFR formation in airspace E or what about an IFR formation in airspace G?)
  • B2 and B9 should have been made consistent. Why are pilots not permitted to just pause in Unicomland as long as they ensure they “do not cause any disruptions to other account holders”? Or the other way around: why are pilots permitted to use time acceleration/decelaration in Unicomland but have to disconnect if they want to pause? To tie into what the companion document for the current CoC says in regard to B2: How is it any more difficult to gauge who pilots may affect and how when pausing compared to using an acceleration or deceleration function (especially when considering that deceleration functions may well have the exact same effect as pausing the sim)?
  • B10, similarly to B4(b) doesn’t acknowledge real world rules. There are many cases where VFR flight plans are required IRL, yet the CoC doesn’t compel pilots to file a flight plan in these cases, while on the other hand requiring users to always file a flight plan for IFR flights even though there are various places where IFR flights are not required to file a flight plan in some cases. A wording more along the lines of “All pilots shall submit a flight plan before their flight if required for the planned flight” (there’s probably a better way to word this, but you get the gist) would definitely have been an improvement.
  • B14 seems a bit out of place as a separate rule - I feel like it would have made more sense as B8(d). However, my main point of contention here is that pilots not having the latest AIRAC has rarely been a problem. Unless a pilot is using ten years old nav data or procedures at a given airport/structures in a given airspace have recently seen a major redesign, it has usually been possible to find an adequate alternative solution - provided the pilot communicates this, of course. While I welcome the idea behind this rule, I feel that it could have been made less restrictive to pilots who may not be able to pay for a Navigraph subscription to keep their nav data up to date at all times (sure, MSFS2024 will always use the latest nav data, but not everybody will be using MSFS2024). I feel like a rule similar to B6 may have been a better compromise: permit pilots to use out of date nav data, but require them to disconnect if ATC can’t accommodate them without the latest procedures, as well as requiring pilots who are using outdated nav data to check beforehand if there are procedures they are not able to fly and inform ATC accordingly in advance.
  • C8 still heavily restricts the vis range for ADC positions, particularly DEL and GND. In many places throughout the world, the primary task of the Delivery controller is not to hand out the enroute clearance, but to manage the outbound flow of the airport based on current operational restrictions and, importantly, the expected amount of arrivals. With just 20 NM vis range, this is effectively impossible as you may not even be able to see the entirety of the final (thus, when we are fully staffed with two Delivery controllers, one exec, and one planner, the planner will connect with a Tower suffix to be able to use a reasonably workable vis range). Raising the vis range for DEL - and for top down purposes also GND - to be the same as for TWR would go a long way in ensuring DEL can plan an appropriate outbound flow to reduce delays and complexity.

I know that for at least some of these points, the current and presumably also the upcoming updated companion document already provides the answer/clarification/specification, but the companion document is - to my understanding - not required but just optional reading, so anything important for the interpretation of a given rule should not be found only in there; instead, the companion document should only add additional context or give insights into the reasoning for the existence of a given rule. If I’m wrong and members are indeed expected to know the additional details put forth in the companion document, I would have to wonder why we even need the shortened “normal” CoC.

1 Like

Why such thing if that is not a behaviour in any aircraft ?

1 Like

Once again, please clarify whether pilots are “expected” to do this (per your post) or “may” and “encouraged” (per the actual CoC). Also please clarify what emergency communications would be used on this frequency. And finally, please remove reference to “Guard” as this is not an ICAO term and has no meaning in most of the world.

1 Like

Simple question - what am I expected to “monitor Guard” for and why? “Emergencies” are imaginary so I’m not going to “listen out” for them, there is no point in doing so.

2 Likes

Honestly, I read through it & didn’t notice anything different than what we’ve been doin.

“Ramp” is the official callsign of such controllers at the larger US airports, but those towers are not staffed by FAA personnel rather they’re employees of the airport authority or the airlines. I imagine it’s the equivalent of your “Apron” controller, but I don’t know how those facilities are staffed in other places.

Guys, you want to operate on VATSIM “as real as it gets” and at the same time you refuse to use “guard”: in the real world we all have to monitor the emergency frequency whenever feasible. Period.

Once again VATSIM makes apparently important announcements, that affect us all, at the very LAST minute before any of us can make timely comments, or suggestions.
I have to wonder whether VATSIM is endeavouring to turn our hobby into a professional activity. Will it be telling us (it doesn’t ask does it?), at some point in the future, that we will need a full licence, with an IFR endorsement, to fly an aeroplane on the network? Because that is where the people in VATSIM’s ivory tower appear to be leading us to.

2 Likes

I do NOT object to using the emergency frequency. I object to it being globally called by an unofficial title (guard) where the official ICAO and FAA use of “guard” applies only to the enhanced area of separation from other frequencies. And pilots shouting “You’re on guard!” does not make its use official.

I also object to the enforced globalisation of the US - only word “ramp” which is a term used by subcontractors in the US and not at all in the rest of the world.

1 Like

I know. But: with a little bit of experience everyone who is involved in aviation knows that “guard” is in fact the international emergency frequency 121.500. I have yet to come across someone (both IRL and also here on our network) who does not know what “guard” means. I hope this did not catch you off guard :stuck_out_tongue:

There’s no ivory tower. There’s a set of volunteers who chose to donate their time and effort to administrate this network, they are responsible for it. They normally do not take decisions lightly and would have discussed about these changes beforehand. One could argue that some changes happen with too little time to prepare, but in this case I do not see overly critical items that would infringe with anyone’s online experience.

But as I mentioned above, the people who manage VATSIM cannot make it right for everyone, there’s always someone who will be unhappy, no matter what. In recent months and years a lot of members are calling for more realism. Now we get it and it is not received well. Really?

EDIT: if you are not happy how VATSIM is run, get your hands dirty and apply to become a member of staff. Otherwise we are all just guests in this network. It is a very nice network and someone has to take decisions every now and then. Life goes on.

Similarly, everyone knows what “miaw” is. Does that make its use acceptable?

1 Like

Looks like someone accepted our suggestions here and made a compromise!

Guard Frequency Usage: Monitoring and using 121.500 MHz (Guard) is encouraged for emergency communications, aligning with real-world procedures.

1 Like

Civil aircraft might not be able to do it (though I daren’t speak about ALL aircraft), but military aircraft usually have two or more radios (usually one VHF, another UHF, but there can be more than just one of each, and sometimes SAT comms in more recent aircraft / upgrades) that they can use simultaneously.

E.g. F-16 communication switch, and data entry display (DED)
image
image

They’ll not uncommonly also have a “hidden” radio (can’t be interacted with by the pilot) that is always monitoring 121.500 and/or 243.000 MHz, even if no other radio has it selected.

I don’t think the 2nd PTT to use the second radio is a requirement wrt the addition of the emergency frequency on VATSIM, but in general, it is definitely a useful function to have.