Closed pierr3 closed 8 years ago
This is actually as it was intended. In real life, flights are actually being assigned code 1000 when entering the area (listening to Rhine Radar, this happens at the German-Polish border, and according to FR24 it happens elsewhere as well), so I implemented it this way. Is there any special case where a different behaviour is necessary?
No, in this case, this behaviour is incorrect, the SWR was assigned a valid, non duplicated mode a code. He was flying within the same PA region the whole flight, so no code change was required. The reason you hear the squawk 1000 change at the Polish/German border is because the two countries are not part of the same PA, hence a squawk change is mandatory. The same happens at the Italian/Spanish/French border etc... The plugin shouldn't create a squawk change if a valid mode A code was assigned, it is up to the controller to trigger the squawk change if a change of PA occurs.
Besides, as in real life, you might want to issue a particular mode A to an aircraft, and not use 1000, so this behavior is totally incorrect.
I don't agree that there should be no change if the aircraft has a valid mode a code. Usually, those aircraft should have 1000 already, but on VATSIM this depends on ATC coverage and the controllers themselves. I think, due to the VATSIM limitations, it's favorable to assign code 1000, even if this would not happen in real life (but would have happened earlier).
After thinking again, I agree that there might be situations where a different code is preferable, and that the controller should be able to influence this.
I will make the automatic change for aircraft with discrete codes an option, and I will implement some kind of a blacklist to prevent an assignment in cases like yours.
What do you think about this: Automatic assignment only happens if the aircraft originates from outside of the PA?
I would make these options:
Do you think number two is sufficient, or would you prefer the option, since the assignment can still happen at places where it wouldn't in real life?
My view is that, as in real life, if a mode A code was assigned for any reason, a code change should not be generated, that is to reduce controller workload, and because it doesn't actually change much once the aircraft is correlated. I'm also against having options in this plugin, as I'd rather have the exact same generation logic for everyone, to not have one person assign a billion sq 1000, and another only a few. Same thing for the PAs, define the PAs is too complex for nothing, since you are already supposed to reassign a squawk to an aircraft coming from an other PA, you are already clicking the tag/list item to assign a squawk, so your function that assigns 1000 is fine. Let's keep this plugin simple.
Guess I see one point why we have a different view: We don't assign codes for ac from another PA, simply because currently there is not enough codes available. On EDMM_CTR I have codes 2354-2367. Last session I assigned 61 codes within 5 hours, few of those were code 1000 - far more than I have available. So for me, this would mean to check for every single aircraft if it is applicable for code 1000 at the PA border. That's why I'd prefer more automation (not the current level, it really is way to aggressive).
I think I will cut it back to the level you are suggesting for now, should work fine for the majority of users.
Btw, would you assign code 1000 for AC without assigned code and 2000/2200 etc. automatically?
We'll have to see how we can balance automation and auto assignement, to be honest, the best would be to write a ORCAM squawk assignement plugin for our PA, if you're interested, we could work that out.
Yes, for AC without assigned code and 2000/2200 I would assign 1000 automatically when the controllers assume the aircraft, since those are already correlated automatically by EuroScope, even not squawking any code.
I was thinking about something like ORCAM as well. The current, sector based assignment can reach its limits pretty fast. I like the idea.
For now I removed the (my) auto assignment and the debug output and moved the code for the combined assignment function completely into the RadarScreen instance. I'll add this assignment back in. I'm still trying to figure an elegant way to do it.
I will release the new version tomorrow after some testing in the sim.
https://s3.eu-central-1.amazonaws.com/pithos/ShareX/2016/05/EuroScope_2016-05-15_17-21-29.png
See here, I owned SWR734, he was assigned a squawk, upon loading the plugin, it assigned 1000, so I reset it to the current one, and 1000 was re-assigned.