No. v3.2.4 and above use the new form of authentication.
1 Like
Does Euroscope support silent install? Iām creating an installer which would in one go install everything for our ATC controllers, with latest plugins, data files, etc. So if ES supports command line args for install, please let me know about them.
Many thanks
Just another minor input: Shouldnāt the first entry read something like āGet Infoā (controller info) for non-ATIS connections?
1 Like
Could we get the same windows explorer window we have when we select a .prf for .sct, .asr and scenario files?
The explorer window once inside Euroscope is very annoying to use
2 Likes
Not a 3.2.9-specific thing, but I would like to suggest a change in the behavior of transferred tracks when the receiving controller logs off before assuming or rejecting the track. At the moment, the behavior is identical to a refused track, which can create problems with silent transfers to a controller who then logs off unexpectedly as the transferring controller may not notice that they own the track again - especially if itās busy and/or the aircraft is already outside of the sector/off the controllerās screen - which in turn prevents other downstream sectors from assuming the track. Depending on how far away the next online sector is, the upstream controller may have to disconnect entirely to drop the track, which is by no means an ideal solution.
It would be preferable if the track was just dropped entirely in this situation.
This might make sense in the specific case you described. However, in general I would refrain from changing this behaviour and keep the āsafe-failā principle implemented now. Otherwise a flight may lose tracking unintentionally, e.g. in a case of a connection issue of the receiving controller. I think itās better in this case that the transfer is stopped and reverted.
If you have agreed to silent transfer of control, you sould also establish procedures precribing the process of a station going offline. If controllers do not communicate this kind of intentions and just knowingly go offline without telling their neighbour sectors, this is not an issue the controller client should solve.
We have agreed with our neighbours that the break flag indicates that transfers should only be made after a specific request has been approved by the receiving controller. Do you have a similar kind of agreement?
To avoid transfers initiated to a controller leaving soon, I would rather propose to link the transfer request logic with the break flag. Similar as for controllers which have activated their busy flag and automatically send a corresponding reply to any message they receive, I would propose an option to make the activated break flag automatically refuse any transfer requests. If activated, your ES client would directly refuse any transfer if the break flag is activated.
What do you think of this idea?
I think an integration with the break flag would be nice, but in a different way than you describe. Might also require a different flag altogether, maybe.
How I think about it is that when you transfer to the next sector, there is ( / should be) a defined hierarchy of who to transfer an aircraft to.
For example, aircraft at FL390 = transfer to UAC āABCā. If āABCā is not online, UAC āDEFā takes over that AOR. If āDEFā is not online, ACC ā123ā is next in line, and finally, if that oneās gone too, thereās ACC ā456ā. If nobody is there, itās UNICOM, obviously.
Now, when the controller of ABC uses the .break command to indicate heās about to log off, I would like it to function as a SKIP ME (another feature that could be nice to have on its own, btw), and the tag will automatically be updated for the sending sector that this particular aircraft has to be transferred to the next in line. In this case, letās say thatās 456, as DEF and 123 are already offline. If ABC was the last online, it would update to UNICOM, obviously.
Would that be possible?
I think this should be possible as the information you are referring to is already provided as part of the ese file, by the sector owner sequence. And I agree that this would be an even better improvement than what I proposed. This basically means that the proposed next sector determined by ES should only consider stations with no active break flag.
@904331 Do you think such a change is feasible?
That works if the break flag is set by the leaving controller (who may not set it if they are leaving very spontaneously, are just switching to a different position, or simply forget about it) and noticed by the transferring controller (who may not notice the flag in time if itās set only shortly before leaving (and setting it too early can of course lead to aircraft being sent to unicom when the leaving controller still would have needed them on their frequency) or if they are simply very busy and the screen height-long online station list has become a very low priority in the scan). We do have such a stipulation in all our LoAs, but in practice, nobody actually works that way and aircraft are either transferred anyway (also those coming from LSAS/Z, usually 
) or the leaving controller is asked āconfirm youāre leaving?ā and ādo you still want these aircraft here or should I send them to unicom already?ā if the transferring one has noticed the flag.
As such, I like the automatic refusal idea in that it would make it easier to notice if another station is on .break, but I dislike that it would seemingly prohibit a transfer to a breaked station altogether. I also think there are some vACCs out there that use .break for other purposes, so weād have to ensure that such a change wouldnāt interfere with what they do.
Maybe a separate command (.close or something like that maybe?) to allow controllers to unambiguously indicate that they are leaving would be a better solution and could then maybe more easily be combined with Mathiasā suggestion of ES ignoring a leaving controllerās current coverage for sector prediction purposes.
Another (or an additional) solution that I can think of would be to automatically drop the track of all targets that are within x NM of the tracking controllerās vis range limit (if I have, e.g., a vis range of 300 NM, anything more than, say, 280 NM from the nearest vis center would automatically be dropped), so anything too far away to still show up on the controllerās scope would 100% not be tracked anymore and anything still close enough could be found and dropped manually by zooming out a bit.
My impression is that you are looking for a solution to overcome controllers non-adherence to prescribed procedures. Wouldnāt it be more appropriate to remind controllers of these procedures and ensure that they apply them correctly? Asking for confirmation regarding the transfer is then the correct thing to happen, because you are not supposed to transfer silently anymore. But of course you still can after coordination. And if tracked aircraft can escape your sector without you noticing, you should either improve your scanning or change to a smaller sector as you are probably overloaded.
Just dropping tracks at some point could create other issues especially with facilities using smaller ranges. An automatic drop could help to avoid ghost tracked aircraft, but should not be done before the visibility range. Meanwhile, I hope you know the command .qx /ok <tag> (https://www.euroscope.hu/wp/command-line-reference/) which you can use to attempt resolving a ghost tracked aircraft. This has done the trick for me in many situations already.
The break flag might be difficult to spot in some situations, I can see that. But thatās why the proposal is to automatically drop such stations directly from the proposed sectors list. And to me, break seems to be the obvious flag to use. If you donāt look at the flag anyway, what else would you use it for other than to indicate that you donāt want any traffic transferred?
1 Like