User mini profile

- Fri Aug 11, 2017 3:12 pm#516716
One should program an anti-VCA-plugin. It is probably the fastest way to solve the problem.

A simpler workaround which helps is to replace the origin airport as VCA then obviously doesn't trigger any flight plan changes. So, I just modify flight plans out of the UK (origin: ZZZZ) before I start to work with the tag. It's not so handy, but effective.

User mini profile

Jonas Kuster 1158939 wrote:One should program an anti-VCA-plugin. It is probably the fastest way to solve the problem.

Little bit counter-intuitive, making other controllers download, install and use a plugin, just for the benefit of a few controllers in the UK.

Back in April, it was suggested that those using the plugin should be kicked, I somewhat agree - it's causing a disturbance to a number of other controllers. The plugin is no longer officially affiliated with VATSIM-UK division, and in reality, controllers should still be able to perform their duties without the need of a plugin, surely?

This problem has been around literally since at least December 14th 2016, so we're now upcoming on the 9-month anniversary!

User mini profile

- Fri Aug 11, 2017 5:22 pm#516725
If there is an issue with a controller using the plugin, please summon a Supervisor through the use of .wallop... If the user refuses to terminate use of the plugin and it is causing issues with other users, then the user is in violation of Code of Regulations section 6.03 (C) which relates to conduct which interferes with other users enjoying the VATSIM Network.

User mini profile

- Fri Aug 11, 2017 6:56 pm#516733
The UK Division is aware of the issues that the use of VCA is causing and dropped support for it earlier this year. It is no longer included within our controller packs.

We cannot, however, force people to stop using the plugin. The easiest way of doing so is providing a suitable replacement which is currently in development.

I am troubled by the quantity of reports we are getting regarding this issue and our friends overseas should be assured that we are working hard to mitigate the issue through this replacement.

User mini profile

- Mon Aug 14, 2017 8:31 am#516814
For information, this is still happening, as soon as yesterday. It's really frustrating, as I have to ask almost every pilot coming from the UK (often it's the same departure airport) to say their assigned squawk, then manually inputing that into their SSR field.

User mini profile

Mats Edvin Aaro 1227980 wrote:For information, this is still happening, as soon as yesterday. It's really frustrating, as I have to ask almost every pilot coming from the UK (often it's the same departure airport) to say their assigned squawk, then manually inputing that into their SSR field.

Surely you could just see what squawk they have set and manually input that? Much quicker...but I see your point in how you shouldn't have to do that in the first place.

User mini profile

Kieran Samuel Cross 1298134 wrote:This problem has been around literally since at least December 14th 2016, so we're now upcoming on the 9-month anniversary!

That would be kind of acceptable. I reported the problem back in January 2015! 2.5 years ago! Then I started participating in the VATSIM UK forum to establish contact with the developper Craig Phillips. But no answer. With increasing pressure from VATSIM UK itself and the community, some smaller changes were introduced and Craig promised to fix the bug. But he couldn't do it. So the same bug still exists.

Kieran Samuel Cross 1298134 wrote:Little bit counter-intuitive, making other controllers download, install and use a plugin, just for the benefit of a few controllers in the UK.

Seems to be one only way right now to at least identify the controller using the plugin while a session is running.

Andreas Fuchs 810809 wrote:The issue is that we cannot determine who EXACTLY is using that plugin that is causing the modification of a plane's TEMP ALT and SQ CODE. That's the start of the issue.

You can, with help of the (manually launched) ES log file function. But the file can only be reviewed after the logging has been stopped. So you would need to stop the log every time you identify a VCA interruption, go back to the log and look for the controller. Pretty complicated to aim for a smooth session.

Nicholas Cavacini 1084329 wrote:If there is an issue with a controller using the plugin, please summon a Supervisor through the use of .wallop... If the user refuses to terminate use of the plugin and it is causing issues with other users, then the user is in violation of Code of Regulations section 6.03 (C) which relates to conduct which interferes with other users enjoying the VATSIM Network.

