Ground Radar plugin 1.2.2 beta 5

[Juha Holopainen]

Beta 5 is available:

Ground Radar plugin version 1.2.2 beta 5

Changes from beta 4:

• Added altitude filters to ground and tower modes (APP window got them in beta 4 already)
• Updated Maps data file (map visibility can be made screen-specific or based on data in ASR file)
• Added OperatorInfo data file (replaces the CargoCallsigns data file which is no longer used)
• Added Ground state to ground mode track label menu

Edit: a debug build of the beta 5 can be downloaded HERE. It contains only the plugin dll that can be used instead of the one in the above package to troubleshoot crashes. Other than being slightly slower due to missing code optimizations, the functionality is the same so I recommend to use it as crash dumps done with the non-debug version are almost certainly not useful for finding broken code. Future beta builds will all be debug builds.

Edited June 24, 2020 by Juha Holopainen

[Ricardo Sousa (1110850)]

I had a compiled list of military callsigns previously, some of them are missing from the operators, in case you want to add them

NATO,AFP,AME,FAF,FMY,FNY,IAM,HRZ,LSV,HAF,HNA,AFB,ROF,HUF,ASF,SUI,SQF,GAF,GAM,GNY,BAF,NCG,NAF,DAF,DAR,DNY,PNF,PNY,CEF,FNF,SVF,NOW,HVK,CWL,KIN,LEE,LCS,LOP,LOS,MRH,NWO,SMZ,STN,SMG,TOF,VYT,VLL,WAD,WIT,RFR,ACW,RRR,RRF,SHF,NVY,EGY,IAF,RJZ,RFF,DOD,QID,GKA,AIO,PAT,RCH,CNV,VV,BRS,CFC

 

[Ricardo Sousa (1110850)]

Some callsigns are outdated, TOM for example still shows as Tomson, RVP still shows as Aerovip, WUK flat out doesnt exist, so on.

Honestly I would rather have an option to have it search for the ICAO_Airlines.txt in a different folder, like, Callsigns_path="..\..\Settings\ICAO_Airlines.txt"

[Jan Doehring (1356262)]

Thanks for the update, Juha! Reloading the data files is much quicker now and makes devellopping a lot easier.

 

However, I just found out, Beta 5 display all time-based activated maps in black. Beta 4 works well. The color definitions are present in the config (attached below). 

And a question: Is it possible right now to exclude some maps from the menu itself? We are using GRPlugin in EDDM and EDDN so far. Is there a way to only show the maps relevant to a specific aerodrome? I can hide the map from being display an on the radar screen, but after experimenting around with ASRDATA and HideMapData I didnt find a combination with which I could hide a map from FUNCTIONS->MAPS completely...

 

regards
Jan

GRPluginMaps.txt

[Juha Holopainen]

21 hours ago, Ricardo Sousa said:

Some callsigns are outdated, TOM for example still shows as Tomson, RVP still shows as Aerovip, WUK flat out doesnt exist, so on.

The plugin itself knows nothing about the callsigns, it just shows what's in the callsign data file. If you have an outdated callsign file in the plugin folder, you're getting outdated information. Put an up-to-date callsign file in the folder and your problem is solved. Right now it is not possible to refer to a file in any other folder. It may become possible in the future, but no guarantees.

20 hours ago, Jan Doehring said:

However, I just found out, Beta 5 display all time-based activated maps in black. Beta 4 works well. The color definitions are present in the config (attached below). 

And a question: Is it possible right now to exclude some maps from the menu itself? We are using GRPlugin in EDDM and EDDN so far. Is there a way to only show the maps relevant to a specific aerodrome? I can hide the map from being display an on the radar screen, but after experimenting around with ASRDATA and HideMapData I didnt find a combination with which I could hide a map from FUNCTIONS->MAPS completely...

It's not about time-based activation or the presence of a style line. The appearance of the issue depends on the line types before and after the coordinate lines. It's probably a bit too complicated to explain fully but one workaround is to arrange the map so that the coordinate lines are at the end of the map. Another workaround that will probably work is duplicating the wanted color line just after the coordinate lines. It will work in other cases as well, but depending on what line types are used, the result may not be exactly as wanted. It'll get fixed in the next version.

