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.
Something appears to have changed with how flightplans are handled. Running back a specific logfile I’ve used for testing, there seem to be a lot more uncorrelated tracks. I haven’t looked at this more closely though to see how big the difference is or if there’s a pattern.
Also, while debugging, I noted OnFlightPlanDisconnect had been called over 30000 times in just over two hours during the playback with either an invalid FlightPlan or a FlightPlan with an empty callsign (I was looking for why the function hadn’t been called for a specific callsign in the log, so I was only monitoring and logging the callsigns). In 3.2.9 and earlier the function gets called correctly in the same situation (and no empty callsigns logged). Fast-forwarding through the logfile is also much slower in 3.2.10 than in earlier versions.
identical drawings in different layers of sector files appearing ever so slightly offset (e.g. current ownership highlight is off by 3px from the CTR outline)
After some switching of ASRs, sometimes parts of the sector are shifted about 8nm to the left. Some sections of border remain in place, others move
Bottom bar sometimes doesn’t show ASEL route anymore
The “on ground filter” seems no longer be working. Labels of traffic on the ground below the set altitude and speed are not suppressed as in previous versions.
Can you explain or show what you see about this? The FSD protocol makes it nearly impossible to have gap there. The handoff request is sent to the next controller only as private message and he replies with an “I track” broadcast message. So there is no drop of tracking before the next controller starts tracking.
My only explanation is the lag created on the client side. The calculation of the status is so laggy that the tag will show as untracked before eventually showing tracked by the next controller. This looks a bit like the connection was lost and the aircraft is not tracked anymore. So I naturally would assume it again and re-initiate the transfer. I also seems that this comes through to the FSD, actually blocking the next controller from start tracking. But the second after, my client reminds himself that this label was about to be released. So it will not actually start tracking it, but show it untracked. But due to the attempt of my client to start tracking it, the aircraft is blocked for tracking by other clients. So FSD-wise it is again assigned to me. Just my client has remembered a bit late that a handoff took place and therefore won’t display it to me as tracked.
So I guess the reception of the “I track” message is not correctly sequenced and the “retracking” of my own client gets the higher priority. My assumption is that this has always been that way, but never shown really as an issue due to good timing/performance. That would also explain why these ghost tracks happended also in the past from time to time. With the decreased performance on newer versions, this scenario is just much easier to replicate.