I'm aware of this option, but refused to use it so far. It's not the way I like to see VATSIM going, but proposed now by you, Nicholas, seems to be the only current option to get rid of this faulty plugin.

As I understood some discussions in the VATSIM UK forum, the automatic squawk allocation and the automatic setting of the temporary altitude (the two "features" which cause problems) are options which can be enabled/disabled separately. So it might already help if every controller using VCA disables this functions by himself. He can continue to use then VCA without causing trouble to other controllers on the network. Even better would be a stop of those services by the developer himself. But after all my experience, Craig is not caring about others on the network ...

Kieran Samuel Cross 1298134 wrote:This problem has been around literally since at least December 14th 2016, so we're now upcoming on the 9-month anniversary!

That would be kind of acceptable. I reported the problem back in January 2015! 2.5 years ago! Then I started participating in the VATSIM UK forum to establish contact with the developper Craig Phillips. But no answer. With increasing pressure from VATSIM UK itself and the community, some smaller changes were introduced and Craig promised to fix the bug. But he couldn't do it. So the same bug still exists.

Kieran Samuel Cross 1298134 wrote:Little bit counter-intuitive, making other controllers download, install and use a plugin, just for the benefit of a few controllers in the UK.

Seems to be one only way right now to at least identify the controller using the plugin while a session is running.

Andreas Fuchs 810809 wrote:The issue is that we cannot determine who EXACTLY is using that plugin that is causing the modification of a plane's TEMP ALT and SQ CODE. That's the start of the issue.

You can, with help of the (manually launched) ES log file function. But the file can only be reviewed after the logging has been stopped. So you would need to stop the log every time you identify a VCA interruption, go back to the log and look for the controller. Pretty complicated to aim for a smooth session.

Nicholas Cavacini 1084329 wrote:If there is an issue with a controller using the plugin, please summon a Supervisor through the use of .wallop... If the user refuses to terminate use of the plugin and it is causing issues with other users, then the user is in violation of Code of Regulations section 6.03 (C) which relates to conduct which interferes with other users enjoying the VATSIM Network.

I'm aware of this option, but refused to use it so far. It's not the way I like to see VATSIM going, but proposed now by you, Nicholas, seems to be the only current option to get rid of this faulty plugin.

As I understood some discussions in the VATSIM UK forum, the automatic squawk allocation and the automatic setting of the temporary altitude (the two "features" which cause problems) are options which can be enabled/disabled separately. So it might already help if every controller using VCA disables this functions by himself. He can continue to use then VCA without causing trouble to other controllers on the network. Even better would be a stop of those services by the developer himself. But after all my experience, Craig is not caring about others on the network ...

Well said! This is the reason the network has a list of approved software, maybe VATSIM/EuroScope's Gergely could implement a system to see that future plugins can be force-disabled by the author/a suitable authority in the same event.

User mini profile

- Tue Aug 15, 2017 11:49 am#516852
Well, the way I see it currently, it isn't a big enough problem for us that I want to go to BoG and demand that it's unsupported. But perhaps VATUK could make a statement to their controllers to disable automatic squawk allocation, which is the problem. Setting squawks manually isn't THAT hard.

User mini profile

Mats Edvin Aaro 1227980 wrote:Well, the way I see it currently, it isn't a big enough problem for us that I want to to to BoG and demand that it's unsupported. But perhaps VATUK could make a statement to their controllers to disable automatic squawk allocation, which is the problem. Setting squawks manually isn't THAT hard.

For those who also say they can't remember the allocations, I found a web tool that was hosted by VATSIM-UK not too long ago, which picked a squawk code based on the info you inputted into it. Realistically, if they can't handle manual squawk code allocation, then there's something that needs addressing with the controller training.

I really don't think it has something to do with that - a manual squawk takes longer time, if you have to find it first, hence why we have auto assign in Euroscope based on the info the sector file has. It is not only the squawk it changes, it also changes the temporary altitude. Again, it is possible to track down who's client is making the adjustments - it might not be easy - but it is possible.