It is not possible to exclude maps or folders. It's on the list of future developments though, most likely in the form of filtering the displayed map folders, possibly individual maps as well depending on how much work that would be.

Edited May 8, 2020 by Juha Holopainen

[Ricardo Sousa (1110850)]

13 minutes ago, Juha Holopainen said:

The plugin itself knows nothing about the callsigns, it just shows what's in the callsign data file. If you have an outdated callsign file in the plugin folder, you're getting outdated information. Put an up-to-date callsign file in the folder and your problem is solved. Right now it is not possible to refer to a file in any other folder. It may become possible in the future, but no guarantees.

That's the problem, GNG has this updated callsign list in the ICAO_Airlines.txt,  but the location of it is fixed. We currently we have it such that there's a copy of it inside the plugin folder, but we have to manually copy it there everytime it's updated, which obviously is not ideal

[Jason Leung]

The plugin is causing my ES to crash, any ideas why?

I'm on ES v3.2

Edited May 7, 2020 by Jason Leung

[Oliver Gruetzmann (961224)]

2 hours ago, Juha Holopainen said:

It's not about time-based activation or the presence of a style line. The appearance of the issue depends on the line types before and after the coordinate lines. It's probably a bit too complicated to explain fully but one workaround is to arrange the map so that the coordinate lines are at the end of the map. Another workaround that will probably work is duplicating the wanted color line just after the coordinate lines. It will work in other cases as well, but depending on what line types are used, the result may not be exactly as wanted. It'll get fixed in the next version.

Indeed.

MAP:S closed
FOLDER:Construction
ACTIVE:1
COLOR:darkred
N048.20.42.732 E011.45.31.002
N048.20.41.798 E011.45.31.184
N048.20.43.817 E011.45.57.836
N048.20.44.750 E011.45.57.654

works,

MAP:S closed
FOLDER:Construction
COLOR:darkred
STYLE:Solid:1
N048.20.42.732 E011.45.31.002
N048.20.41.798 E011.45.31.184
N048.20.43.817 E011.45.57.836
N048.20.44.750 E011.45.57.654
ACTIVE:1

works,

MAP:S closed
FOLDER:Construction
COLOR:darkred
N048.20.42.732 E011.45.31.002
N048.20.41.798 E011.45.31.184
N048.20.43.817 E011.45.57.836
N048.20.44.750 E011.45.57.654
ACTIVE:1

doesn't work (but did in the last version). I'll stick with the workaround, the explanation seems like it might cause a headache

[Juha Holopainen]

14 hours ago, Jason Leung said:

The plugin is causing my ES to crash, any ideas why?

I'm on ES v3.2

With just that information it's not possible to do anything. As it's not crashing for me and other people seem to be able to run it, it's something specific to your setup.

Let's start the troubleshooting by learning HOW, WHEN and WHERE this happens:

How?

• dialog box telling an unhandled exception occurred in the Ground Radar plugin (GRplugin.dll)
• dialog box telling something else
• ES crashing to desktop without any error message popping up

When?

• immediately on starting ES even if the used ASR doesn't use the plugin
• when opening an ASR that uses the plugin (GroundMode or TowerMode entry present in the ASR file)
• when doing something specific (mouse over something, clicking on something, etc.)
• while doing nothing special

Where?

• Ground mode, Tower mode or both? (if you've only used one of them, no need to test the other, I just need to know which one you've seen the issue in)

Especially if the crash happens on startup, the contents of your plugin data files may be important information, in case it turns out the plugin has a problem either reading or using the data in them.

[Martin Loxbo (811805)]

16 hours ago, Jason Leung said:

I'm on ES v3.2

This is 6 years old. Try the beta releases.

[Christian Kovanen (1379372)]

1 hour ago, Martin Loxbo said:

This is 6 years old. Try the beta releases.

beta a bloody beta [breathing intensifies] its a beta you cant use a beta  I only got hate when I recomended beta the last time a few months ago

[Martin Loxbo (811805)]

Beats me why he never called any of the releases stable. Maybe because the documentation hasn't really kept up?

[Oliver Gruetzmann (961224)]

Also seen some Crashes. Happened to me right after starting Euroscope with a GR Tower Mode ASR open at startup.

