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.
Once again the METAR problem, now after an update, it was shown correctly several METARs before… (ESOW)
TopSky is showing ESOW METAR from 1720 instead of 1320 or 1350 as all other METARs, if that is of any help…
I can confirm that the SDK is available in my TrackAudio client, and fully functional. The documentation of the protocol is the same as VectorAudio (see here: SDK documentation · pierr3/TrackAudio Wiki · GitHub)
This SDK also does not have the issue where proxy instances cannot receive AFV data, and can be used with as many sub-clients as you want.
1 Like
It happens in every sessions or so. Another controller connected at the same time with an older version of ES didn’t had the issue.
Having same problem.
This is already fixed for v3.2.10
1 Like
I think the following is a bug;
Sometimes when using “Display scope as”, certain planes become automatically assumed by me after the controller I am observing transfers them.
(I do not have an active frequency, so no, they are not transferred to me)
I just noticed that some temporary unavailabilities of the VATSIM METAR website also contribute to this issue. If the web endpoint recovers in between regular update cycles, it would be nice if an update can be forced by the controller. I wasn’t able to bring the METAR to live although it was available again via metar.vatsim.net. Is there a specific command for this?