All Activity

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

There will be an exam on Edinburgh Tower (EGPH_TWR) on Thursday 18th April 2024, commencing at 1700z. The exam is expected to last 90 minutes but the exam may end earlier/later, depending on whether the competencies have been sufficiently assessed. A good number of IFR outbounds as well as some IFR inbounds/VFR are essential to making this exam a success. Please, no funny business without first speaking to EGPH_X_TWR. Pilots wishing to fly to ensure that they are familiar with the pilot guidance for ATC exams. Good luck to the candidate!

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?

One reason I sometimes don't wallop (even when I want to) is workload. When I tend to decide to wallop, it's often because I won't be able to cope with a pilot at all and they need to just be removed (and pointed to some resources later). Having to type out quite a bit of text (so I can't be updating tags, and I can't be typing at talking at the same time) and wait for a response that might be too late anyways often make me just decide to focus on the traffic right now.

Hi Robert, Thanks for sharing, particularly publicly. Please trust me that I absolutely agree that there is a perception/stigma that if people wallop, nothing will be done and this was my first response to the Region when they brought this to me earlier today. I have long argued that the more we use the .wallop command, the more we illustrate that more supervisors are needed to deal with the problem. Not .walloping because there is a lack of supervisors isa vicious circle - unless we make reports, there is no evidence that more supervisors are needed! We must take the initiative - as we've been asked - and I strongly encourage you to .wallop when appropriate regardless. As I've said in my original post, all .wallop messages are sent to a central Discord and they absolutely will be seen. Cheers, Adam

