All Activity

Version 2024/04 Available A changes only version is available here. ⚠️ You must update your sector file and controller pack to ensure correct sector ownership and sector file identification when controlling. ❗A small program (Logon Details.exe) is now included in the main ‘UK folder’ This will insert basic user data into all required files, making installing and updating easier than ever! Run this program before opening a profile. Installation Instructions The pack is compatible with EuroScope 3.2.3 which can be downloaded here. You should install in the default 'working directory': \%appdata%\Roaming\EuroScope Please read the README contained within the pack for full details. We continue to work with Gergely to test the latest version of EuroScope (3.2.9) However, at the time of writing we cannot guarantee it will be stable. Please keep an eye on Discord announcements for the recommended ES version.

Effective 18 April 2024 Fairoaks Information (EGTF_I_TWR) has now been downgraded to Fairoaks Radio (EGTF_R_TWR), hence Aerodrome Flight Information Services (AFIS) should no longer be provided, and instead Air Ground Communications Services (AGCS) should be provided. The frequency remains the same, 123.430.

2024/04 Released! --- AIRACs: --- 2404: Changed Fairoaks (EGTF) positon from FISO to A/G Updated Benbecula ATIS frequency Updated Birmingham (EGBB) SMR WIP areas Updated Bristol (EGGD) SMR, added new holds and stand Updated Ronaldsway (EGNS) SMR 2403: Added Coventry (EGBE) 05 stopway and Updated SMR 2401: Updated Stansted (EGSS) VRPs --- Other: --- Bug: Removed danger area EGR612 Arbroath Enhancement: Added Thruxton (EGHO) Heli Aiming Points Removed spaces in danger/restricted area file names --- Many thanks to our contributors this cycle: --- @Luca Kulaga Abdullah Shahid @Christoph Reule @Alice Ford Ben Walker @Oliver Cesarczyk

Having had this discussion, I'd been planning to keep tabs on how many 'infractions' I typically get, and submit them 'en-masse' to the SUPs to help raise awareness of the scale of the issue (which I think was Adam's aim). I didn't think .wallop -ing someone for taxiing the wrong taxiway to the wrong gate appropriate, since by that point they're not impacting anyone else and was probably a genuine mistake (we all make them). Anyway, when I looked into how I'd submit this I see "VATSIM does not have interest in policing petty matters on the network. Issues that are minor violations or personal in nature, should not be reported via this ticketing system. Reports should not be made unless evidence is available & provided to support the allegations." I don't have evidence I told a pilot to taxi left not right. I can't evidence that they went the wrong way. I had a poor pilot ruin my flight earlier, I wrote a lengthy .wallop, sent it - no SUPs online. Directed to the ticketting system, but how can I prove they weren't complying with ATC's instructions and getting in everyone's way and using frequency inappropriately? Feeling frustrated. I want to help raise awareness of the issue but it seems from reading that SUPs don't want to know. P.S. averaging >2 CoC breaches per session so far. And that's just quiet ADC stuff.

As a fairly new S1, I've used .wallop around 4 times with pilots who taxi on their own accord or are not capable of reading back instructions/clearances and then affect other pilots as my time is spent on the pilot issue. I have to say that a Sup has connected everytime, asked again the problem (another type up) and I've left it with them with a comeback of "It's been resolved" with a couple of sentences by the Sup that they've advised to go to observer mode and listen to the frequency or they've disconnected them. I agree from others, a summary of what the Sup has done would help and improve confidence with controllers when requesting a Sup of how it's been dealt with. Voice contact with the Sup would certainly assist (where applicable/language) in quickly passing the info over and then being able to concentrate on the other pilots without them being held up as its others that are affected. If it's quiet, I have no issues in giving advice to new/lack of confidence pilots (as we all started there at somepoint) to boost their confidence and wanting them to keep coming back to VatUK but the general standard when starting on Vatsim needs improvement.