Pure CTD shortly after starting that instance and changing to a different ASR (Topsky). The time until it crashed differed, but it was no instant crash, tracks seen and I was already issuing instructions using this instance. After the 3rd start, it didn't crash anymore (start was always in the same state, since ES didn't save anything). The crash happened with the other ASR in foreground, GRP-ASR not closed.

Same today, but only one crash until it became stable (and not sure what I did today, the GR-Tower ASR was still open).

Can't remember if I did anything special, think it was simply running on the second screen while I was working on my first ES instance.

The resulting message in the Windows Event Viewer:

Faulting application name: EuroScope.exe, version: 3.2.1.24, time stamp: 0x5e92f782
Faulting module name: ntdll.dll, version: 10.0.18362.815, time stamp: 0x2995af02
Exception code: 0xc0000374
Fault offset: 0x000dfa1d
Faulting process id: 0xf0
Faulting application start time: 0x01d6252e963ad725
Faulting application path: C:\Program Files (x86)\EuroScope\EuroScope.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report Id: 6f5554be-5b44-419c-b71c-928628d5ae7f
Faulting package full name: 
Faulting package-relative application ID: 

EDIT: Exception Code and Fault offset are the same in all 4 crashes.

Edited May 8, 2020 by Oliver Gruetzmann

[Jason Leung]

5 hours ago, Juha Holopainen said:

With just that information it's not possible to do anything. As it's not crashing for me and other people seem to be able to run it, it's something specific to your setup.

Let's start the troubleshooting by learning HOW, WHEN and WHERE this happens:

How?

• dialog box telling an unhandled exception occurred in the Ground Radar plugin (GRplugin.dll)
• dialog box telling something else
• ES crashing to desktop without any error message popping up

When?

• immediately on starting ES even if the used ASR doesn't use the plugin
• when opening an ASR that uses the plugin (GroundMode or TowerMode entry present in the ASR file)
• when doing something specific (mouse over something, clicking on something, etc.)
• while doing nothing special

Where?

• Ground mode, Tower mode or both? (if you've only used one of them, no need to test the other, I just need to know which one you've seen the issue in)

Especially if the crash happens on startup, the contents of your plugin data files may be important information, in case it turns out the plugin has a problem either reading or using the data in them.

So I have updated to ES v3.2.1.24

Replaced the GR plugin dll file form b4 to b5, started ES on ground mode ASR and it CTD immediately. Started again in a different ASR and ES turned white and not responding.

Tried unloading it and reloading the plugin to b5 and the plugin window just went blank and not responding.

(And off topic... anyone else getting this problem where ES v3.2.1.24 is taking forever to close and exit?)

[Juha Holopainen]

7 hours ago, Juha Holopainen said:

Especially if the crash happens on startup, the contents of your plugin data files may be important information, in case it turns out the plugin has a problem either reading or using the data in them.

So, anyone experiencing a crash immediately when the plugin is loaded, I'd like to have a look at your data files. I can't make the plugin crash using my setup, so I need to alter the setup somehow to trigger the crash. The best way of doing so is trying to mimic the setup of someone having the issue.

Until the crash(es) can be linked to a specific action or part of code being run, or at least a scenario is found that can be used to trigger it repeatedly, the chances of a quick fix aren't very good.

[Oliver Gruetzmann (961224)]

51 minutes ago, Juha Holopainen said:

So, anyone experiencing a crash immediately when the plugin is loaded, I'd like to have a look at your data files. I can't make the plugin crash using my setup, so I need to alter the setup somehow to trigger the crash. The best way of doing so is trying to mimic the setup of someone having the issue.

Until the crash(es) can be linked to a specific action or part of code being run, or at least a scenario is found that can be used to trigger it repeatedly, the chances of a quick fix aren't very good.

My whole folder as of yesterday.

For me, the crash was not immediate, but delayed.

Ground.7z

[Juha Holopainen]

Thanks @Oliver Gruetzmann. I haven't been able to trigger a crash so far with your files either, but as your crashes weren't all related to plugin startup, I wasn't really expecting immediate success either, as they were likely caused by the traffic that was present then or something you had done.

