EuroScope v3.2.9

I’m sorry, I don’t know that.

It’s not a documented feature. As far as I know, no documentation has ever been released describing the possible ways to access AFV data. AFV sends these window messages (either to all windows that match the criteria or only the first one it finds if there are multiple plugins trying to listen out for them, I don’t know) and VectorAudio currently uses websockets for the same purpose. Already two different solutions are being used, and with no standard, possibly more in the future. Not an ideal situation, but at least the VectorAudio SDK is documented.

I see, I missed that it was already reported, sorry!
Yes, I do use the AFV bridge to sync text TX/RX to channels active in AFV, ES does not do this on its own, right?

The transfers might have been initiated on a proxy instance, that factor/possibility I forgot to take into account, I am anyways pretty sure it was always displayed the same on all instances, but maybe it makes a difference which instance initiated it. I will keep an eye out for this and get back to you.

To my knowledge, this data is sent only to a selection. Because if you are running multiple ES instances, only the one opened most recently will get the data in the hidden window. Determining the primary frequency (for AFV) is probably linked to this, as AFV will always consider the most recent ES instance to get that information.

After a session yesterday the transfer issue was in fact behacing as suspected. Sometimes when initiating a transfer on a proxy instance it will only be shown correctly on the main instance.

I did not experience the squawk issue at all during my session yesterday, hopefully it was an isolated issue.

I found the proxy handoff issue. It will be fixed in the next release.

1 Like

In the ATIS dialog, test URL doesn’t seems to get the latest runway config anymore. So if I change the runway, the ATIS dialog will not catch this unless I disconnect the ATIS, update the URL and then reconnect it. This worked without the need to disconnect before.

I seems when the shift change function is used, the controller info (although the new one is shown when pre-selecting the new station) will not be changed and sent to the network. So the controller info will remain the one from the old station. At least this was the case today when I logged in initially as an observer and then used the shift change to switch to my controller position.

@904331 Hi Gergely! Would you please add a variable for COPN/COPX altitude? We use specifically designed meters in China. It’s not always an integer. It would be great if a variable could be opened to customize the altitude of COPN/COPX to facilitate coordination.

Another already longer standing issue: When a level is coordinated and accepted, the altitude label item will stay in the coordination accepted colour. This is different from a direct, where the colour will change to the normal (assumed) colour. Although also there an additional click (compared to early beta of 3.2.1) is required to remove the coordination accepted colour. In early version of of 3.2.1 it worked the way that once the coordination was accepted and the same value (level, fix) was selected again, the coordination accepted colour would be changed back to the normal tag colour.

Hi, I am not sure I completely understand the request. Where do you need it?
And it might not be easy to add it anyway. Internally in ES everything is stored in feet as integer. It is converted to meters only for displaying.

Hi, Like COPX/COPN altitude coordination. I understand that changing to the metric level is not easy. So I think maybe spilling it out could be easier. Just like COPX point. There is a function for points, which Topsky or other plugins could call it. The third-party plug-in sets the value and returns it to ES, and ES transmits the value to the recipient through the coordination function. For example FL 256,301,411

In the chat window, adding text anywhere else than at the end of the written text string does not work for me. It lets me write one letter/symbol before moving the text cursor to the end of the message.
This is only happening in proxy instances, working as normal in the main instance.