I completely agree with everything that's been said so far. Personally I've always been very reluctant to wallop pilots, apart from those egregiously breaking the code of conduct or intentionally trolling, because of the negative perception. We're obviously reliant on there being a good number of knowledgeable pilots on the network to control, otherwise we'd be wasting our time. I'm always conscious that pilot's that are sub-standard today could become consummate pros with a bit of time and practice provided they're not put off flying on the network. Of course that practice doesn't have to be, and sometimes shouldn't be, on the network. I think the reason I'm so hesitant to wallop is because it's seen as something overwhelmingly negative and so I feel using it carries a non-negligible risk of permanently turning pilots away from flying online. The terminology (supervisors, wallop, the standard "I'm one of VATSIM's supervisors..." message etc) are somewhat threatening and you commonly hear of supervisors in relation to them having kicked or banned a pilot which is likely to further intimidate new pilots. I also think there's a bit of a natural power imbalance between controllers and pilots given controllers are essentially there to tell pilot's what to do and to my knowledge the wallop is utilised significantly more by controllers against pilots than the reverse. This makes sense given the high barrier to entry and threshold of capability that controllers are held to but it feeds into a possible perception that supervisors are there to help controllers deal with 'irritating' pilots rather than to help the pilots themselves. Therefore, when a controller mentions that they will or in fact does call a supervisor to help or otherwise deal with a pilot, it would be understandable that the pilot might think they're in trouble and that their vatsim account could in jeopardy. Of course, when a controller wallops a pilot, they often do need a rapid resolution which makes this a difficult problem to solve. Just completely off the top of my head, and I appreciate this can't happen short term so perhaps isn't what you're looking for, but if we're going to be walloping more frequently for smaller issues, maybe there could be an alternative to a wallop? A different command which is broadcast to supervisors but indicates that a pilot isn't causing an urgent and significant problem but just needs assistance that I as the controller might not have time to give while the wallop could remain for the more disciplinary related situations requiring an immediate resolution. This might also help to get away from some of the stigma currently associated with being walloped.

Yeah, that was my understanding of the term, but as I say, whether that's the way everyone understands it, I'm not always so sure. It's commonly worked into sentences in such a way as to imply the other meaning

This is really interesting. Some great points. I'm not a controller so forgive my six penn'orth. As a pilot I find the behaviour and low competence of some others frustrating and annoying. If all the points above, a couple really strike me as important. First, that wallop is an inherently aggressive term and that maybe Sup, or Help or something similar would be better suited to the situation if we're trying to maintain a positive environment and have a good effect. Second, that supporting your team is a fundamental part of good leadership and I detect a lack of confidence in parts of the Vatsim system in this thread. I'm very glad that Adam is taking a strong lead here, and hope the powers that be take this seriously and act.

"wallop" is short for "write all operators" - its origin was from IRC back in the 80s and 90s. 🙂

I think thats a lot of it. From talking to the newer controllers during events and other things, there appears to be a reluctance to use .wallop, now whether this is because they don't have a complete understanding of what happens when the command is sent, they're not sure of how much a Supervisor can do, or, they don't want to get anyone into trouble. Unfortunately, the word 'SUPERVISOR' does a lot of the heavy lifting here. People see/hear that, and are immediately on the defensive, I've seen posts on social media and other sites where pilots have had Sups called on them, and, they're immediately defensive and more 'I know how to fly my aircraft, I should be left alone', than, 'I welcome the support'. Perhaps an education towards both pilots and controllers is something that is needed, I know there have been efforts made in the past to try and help everyone understand the remit of a SUP and how they can support people, but, perhaps a change of title to 'Online Support', but still using the SUP callsign could change the image that some people have of the group.

