Ok. I’m only using the GRP plugin from Juha. I don’t have the TopSky plugin in use.
And regarding the aircraft info/capabilities issue, I’ve sent you the log file via email.
Curious - is there planned to have a round globe support in ES?
For countries futherr north, Norway especially we have to use alot of .dcenter to get the correct projection depending on where we are looking.
IRL they use a round globe projection, and would be cool/nice to have this in ES.
1 Like
Round globe or Lambert Conical?
Either way, +1 as it is useful for bigger FIRs
“no data” getting stuck, unable to remove them from the list by clicking.
I can get rid of them by using “.QD”, but adding them again gives me the same “no data” error.
Adding new airports which was not in the list during the network error works as normal.
Hi,
.find ASEL without a selected aircraft produces an instant CTD
Yes, it is in my TODO list. But it is a bigger update.
I was wondering to keep the current projection but always change .dcenter to the actual center point.
But round globe sound quite interesting.
Thx, I have the sentry LOG about that.
Does it happen to you just immediately after using .QD? Or just later? What airports?
It was just that one session when there was network issues, ESNQ, ESNU and ESKS IIRC.
The problem was them getting stuck in the list bc no data avbl (even after network problem was solved they stayed stuck), not that it didn’t download the data.
Trying to add them today (or other airports where there is/should be no data) works as intended. Maybe it was a one time thing, sadly I did not save any log files of that problematic session.
I’m not quite sure if everything is alright with the new combined frequency chats. There is definitely not enough space anymore in the left bottom corner. When a call sign is a little longer, the “on frequency” is not shown anymore. Suggest to either provide a bit more space, or shorten the text to something like “on TX”.
Does the combined chat mean that ES will care about coupled frequencies and send text messages to all to frequency chats? Until now, a plugin was required for this (GitHub - AndyTWF/afv-euroscope-bridge: Provides a bridge between the Audio for Vatsim standalone client and EuroScope 3.2). This plugin is also the one working with a hidden window allowing other plugins to use some AfV client information (receiving a transmission, originator = call sign) to provide VDF display functionalities. If ES could provide information about received transmission (call sign, frequency) directly - and also through its API - this would make VDF implementations easier.
In 3.2.8 and 3.2.9 I noted a bug in the scenarios. Everytime I start sweatbox, it wants to default to a VIS point of N48,E08 ish. If I try to put .vis points to my local airports, it still does the N48,E08 area.
Two presisting problems in 3.2.9
- When controlling, ES sometimes freezes for about 6-7 seconds, also taking AFV with it. This happens as the sector ownership changes when a new position is opened/closed, in 3.2.3 this temporary freezes were a lot shorter.
- When transferring labels to other positions they appear assumed by me and sometimes are despite that assumable by the downstream position, and sometimes not. A second transfer usually works as normal, this is only present when using TopSky 2.5b7 together with this ES version. Juha stated that there have been no changes to the related code in TopSky so it has to be “a temporary network issue or an issue with EuroScope”. Any ideas on this issue?
EDIT:
- During my session today i experienced the bug again where a faulty/network error METAR getting “stuck” in METAR window. Looking like this (was for ESNU).
Is there any way to solve it so that the network errors simply returns a “no data” without causing them to be “stuck” like in my examples? (I’m unable to reload METAR for that airport until ES is restarted)
What is the reccomended way to send you data (Memory dump files, some kind of log file? I’m a tech sucker 
) for the next time I have issues that do not cause ES to crash? (triggering the automatic sentry log if I’ve understood everything correctly)
Maybe consider limiting “Display scope as” option to controller positions only, so excluding observers and especially ATIS stations.
And would it be possible to have transfer status of tags also indicated/synchronised for the observer? This would also be helpful for mentors/examiners.
OK, I changed the message to " on TX".
I also looked at the avf-euroscope-bridge project. I understand that whenever anyone send a message to the hidden window, then this plug-in changes the send/receive flags. But there is no information about who and when is sending these messages. Does it need any plug-in to AFV?
Meantime still use this plug-in.
Again encountering the cryptic METAR, currently for LSZH while the VATSIM provided METAR string is: LSZH 241250Z 27014KT 230V290 9999 FEW040 SCT050 BKN065 08/M01 Q1012 TEMPO 4000 SHRA.
What callsign do you use for connect? In general if your callsign starts with an airport name, it moves the visibility center to the airport coordinates. Otherwise it has a default - that might be N48,E08.
As far as I’m aware, this creates regular messages indicating which aircraft is transmitting. So the aircrafts call sign can be received (and consequently be used to create a visual indication via a plugin). When no transmission is ongoing, this string is just empty.
- The ownership lock was already reported. What is interesting to me is your statement that “also taking AFV”. ES and AFV has no relation at all (except if you use some plug-in like the above bridge). Do you use that?
- I also noted similar things but only only proxy connected clients. Do you see that in main or proxy client?
Crashes are sent to me automatically.
I see. But is it a known feature of AFV that it sends such message to a window that class is “AfvBridgeHiddenWindowClass”?
Using a Centre callsign. In particular, CZQM_CTR and/or CZQX_CTR.
The ESE file has the vis points in it as we are using GNG.
CZQM_CTR:Moncton Centre:132.200:QM::CZQM:CTR:::3101:3177:N048.32.46.875:W054.34.21.726:N045.38.29.854:W062.38.52.086:N056.33.03.000:W061.40.93.300:N061.55.30.453:W058.56.29.983
A rollback to a previous version works ok with the current vis points. When I try a .vis point, it won’t display the expected vis and will still go to the default.
1 Like