a time of delay please

[Florian Harms]

Hi all,

just monitored a couple of problems lately. When a new controller is coming online, it looks like that plugins in use might not wait until all data is processed and do starting their work e.g. setting new squawks and so on. Of course, this is what to expect from a client, a plugin and so on. However, there need to be a time until all data from the network is processed prior to start the plugin's work. In the mentioned situations, a new controller came online with a plugin. By sector file definition, his controlled airspace was part of mine, but due to the sector priority, my login was keeping all tracks. But however, all my aircraft's got new squawk automatically WITHOUT being tracked by somebody else than me...

I have talked with a few guys and they have monitored the same effect. My Inet connection was working properly and without any hiccups. The only conclusion from my point of view making sense is that the other client coming online started to process the work without waiting until the whole server data were processed; the system didn't check that the tags were already taken by another controller.

What could help to solve this problem is to simply start working a bit later, lets say after 10-15 seconds for the first tag checks and so on. I am not sure if this is either easy to implement or if the task is better by the ATC client, but please have a look into this problem...

 

All the best

 

Flo

[Magnus Meese]

Couldn't this be implemented in the plugin? Initiation delay of some sort, or simply a "power on"-button hidden in a corner of the screen or something like that?

 

A temporary solution until a permanent fix is found, is to just avoid saving the plugin in your .prf. It's a bit clunky to have to load the plugin manually each time, but at least it should fix the issue, given that the cause is what you predict and not the plugin itself

[Adam Trzcinski]

A temporary solution until a permanent fix is found, is to just avoid saving the plugin in your .prf. It's a bit clunky to have to load the plugin manually each time, but at least it should fix the issue, given that the cause is what you predict and not the plugin itself

 

The problem is that it's not the plugin installed in my (or in this case: Florian's) EuroScope, it's a plugin installed in someone else's EuroScope that is causing the headaches. Since I have no control over what plugins someone else has written and installed in their EuroScope, the best path is to ask for the EuroScope client to include a delay.

[Pierre Ferran]

Florian,

 

I haven't found a way to implement easily what you are asking with the current SDK. But to me the problem is not there, to me, the controller client should verify the validity of the information received before letting any plugin do anything. It also seems weird to me that the servers allow tags that are owned to be modified by someone who doesn't own them.

 

So in short, it's hard for plugin makers to correct those kind of bugs when the SDK used is supposed to take care of all of that.

 

Hopefully we can resolved this ASAP.

[Jonas Kuster]

It also seems weird to me that the servers allow tags that are owned to be modified by someone who doesn't own them.

 

That's exactly the point. This kind of action should be possible by network architecture, at least not for the "normal" controller. It might be an option for supervisors. Unfortunately, not all plugin developpers are as cooperative as Pierre is as we know from the problems with the Virtual Controller [Mod - Happy Thoughts]istant plugin.

 

So I would highly recommend to forward this problem to the network administrators that they can implement the relevant restrictions.

[Pierre Ferran]

I just updated my ModeS plugin to delay the start of the squawk [Mod - Happy Thoughts]ignment upon connection by 15 secondes, hopefully that'll work. If any developer want to implement such a system, my code is available on GitHub:

 

https://github.com/pierr3/ModeS

[Andreas Fuchs]

Great, will test it!