Just so those monitoring this post see this, a pilot didn't wait any longer than 3 minutes for any form or clearance or instruction but was not patient enough, departed on Unicom so therefore I couldn't even talk to them on the freq. For additional context this pilot was departing from EGBB and I was on Central, there was an East Midlands Radar and a TC Essex at around 1330 local time today, so the sector was no where near overloaded. I called a supervisor to which they allowed me to get back in touch with the pilot but seems that no punishment was put on the pilot at all. I then had a ridiculous argument with them over PM which I admit, I shouldn't have got involved in. But the pilot claimed they waited over 5 minutes for clearance which was a blatant lie, the logs I saved proved that they didn't wait any longer for 3 minutes for anything (or 3 minutes and 18 seconds). Here is what I sent: I noticed they just departed when I was about to get back to them at time 1253z! I think the key thing that got to me here is the gross and blatant violation of the CoC with 0 repercussions, the pilot LITERALLY got away with doing whatever they wanted! Also, the way SUPs deal with things is so inconsistent. Sometimes you get someone who just responds "on it" and the plane disappears from the radar. And other times the pilot just stays there and the SUP at best has a word with them. That then sets the idea to these sorts of pilots that they can depart without talking to ATC, all they get is a word from a SUP but they still get to fly even though they just blatantly violated the CoC (like this isn't an issue with "new pilots," experienced pilots tend to do this more, because they know they can get away with it) and skipped the waiting bit! I do hope that with the spotlight on pilot quality these issues can addressed, and overall the quality on the sector for everyone else was acceptable, it's just this one pilot that can ruin it (or "knacker your evening") by just doing whatever they fancy.

I wonder if there's any stigma/misunderstanding associated with the name of the command? I often see talk of "walloping" someone, which kinda implies something other than getting help. I don't know if this sometimes gives an impression that it, and the supervisors it invokes, are there for getting someone into trouble/kicked off/banned rather than to provide support and assistance? I think it's an unfortunate clash between the English language and what I understand to be derived from an IRC command. Perhaps something like .sup would have fewer connotations. As a new S1, I've felt like it had to be quite a high bar to justify .wallop - seeing this forum post has encouraged me to use it where I might not have done previously.

Just tried it out myself when I knew there weren't any online and it does work - its possible that Euroscope shows it in the SERVER tab of the chat, rather than in the active SUP window which pops up when you issue .wallop

My reasons behind shying away from using .wallop often are mainly the response I’ve got from some supervisors they usually fall into two categories; 1. I’ve typed out a detailed .wallop while busy in the hope that the supervisor can just deal with the situation, but then I receive a message saying hi and asking how they can help/what the problem is. 9/10 my reply is retyping what I said in the .wallop string. this is frustrating when you’re busy and a pilot is still causing issues. 2. Just a lack of help from the supervisor, more often than not if someone is ignoring .contactmes on the ground and just freely taxiing and departing the response from the Sup by the time they arrive is that they’re no longer causing an issue as they’re in the air with no area controllers on so nobody to upset - but we all know if they’ve not spoken to ground or tower then they’re not going to use Unicom and they’re not going to speak to the controllers at their destination.

As a fairly new controller, it took me a while to appreciate why it was a good idea to use .wallop with less than proficient pilots, and it was largely down to @Adam Arkleyinsistence on Discord that made me confident to use it. However, the response from supervisors, when online, has not filled me with confidence, and the impression I currently sit with is that they view their job as done if/when the problem pilot disconnects. I appreciate I don't see what they may, or may not, do subsequently, but more than once the supervisor has taken a while to respond and their response has been "they've disconnected now so have a good session". It would be reassuring if there was some form of feedback that let controllers know that something was done with these miscreant pilots. I appreciate we wouldn't get (nor would I want) chapter and verse of what was done, but some form of feedback would be good.

Now that I have a bit more time, I want to deal with some of your comments here specifically. 1) I completely agree with the desire to help and on occasions where you have capacity to do so, then that's fine to a degree. But, to directly relate that to 2), 6) and your summary after your numbered list, it's critical that we flag cases where support is required for pilots in order to paint a picture of how the P0 test might leave something to be desired. We cannot complain that P0 is not doing enough whilst simultaneously hiding the extent of the problem. To that end, it isn't our responsibility as controllers to be teaching pilots and I sort of encourage that we stop! 3) I will flag this for attention. This isn't acceptable. 4) I sort of get this; I get notified by a supervisor if someone is removed from the network, generally, However, we have to question the morality of us knowing the ins and outs of every conversation that a supervisor ahs with the subject of a wallop. What I will suggest to the Region is that we get some summary of supervisor actions per period and hopefully this will give people confidence that Supervisors are, in fact, acting. 5) This is the key issue. This is why we must wallop. We have to play the long game - if you wallop and nobody is available and we can demonstrate that routinely, that is evidence to VP SUP that we need more supervisors. It should not become our problem, in any way, that a supervisor is not online to help - VATSIM is a global platform in use throughout the day and it is incumbent on the network to ensure that we have suitable resources in place to ensure the enjoyment of the network for all involved.

Pretty much every reason - especially 1 and 2 - Peter gives is why I sometimes won't use wallop, some anecdotal stuff: Basically, pilots who need help are scared of supervisors, pilots who cause major disruption are not, and cannot be dealt with in a timely manner by supervisors - which I don't think is an issue with individual SUPs but just the nature of the time sensitivity of most problems that arise, I'm not sure I could do any better than them honestly. In recent times whilst private messaging inexperienced pilots who I've been assisting - when I'm quiet enough to help but busy enough that there's some delay to my support. I'll let them know they aren't in trouble but I'm going to asking a supervisor to get in contact with them to help them since I'm getting busy and won't be able to respond quickly. The response to this is overwhelmingly negative - often in the form of disconnecting or aggressively apologising to me and asking if they could stick with me instead. Doesn't matter how much I stress they're not going to just be banned. Overall, I find - as ADC - wallop useless at helping me resolve immediate problems. I need the time immediately after someone does something wacky like slewing across the airport taking off on the opposite direciton runway without a clearance or totally missing the departure procedure track to actually react to what I'm seeing, resolve the conflict and coordinate with other controllers, and then catch up on all the stuff I should've been doing in that time. By the time I've done all that walloping feels redundant, the pilot's flying off into the sunset, possibly even complying with London Controls instructions. I may also have to explain local procedures that the supervisor through no fault of their own is not familiar with that are relevant to a scenario. If the pilots off halfway down their SID I can't even answer the question I get everytime about whether pilot is complying now or not. Minor point, but explaining the scenario 5 mins later also makes me stew on what happened, and makes it harder to just move on and continue to enjoy my session and not vent at other pilots who're making small mistakes, perhaps a personal failing by me but still relevant. Maybe the ability of supervisors to more easily use some form of voice communication when talking to controllers would be helpful? (Is controller-controller communication in AFV still planned? something similar to that if it ever appears?) This would remove the text communication delay and resistance, I guess language barriers and such would still be an issue though.