The issue I have with this, and I'll post this here, instead of letting it get lost on Discord, is that a lot of the time, especially when theres no Supervisors online, the person .walloping gets no feedback in one way or another. You say that you've been asked by Region (I take it that this is VATEUR) about why controllers do not wallop pilots, from my point of view, there is no regularity of support for controllers/pilots. I get that, like everyone else on VATSIM, SUPs are volunteers, however, when a controller sees on pilot disconnected for poor behaviour/conduct, and this pilot then reconnects and does the same thing, with no recourse, is there any wonder why confidence and support is lower in VATUK? There used to be an e-mail address where controllers could e-mail supervisors with their concerns, that went to a global inbox, again so that Supervisors could deal with issues that arose when they were not online. I have previously raised concerns about pilots that way, and have had responses saying that things would be dealt with. The last time I tried to e-mail that address, I got a 'not available' return. Has this facility been withdrawn, or is it something the BOG are looking to utilise still. From our experiences in the UK, we know that poor behaviour increases on the network around school holiday times (not looking to apportion any blame, it just seems to be the case), however, the majority of Supervisors seem to be in different timezones on the opposite side of the world to us, and as such, support again, comes to a minimum. I know there are one or two VATEUD based sups, but, the last I was told, a SUP cannot be online at the same time as their main account (for apparently obvious reasons), and as such, the UK based SUPs are more focussed on controlling, and dealing with poor behaviour after the fact, than being available as SUPs (I cannot blame them for this, I'd do the same in the circumstance). Perhaps something needs doing from an overall level at VATGOV, as, theres been a lot of great work done promoting events for new pilots, and, from talking to those new pilots on the network, there are plenty that are willing and wanting to increase their expertise, but, are frightened/unsure of how to proceed. The advent of MSFS2020 (and the coming MSFS2024) seemed to catch VATSIM unaware, even with the 'tie ins' that they got. We don't want to be caught out again.

The quality of many pilots on the network is the subject of much discussion across VATSIM UK and other vACCs, Divisions and Regions. For as far back as I can remember, the topic has been present on a daily basis across VATSIM and I have dealt with my own fair share of well meaning but very new members of the VATSIM network that disrupt my ability to enjoy the network. As a direct result, I have been encouraging people for some time to make better use of the .wallop command whilst controlling, particularly in the en-route environment, whilst also quietly discussing this at more senior levels within VATSIM. Today, a representative from the Region approached Ben and I to discuss the issue of pilot quality and steps that we are being asked to take moving forwards. The message is simple: across the board, we are being encouraged to make better use of the .wallop command at any time during our controlling. I have already taken steps to ask my training/mentoring teams to ensure that student controllers are taught about appropriate and proper use of the .wallop command during mentoring sessions at all levels and this will propagate to students in due course. The message to everyone is very clear - if you are controlling (or flying) on the network, and the competence of a pilot falls short of the requirements outlined in Section B8 of the Code of Conduct, please .wallop the pilot. Many that read this will have considered walloping pilots previously but opted not to and I am very keen to understand - either by way of response to this post, by e-mail, by Discord DM or even DM via this forum - to understand why they chose not to. I have made representations to the Region as to why I think that controllers do not commonly .wallop pilots and, quite rightly, I was asked to provide evidence of this. You have my assurances that anything presented to me will be taken to the Region in the right way and I will be asking that your concerns are acted upon. I will provide assurances on two things: firstly, I have had several discussions with controllers recently whereby they either did .wallop someone, or considered .walloping someone, but realised that there were no supervisors online that could help. My understanding is that all .wallop messages are sent to a Discord server for the awareness of supervisors and I have asked for some months now that people .wallop even in the absence of supervisors; doing so will highlight to the Board of Governors that more supervisors are needed. Secondly, I am aware that additional guidance has been given to Supervisors recently with respect to the appropriate way in which pilots that fall below the expected quality standards should be dealt with. This has been a highly debated topic for years and for the first time, we have an open invitation to meaningfully contribute to how the topic is handled. It is incumbent now on each and every one of us, particularly as a high-traffic division, to take this request in the spirit it is intended and ensure that we're helping make the network aware of the breadth and scale of the pilot quality problem - it is not enough to simply debate the issue endlessly in Discord. We must now take action, as has been requested, and shine a spotlight on the problem once and for all. As always, if anyone has any questions, please let me or another member of the DSG know. Best regards, Adam, on behalf of the DSG

Hello all, There will be an Edinburgh Radar approach exam on Friday 19th April from 1100z. The exam will last approximately 90 mins. We will require a good amount of IFR inbounds with a few VFR aircraft to asses all competencies of the exam criteria. For pilots, please see the 'Guidance for Pilots' post below. If you plan on doing anything 'out of the ordinary', please check with myself on EGPH_X_APP before hand.

Effective 18 April 2024 Departures from Luton and Stansted routing via Dover (excluding DET departures) cross the LOGAN 2H/L980 track. In order to prevent these aircraft turning right, TC NE shall transfer these departures displaying a 'D' intention code on a radar heading. This traffic routes via M84 (cruise >FL195) or M85 (cruise <FL195) and is transferred by TC North East to TC East climbing to FL150 (GW) and FL110 (SS). vMATS LTC 4.2.1.3, 7.2.1.1 From TC NE to TC East From Agreement Conditions Heathrow Group ^ FL150 (Note 1) EGGW ^ FL150 (Notes 1 & 2) EGSS ^ FL110 (Notes 1 & 2) EGLC ^ FL110 (Note 1) EGKK, EGKB ^ FL170 (Note 1) Note 1: Traffic shall be positioned to remain north of the DB-FL175 area of TC NE (at least 3 NM north of the SABER-LAM track). These aircraft are not to be positioned south of the northern edge of ATS route L980 (abeam the TC NE sector boundary (DB-FL175)). Note 2: Traffic displaying 'Dx' intention codes (via Dover) shall be transferred on a radar heading. Documentation Status This change will be reflected in the London vMATS release 2024/04.

Valid 06 April 2024 For the Leeds event, in order to manage the increased workload in the PC West sector, a temporary arrangement is made to allow for the splitting of PC West. Positions PC West - MAN_W_CTR (Relief: MAN_W__CTR) Frequency: 128.050 MHz RTF callsign: Scottish Control Coordination callsign: PC West PC West is the permanently published position which, when online, takes responsibility for all of the usual PC West airspace minus any which is covered by another controller, as detailed below. PC Penil - MAN_WP_CTR (Relief: MAN_WP__CTR) Frequency: 126.875 MHz RTF callsign: Scottish Control Coordination callsign: PC Penil Top-down responsibility for: PC Isle of Man & PC Wallasey PC Penil is responsible for both the PC Isle of Man and PC Wallasey sectors, detailed below. PC Isle of Man - MAN_WI_CTR (Relief: MAN_WI__CTR) Frequency: 133.050 MHz RTF callsign: Scottish Control Coordination callsign: PC Isle of Man Top-down responsibility for: EGNS, EGNH and EGNL 🗺️ Agreed Levels Diagram - PC Isle of Man PC Isle of Man is responsible for airspace up to FL255/FL285 in an area to the west side of the Manchester TMA, as shown in Figure 1. This sector is primarily responsible for the streaming of inbounds and outbounds to/from Dublin ACC Liverpool inbounds via TIPOD from the West, Manchester inbounds to MIRSI, as well as MTMA departures toward ScAC Rathlin and Shannon. PC Wallasey - MAN_WL_CTR (Relief: MAN_WL__CTR) Frequency: 125.950 MHz RTF callsign: Scottish Control Coordination callsign: PC Wallasey Top-down responsibility for: EGGP, EGNR 🗺️ Agreed Levels Diagram - PC Wallasey PC Wallasey is responsible for airspace up to FL195 in an area on the western side of the Manchester TMA as shown in Figure 2. Their top-down responsibilities reflect the airspace of this sector (i.e. Liverpool and Hawarden) in the absence of other controllers. This sector is primarily responsible for the final streaming of inbounds to Liverpool via TIPOD and KEGUN, and Manchester via MIRSI, as well as departures from the MTMA routing west, or via MONTY and the N864 to the south. Coordination between PC West and PC Isle of Man Traffic Positioning PC Wallasey should position westbound traffic from EGCC, EGGP and EGNR on a heading north of WAL prior to transfer to PC Isle of Man. This traffic is RFT on transfer of communication to PC Isle of Man. PC Isle of Man should position eastbound traffic inbound to EGCC, EGGP and EGNR on a heading south of WAL prior to transfer of to PC Wallasey. This traffic is RFT on transfer of communication to PC Wallasey. If traffic is not operating in accordance with this guidance or is on a heading against traffic that is unknown to the receiving sector, then coordination must be effected. Aircraft inbound to the MTMA with an RFL below the Standing Agreement Level Traffic inbound to MTMA airfields cruising below the standing agreement level is RFD on transfer of communications from PC Isle of Man to PC West. Coordination must be effected if the aircraft is not RFD. Aircraft inbound to EGGP/EGNR from the northeast Controllers should be aware that there is no standing agreement for EGGP or EGNR arriving traffic via the TIPOD 1C, 1D or 1E arrivals between PC East and PC Wallasey. A level must be individually coordinated between the controllers responsible for these sectors, as it would need to be without this event split. Coordination with Adjacent Units Sectors/ACC When any of PC Penil, Isle of Man, or Wallasey are opened, it is the responsibility of the controller (or PC Coordinator) to inform the relevant adjacent units/ACCs: Scottish ACC - Antrim & Rathlin Dublin ACC Shannon ACC PC East AC North AC West Airfields Whenever either PC Wallasey or PC Penil are opened, which are non-standard adjacent controllers for Liverpool and Manchester, APC and ADC units at each field shall be informed. Manchester Departures with altered handoff orders: ASMIM/MONTY (05s): PC Wallasey (125.950) > PC Penil (126.875) > PC West... KUXEM/EKLAD/MONTY (23s): PC Wallasey (125.950) > PC Penil (126.875) > PC West... PC Wallasey is the controller responsible for arriving traffic via MIRSI. Liverpool PC Wallasey is the controller adjacent to Liverpool ATC. As such, whenever PC Wallasey is open (or PC Penil covering the Wallasey sector), all coordination/handoffs for departures and arrivals shall be with Wallasey. Isle of Man The PC Isle of Man sector has an interface with Ronaldsway APC, and covers the airfield top-down in the absence of local ATC. Sectors NB: OUTDATED FIX/WAYPOINT NAMES; DIAGRAMS DO NOT REFLECT THE WEST AIRSPACE DEPLOYMENT Figure 1 - PC Isle of Man - Area of Responsibility Figure 2 - PC Wallasey - Area of Responsibility This procedure does not alter the staffing permissions as defined in the UK Division Policy or GRP.

I am delighted to welcome @Max Brokman to the Technology Team. Max brings a wealth of professional experience within development teams and I am excited to benefit from that knowledge as we continue maintaining, enhancing (and occasionally fixing...) the various services that we run.

Hi Hugo, Good question, but one I'm afraid I don't know the answer to. Given that we didn't have a roster before and only 'added' people to it that had controlled in the previous 12 months, I'm not even sure whether our colleagues in Tech will have the answer. Adam

Thanks for the update Adam. How do these numbers removed from waiting lists compare to the numbers removed in the three months prior to GCAP under the previous 12 hours in three months requirement?