Hi,
Ad 1 - Disable “Zoom in background thread” option in general settings.
Ad 2 - Check the ATIS letters at https://www.euroscope.hu/wp/basic-lists/
Gergely, thanks for the info. i still see some lagging when i move the screen for a couple of milliseconds. and something else. when i open my runway dialog the dep / arr squares are empty so i need to check them again. but after a couple of minutes they get empty. and something else. in previous versions when you opened the runway dialog and closed it , the metars changed color considered as ‘‘read’’ , now it doesnt do that. the good thing withthe new metars is that they are in alphabetical order
Another strange thing found:
I constantly hear the clicking sound of a privat chat message comming in without actually receiving one…
I seem to have the same bug @815026 encountered, but it happens on the network for me as well. Unchecking the tickbox does fix it. Doesn’t seem to be a display issue, as the ATIS generator will error out with a message about checking runway config while the box is ticked and the dialog shows no runways.
Can also confirm that bug. Not constant for me, but bursts of roughly ten clicks do happen
Hi Gergely,
I noticed something I assume a bug.
I’m a plugin developer myself. When I try to debug my plugin, I need to test its stability when I rapidly switch from ASR to ASR with the F1+1~9 shortcut. However when I go fast enough, Visual Studio prompts me something went wrong with stack. From the stack view I don’t see it has anything to do with my plugin, and afterwards I try to unload them and still use the debug mode, the problem still appears. I also tried it outside of debug, ES crashes directly. I guess the rapid ASR switch is the cause, and I tried disabling “Zoom in background thread”, same thing happens. I tried downgrading to 3.2.3, every thing works fine.
UPDATE: It seems like an issue with Topsky. Unloading Topsky and ES doesn’t crash. I will report in their thread.
Having the same issue.
Disabling the “Set active APT by owned sectors” fixes it, the runways stay after re-enabling it, but if the sector ownership somehow changes after having re-enabled the setting the runway selections disappear again.
Can confirm this issue. Also the performance is still significantly lower than in 3.2a(r34), which currently remains my operationally used release. Especially considering the dense traffic in Switzerland, for sessions 1h+ none of the new releases reaches at least the same performance as r34.
I fixed the active RWY for the next release.
1 Like
Using your Sentry LOG I found a missing Mutex lock in my code. TopSky might cause the problem only the way that it triggered an update.
Jonas,
How do you feel the performance issue? What actions are significantly slower than before?
I will need to pay close attention again to any detail. But definitely the lists from the tags get laggy when there is a lot of traffic. I also have the impression that this stays stronger even after traffic has disappeared, compared to earlier versions. But this is really difficult to judge. I can try to reproduce it by using logs. But I’m also not sure if the effect is the same (live vs. running log).
Should this drop down show the list of ATIS positions from the VoiceChannels.txt? It’s empty for me. However the voice communication setup lists shows the ATIS entries.
Gergely,
Since you are doing modifications to the drawing and optimizing performance, could you consider adding an auxiliary window, for sure present in the majority of ATM systems around Europe?
2 Likes
I’m not sure what you mean by “auxilliary window”, but you can open a second ES instance, choose “To Vastim via Proxy” in the connection dialog and go from there.
It gets the ATIS positions defined in the ESE file.
It is in my TODO list with a higher priority.
2 Likes
Ok. That’s not working here. However I can enter an ATIS station manually and then the frequency is changed accordingly. But the list remains empty.
I find the new combined frequency chat a little annoying:
Because I’m tower (120.180) and I had to cross couple onto ground frequency (121.955), this is how my chat label turned out…
The frequency setup in this case is:
- EDDV_TWR: 120.180
- EDDI_GND: 121.950
- EDDV_GND: 121.955
- ETNL_A_GND: 121.955
First of all, 121.955 should not activate text chat for 121.950 frequencies at all.
Second, I’d love to see a solution to prevent such huge chat labels. I’d suggest:
a) If there are multiple stations with the same frequency active, only show the respective frequency once
b) simply label the chat tab “on frequency” or something like that
c) a mix of the two, where up to ~3 frequencies will be shown, but once a fourth one gets activated, it gets shortened to “on frequency”
Just my thoughts…
Edit: idk how the AfV API works, but maybe it would be a good idea to use the station name set in AfV instead of the frequency to determine which frequency chats to activate