I've not seen the message come through informing that there are no supervisors online, however, thanks for taking the time out to reply.

I'd also agree with what's been said here. I find that (specifically from a ground-based perspective), I almost always have time to send the pilots some links to help them get started, give them some videos to watch, etc. The times I use `.wallop` on the ground are almost only when either: - A pilot actively does something to cause a mess, for instance randomly pushing or taxiing without talking to me - A pilot can't effectively communicate in English (either due to a different first language, or, more commonly, a stuck or broken mic). In these cases what I want to convey is more of a 'please get off the frequency' than 'please get off the network' - they may be a good pilot, they may be willing to learn, but there's pretty much no way I can communicate with them. Outside these I normally just try to help, however I do understand that that could have ramifications further up the food chain, especially for enroute sectors.

I've never seen this myself, Phil, but I've never correlated it with no supervisors being online.

I would largely echo Peter’s comments. i generally only make use of Walloping if I feel I am actually unable to deal with the pilot myself. I’ve probably used it on about 5 pilots in the 3 years I have been controlling. The most recent was a pilot with an open mic that had ignored 3 messages telling them so. the primary reason is that all you tend to see from it is a delay and then told that they have been removed. This doesn’t feel like it’s really helping a pilot improve and may put off those that genuinely want to learn. I have no real sight as to how supervisors actually engage with the pilots we wallop so it still feels like a bit of a punishment.

The email has been replaced by the VATSIM support system - you can visit https://support.vatsim.net/ and file a report under "Network Supervisors / Incident Report" On the lack of feedback element, there is supposed to be an FSD message returned when you wallop, to inform you that there are no supervisors online. It should state the following: If this isn't being displayed when there are no supervisors online, I'll take a note to pick this up and figure out why.

Reasons I don't use .wallop (much): 1. Stigma - I don't want to scare off a new/inexperienced pilot. I will generally try to help them as much as possible myself, even if they fall short of the requirements set out in the Code of Conduct. I feel this can be less 'scary' for a pilot than the "Hello, my name is _ I am one of the VATSIM supervisors..." message arriving in the pilot client with three bleeps. I am also able to communicate over voice with the pilot to explain things better (AFAIK SUPs have to use text where tone etc could be lost). 2. Workload - As mentioned by Samuel, I tend to resort to needing a .wallop when I don't have time to help myself, at which point I'm close to task saturated before having to type out a .wallop, have follow up conversations explaining the situation, what's happened etc. 3. Poor past experiences - When I have reached out to SUPs in the past I haven't always been overly impressed with the responce. Some take so long to do anything about the issue the aircraft has taken off into your arrival stream of their own accord and left your AoR by which point the SUP is like "so they aren't a problem any more". (Note some SUPs have been fantastic and fast acting). 4. Lack of transparency - Perhaps things happen to guide erroneous pilots to resources that I don't get made aware of, but it sometimes feels the SUP is 'fire-fighting' and will disconnect someone in extreme circumstances, but otherwise there are no ramifications/help/support given to the pilot. I don't see what happens apart from sometimes a "I have dealt with the issue". 5. Lack of supervisor availability - SUPs are often not online, as you say these things are logged, but there is (selfishly) little benefit to me to do the .wallop at the time if there's noone to help me, and it will take time away from controlling the competant pilots to do it. 6. Supervisor burden - SUPs are often presumably dealing with multiple problems at once across the VATSIM globe, if I can deal with it myself why burden a SUP? I do (try) to use .wallop when I think someone is being mallicious or I'm too busy to 'babysit', and following your post will be encourged to use it more. ---- I think most controllers in VATUK have experienced bad or inexperienced pilots. Some controllers handle them better than others. Some SUPs handle them better than others. But are we looking at something which isn't the _root cause_ of the pilot quality issue, that anyone with no training following a very basic muli-choice test (AIUI) can connect as a pilot? Our controllers have hours of required self-study, training and practical exams before they can connect, pilots none. I am grateful this is being discussed, but I think it needs to be reviewed as part of a more hollistic approach to improving pilot quality (hopefully that's the intention!). P.S. I had a first time pilot on the network the other day who was near perfect! So I don't want to give the impression I'm complaining about 'new pilots' just the ones who don't know left from right.

Not entirely sure this is relevant to the blog post Rish, but yes. Pilot quality concerns are taken into account whilst mentoring.

Sometimes I also think that even if you have the pilots required for a busy session , you need to be sure that they are capable for example a Gatwick ground mentor wants a busy session for the person he/she is mentoring but then to only start realise that the pilot quality isn’t as expected. Are mentors looking at pilot quality constantly now for a more smoother run session?