UK (?) Plugin creating issues

[Pavel Brodsky]

Cool!

[Pierre Ferran]

Seems like the problem has not stopped, I suspect even the new version of VCA [Mod - Happy Thoughts]igns squawks and altitudes outside the controller's range.

[Andreas Fuchs]

Unfortunately, yes, just had a pilot coming from the UK, TEMP ALT 6000ft set.

[Mark Nelson 1266047]

Same here. Had three pilots tonight and one the a couple of nights back. All froom the UK, one from LEPA.

[Bernd Mehl]

Every session the same problem with the altitude changes outside the area of responsibility from controllers using this plugin. Why is it not possible to fix the problem or suspend this plugin?

 

A lot of controllers are waiting for a solution.

[Jonas Kuster]

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.

[Kieran Samuel Cross]

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!

[Nicholas Cavacini]

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 © which relates to conduct which interferes with other users enjoying the VATSIM Network.

[Calum Towers]

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 [Mod - Happy Thoughts]ured that we are working hard to mitigate the issue through this replacement.

[Andreas Fuchs]

If there is an issue with a controller using the plugin, please summon a Supervisor through the use of .wallop.

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.

 

Thanks to Calum for the information, I hope we can resolve this issue quickly. The issues with the VCA-plugin are not the end of the world, but it can be really annoying at times.

[Trevor Hannant]

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.

 

Just to be clear, support was dropped because Craig wouldn't make the plugin Open Source to fit with the UK Division's requirements/requests - not because of this issue:

 

https://community.vatsim.uk/topic/33962-the-future-of-virtual-controller-[Mod - Happy Thoughts]istant-vca/

[Kieran Samuel Cross]

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.

 

Just to be clear, support was dropped because Craig wouldn't make the plugin Open Source to fit with the UK Division's requirements/requests - not because of this issue:

 

https://community.vatsim.uk/topic/33962-the-future-of-virtual-controller-[Mod - Happy Thoughts]istant-vca/

 

Well doesn't that change perspectives.

[Mats Edvin Aaro]

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 [Mod - Happy Thoughts]igned squawk, then manually inputing that into their SSR field.

[Layth Al-Wakil]

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 [Mod - Happy Thoughts]igned 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.

[Jonas Kuster]

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.

 

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.

 

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.

 

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 © 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]

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.

 

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.

 

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.

 

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 © 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.

[Mats Edvin Aaro]

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.

Edited August 15, 2017 at 11:52 AM by Guest

[Kieran Samuel Cross]

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.

[Morten Jelle]

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 [Mod - Happy Thoughts]ign 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.

[Mats Edvin Aaro]

Isn't it just to see the departure airport?

[Andy Ford 1203533]

Realistically, if they can't handle manual squawk code allocation, then there's something that needs addressing with the controller training.

 

Fine for TWR and some APP positions, but for busy area sectors covering 4/5 airports at least, much harder when it gets busy (London can peak at 30+ pilots on a single small sector in some cases).

[Jonas Kuster]

Fine for TWR and some APP positions, but for busy area sectors covering 4/5 airports at least, much harder when it gets busy (London can peak at 30+ pilots on a single small sector in some cases).

So do we. But it can be managed, trust me. [Mod - Happy Thoughts]igning squawk is one of the easier tasks. It only depends on proper sector files. [Mod - Happy Thoughts]ign a range big enough to London control, and it won't be a problem. You probably underestimate the features of ES as you are used to the simple-to-use way.

[Craig Phillips 947617]

This has been brought to my attension again and I am looking into this as a priority. Unfortunately, it is not an issue I can resolve myself in VCA, the bug stems from the VATSIM servers/protocol itself. I have tried various different ways to fix/workaround the issue, but it is impossible without changing the VATSIM protocol or Euroscope itself.

 

I shall post here of any further developments.

 

Kind Regards

 

Craig Phillips

(Developer of VCA)

[Jonas Kuster]

That's no excuse. Somehow, it worked a few years back. There might have been changes. But you can't expect the network or client to change the way you like it. The plugin is at the lowest design hierarchy, so you have to cope with the conditions. If you can't, deactivate those services until you fixed it!

I find this hard to believe anyway. There were similar issues when a mode S plugin was introduced setting squawk 1000 all over. But it was fixed within a few weeks. And as I understand, your plugin is even working with a server where [Mod - Happy Thoughts]ignments could be cross checked. However it's not done. Did you ask for support regarding squawk [Mod - Happy Thoughts]ignment from Pierre?

 

To conclude: I seems you are not really interested in a solution acceptable for both VCA users and such controllers which are not using this plugin. You are just waiting the network or client to fullfil your requirements. This won't bring us a solution. It's up to you, Craig, to fix the mess you are causing!

 

It's really a shame one person can cause such negative network experience to so many other members.

[Craig Phillips 947617]

That's no excuse. Somehow, it worked a few years back. There might have been changes. But you can't expect the network or client to change the way you like it. The plugin is at the lowest design hierarchy, so you have to cope with the conditions. If you can't, deactivate those services until you fixed it!

I find this hard to believe anyway. There were similar issues when a mode S plugin was introduced setting squawk 1000 all over. But it was fixed within a few weeks. And as I understand, your plugin is even working with a server where [Mod - Happy Thoughts]ignments could be cross checked. However it's not done. Did you ask for support regarding squawk [Mod - Happy Thoughts]ignment from Pierre?

 

To conclude: I seems you are not really interested in a solution acceptable for both VCA users and such controllers which are not using this plugin. You are just waiting the network or client to fullfil your requirements. This won't bring us a solution. It's up to you, Craig, to fix the mess you are causing!

 

It's really a shame one person can cause such negative network experience to so many other members.

 

That's very harsh, considering I code the plugin in my own free time... I don't get paid for it. I'm guessing you're the guy who's .walloping everyone for using VCA that is now a topic in the UK forums?

 

I have provided many fixes in attempt to fix the issue, but have failed. The issue is/was not caused by myself as you state it was working sometime before. Nothing was changed in VCA to cause the problem, therefore it SHOULDNT be my responsibility to fix it!

 

The question remains... why does Euroscope or the VATSIM protocol allow the squawk code of an aircraft to be changed when the controller cannot see the aircraft? This was not the case a few years back... why has it changed?

 

I have tested that a controller in the UK is able to change the squawk code for an aircraft in Australia successfully, which should NOT be able to happen... That is a failure of the VATSIM protocol, NOT VCA.

 

I have released a work-around this evening that ensures that aircraft is visible when resetting the squawk code. Various Euroscope APIs failed to determine the visiblility of an aircraft successfully... I have had to write my OWN method to determine the visibility.

 

PLEASE DO NOT UNDERMINE ANYBODY WHO CONTRIBUTES TO THE COMMUNITY IN THEIR OWN FREE TIME. I am really quite offended by that...

 

The easiest way of doing so is providing a suitable replacement which is currently in development.

If that is the case, I don't see that it is open source... which goes against the grain a bit. One rule for one, another rule for another one?

 

Kind Regards

 

Craig

Edited August 15, 2017 at 09:25 PM by Guest