Dear Gergely
Thanks for the latest update 3.2.10 of EuroScope. I’m sharing my observations from a test session online today. Any comparisons are referring to version 3.2.3 (which I use as the stable basis).
- I had two CTD within 2 hours using the same setup as before with 3.2.3. One of the crashes happend after I entered a question mark in the command line to complete a message and hit Enter. Not sure if this was related as I wasn’t able to reproduce. Hope the Sentry reports made it to you.
- I got a bunch of strange messages from an ATIS station. Not sure if this is due to my EuroScope or the one from the controller at the other end.
- The cursor in the command line always jumps to the very end, making the use of alias with variables to complete nearly impossible. After every character written, the cursor will jump to the end, and you have to place it again where you want to continue writing. This is a blocker to recommend this release to all users of my vACC.
- Minor bug (already present before): headings <99 from the auto text messages are missing the third digit. I would prefer “090” over “90”, replicating also the spoken numbers in radiotelephony.
- Performance issue: changes in the APT/RWY setting dialog result in a very high CPU load and a temporary freeze (for several seconds) of EuroScope. While this issue was already present before after confirming the changed configuration (seemingly when the sector ownership internally was updated), there is now also a delay while only changing the checkboxes in the dialog. The delay after confirming the changes has grown compared to previous versions. This is a blocker to recommend this release to all users of my vACC.
- The COPN dialog now shows the full call sign instead of the controller ID for waypoints that will required coordination. Is this change intended? If so, what are the thoughts behind. For me, it rather clutters the COPN list unnecessarily. A solution in the SI item where the controller can choose the ID or full call sign would be preferred if there is a need to allow the controller easy an quick access to the full controller call sign. As the COPN can only be coordinated with the next (or the SI selected) controller, a simple “*” in the COPN list or something similar would also do the trick to indicate that this will initiate a coordination.
- The transfer of tags takes noticeable longer, and also lags. There is always a phase in between accepting or completing a handoff where the tag shows un-owned, creating the split-second perception that the handoff was not done. If you’re quick enough, you can start tracking such a tag again exactly during this phase - which results in blocking its state. It will no longer be trackable for other controllers, but it will also look occupied by another controller for myself. As my client was in fact the issue, I was eventually able to release the tag again by using “.qx /ok”. Otherwise, the tag would have been locked.
Thank you for looking into these issues and I hope, the most critical bugs can be fixed in an update soon.
Kind regards
Jonas