Everyone having the issue, one possible way to get a repeatable scenario would be to start a primary instance of ES without the GR plugin loaded (or just unloading it after startup, doesn't matter as long as it's not loaded during the session so it doesn't crash the primary instance). Then start any number of other ES instances with the GR plugin loaded. As soon as one of the secondary instances crashes, take note of the exact time and any other information about the situation you may think would be useful. Then, either immediately if it's a good time, or when you end you session, remember to save the log from the primary instance. Check if you can get the GR plugin to crash by playing back the logfile. If so, send the logfile to me with the details of the crash you took down.

[Oliver Gruetzmann (961224)]

Btw, any thoughts about stand restrictions not based on wingspan only, but on wingspan and distance between the positions? The picture below would not be possible with wingspan only (Munich real life). Take the distance between two gates and allow to distribute this between two aircraft, including a safety margin (4,5 m or whatever is valid).

Also, I read a very nice idea elsewhere: In addition to assigning airlines to stands, allow to assign stands to airlines.

[Jason Leung]

This is the setup I have. My current work around is by renaming the DLL file by adding a "5" in front, this prevents ES from crashing, but all the plugin features becomes unavailable. The moment I remove the "5" in front of the DLL ES either CTD upon start up or it will freeze when loading it in the plugin screen... how strange... but beta 4 is working well.

Gound Radar plugin.zip

That's the crash log when loading the original DLL without renaming.

Edited May 9, 2020 by Jason Leung

[Juha Holopainen]

Adding the "5" in front of the plugin file name leads to the data files not being processed. Just by replacing my data files with yours doesn't cause my setup to crash though. Your screenshot however shows the crash being an unhandled exception. If that's the case (instead of ES just crashing to desktop without any error message), I can debug the crash dump and find the faulty code in just a couple of minutes, that's why I was asking before how exactly the crash happened. I'm not sure if the minidump you're looking at there has all the necessary information, but I can take a look. If it doesn't, I'll need a more comprehensive dump (once the crash happens, don't close the error message but open Task Manager, right-click on the EuroScope app in the "Processes" tab and select "Create dump file").

Creating the dump file from Task Manager is only possible with the ES process still alive, so it can't be done if the crash terminates ES without presenting an error message. It may be possible to get a dump in that case as well but a dedicated utility would be required (an application such as procdump may work)

[Jason Leung]

Both dump files are in here. The smaller one is ES generated and the larger one is generated via task manager.

https://drive.google.com/file/d/1QVZb9b5LEKAJy5dQRzQKuyP2s5eDOzKm/view?usp=sharing

[Juha Holopainen]

The dumps didn't seem to point anywhere useful which seemed disappointing to say the least, but then I realized the dll wasn't built as a debug build, so that was to be expected . Everyone, please download and use the debug build HERE to create further dumps so they will actually contain information I can use... Other than having been built as a debug build, it's the same code as the original b5. Sorry for the extra work.

[Jason Leung]

So this is what happened when I loaded it with the new DLL. I clicked retry and let ES freeze again and created a dump via task manager, ES crash dump is also included in the link below.

https://drive.google.com/open?id=1Z2VaoKp8E_afaPzIX71mqqGGyBS93qFm

[Juha Holopainen]

At least in this case the EuroScope_crash_.dmp minidump was sufficient. It doesn't store the values of internal plugin variables but this issue could fortunately be fixed just by seeing where it crashed. As it happens, it's already fixed in the development build - it was the same line of code causing the maps coloring issue reported earlier in this thread. So depending on the lines surrounding the coordinate lines, you'll either see the map working as expected, something being wrong or the plugin just crashing at startup.

I'll publish the next beta in the next couple of days. Note that the faulty code here is only run on plugin startup and when manually reloading the plugin data files, i.e. whenever the Maps data file is read. It does not (at least directly) cause the crashes occurring later during a session reported by Oliver, I still need a crash dump from one of those. A minidump may be enough, but it probably doesn't hurt to take a big dump in the Task Manager as well (pun intended).

The dump via Task Manager probably has to be done before clicking "Retry" in that dialog, at least the one you sent now contained only one thread and its call stack was pointing to vSMR.dll, while the ES minidump contained 22 threads and pointed straight to my faulty code.

[Jason Leung]

Thank you