Hi, when using proxy and mode C correlation (which could do with being re-named to “mode A”, as C only sends altitude info), any ES-instance started after connection will not show correlated aircraft as correlated. If all instances are started before connection, everything works as expected.
The chat headers also doesn’t sync across instances, like they used to a few years ago, giving tons of unnecessary extra work chasing flashing/unread headers across all the windows.
Misc wish list:
- Make all dialogue windows behave like the Voice Com Setup, not like the active runway selection. I.e., let us interact with the rest of the scope while the window is open.
- Add new Title Bar toggle to show/hide 4x ATIS letters.
- Show save .asr prompt when closing with F1+0. Or option to auto-save with it.
- Make ES ignore key set as PTT in AFV / VectorAudio, or provide option in ES to ignore a specific key. It is currently not possible to have a character as PTT without filling up the command line with said character.
The config value m_ScreenNumber:0 in the screen.txt-file is not able to deal with screen numbers moving around as a result of a DisplayPort monitor being switched off/on in a multi-monitor setup. It results in ES-instances loading up on a different monitor than expected.
My specific issue is that I switch off the monitors only if someone is sleeping in the PC room, which is not always. Starting up the PC without the main monitor (DisplayPort) switched on first will cause a shift in whatever value ES uses to define “number 0”, even if the main monitor is switched on before logging in on my PC User Profile during startup. It sends ES windows I want on my main monitor over to one of my HDMI side monitors, because they were the only ones initially detected during Win launch.
Issue remains until Windows is restarted. All Win11 dialogues and nVidia dialogues show the main monitor as the first in the sequence the second it is started, so I’m guessing ES is looking for an older registry value than seems to be the norm today.
@904331 Any chance you could have a look at any of these?
+1 for all of this, especially with syncing chat headers which apparently have worked before.
I put them to my TODO list. Bugs have priority over new features.
Syncing chat handlers have a work around: you can completely disable chat handlers on proxy instances. I normally control in this way.
Thanks very much.
How are proxy chats disabled? I’d very much like that setup.
Edit: If it’s done by disabling “advanced proxy communication”, that still doesn’t stop incoming chats from doubling up and staying unsynced (v 3.2.3 for VATSCA Norway plugin compatability).
Second page in General Settings (in 3.2.8)
Thanks, that’s not an available setting in the stable controller package here yet, looking forward to being able to use that.