TopSky plugin 2.2.1 beta 12

[Juha Holopainen]

Beta 12 is now available (it was either now or after the summer... hopefully I was able to avoid the most obvious bugs in the new code):

TopSky plugin version 2.2.1 beta 12

Main changes from beta 11:

• Datalink clearance messages split into header and message parts. Unless you've adjusted the error and/or status messages the effect of this is limited to the clearance message itself. Even that usually doesn't require immediate action as the plugin will just replace everything up to and including <endheader> with the new default header part which can be adjusted in the plugin settings if required
• STCA data file syntax updated with a possibility to add an NTZ definition (extends STCA alerting down to ground level within the defined area)
• Primary radar video takes ESE file radar holes into account if no terrain masking data is defined for a radar station
• SSR data file syntax updated with type and descr keywords
• Maps data file syntax updated with screen-specific and asrdata keywords
• Callsign data file syntax updated with a possibility to refer to another file
• If an assumed track disconnects more than 2nm from destination, certain controller-entered data (AHDG, ASP, DCT, CFL etc.) is kept in memory for a pre-defined time (5min by default). If the track re-connects within that time and is still inside your airspace, the track is automatically assumed and the data re-applied. The data is also re-applied if the track is outside your airspace and you manually assume it again. Feedback on this would be appreciated even though it may be difficult to gather, as if it works correctly, you may not even notice it happening (which is of course the goal here, but I won't keep it in the code if I'm not sure if it works or not...)
• Things I indicated I'd fix on the beta 11 and various other threads
• "CPDLC-enabled" tag items that have a "(DEP list)" version no longer display the square brackets or empty spaces around them. This may require changes to your DEP list definitions.
• Manual sets completely revised
• Performance tuning. Based on tests, compared to version 2.2.0.1, the beta 12 code uses from 41.84% to 52.86% less CPU [the method used provides an accuracy at least 7.39% better than using the Stetson-Harrison method] (it's not really a fair comparison or exact science for various reasons, and it only translates to a 17-18% reduction in the whole EuroScope process CPU usage which is the number that really matters, but the bigger numbers look better in advertising)

What to do if a CTD happens (no need to memorize all this, just remember to come back and read this if it happens):

A crash dump is the best way for me to find out what went wrong. Depending on the EuroScope version, it may or may not make an automatic crash dump in the same folder as EuroScope.exe. It'll be named "EuroScope_crash_.dmp". If the EuroScope process is still alive (it didn't crash straight to desktop without an error message), a manual dump with some more information can be made in Task Manager: in the Processes tab, right-click on the EuroScope app and choose "Create dump file". Should a 'clean' CTD happen (no error message, just straight to desktop), or if you didn't remember to make a dump in Task Manager, Windows may have made an automatic crash dump in "%APPDATALOCAL%\CrashDumps". The filename is EuroScope.exe.<number>.dmp .

The small EuroScope-generated dump is usually enough to fix a bug, the slightly larger Windows-auto-generated one a bit more likely, and the one from Task Manager should cover all needs, but it's also a couple of hundred megabytes in size, so it's easiest to start with the smaller ones first as they can easily be attached to a forum message or uploaded anywhere for me to have a look.

Edited August 9, 2020 by Juha Holopainen

[Juha Holopainen]

For the Finnish setup, beta-specific settings and data files can be downloaded HERE. The package contains an updated Lists settings file (updated DEP list definition) as well as some plugin data files (contain some items 2.2.0.1 won't understand). They should only be used with this beta version or later. None of them are mandatory but at least the lists file is recommended to make the DEP list look as it should.

Edited August 9, 2020 by Juha Holopainen

[Jan Doehring (1356262)]

Thanks Juha! Whilst updating my config I ran across something. With the last beta (11) of Topsky we had our Military CTRs displayed according to their official activation times. This was done using multiple activation lines. Worked like a charm!

When using the exact same config now, I get following error: 

This is the code:

MAP:Tower CTR ETSI
ZOOM:7
FOLDER:Military CTR
COLOR:greysector
STYLE:Dash
LINE:N048.47.10:E011.20.50:N048.49.20:E011.44.45
LINE:N048.49.20:E011.44.45:N048.43.35:E011.48.00
LINE:N048.43.35:E011.48.00:N048.37.45:E011.24.00
LINE:N048.37.45:E011.24.00:N048.47.10:E011.20.50
LINE:N048.47.10:E011.20.50:N048.47.10:E011.20.50
ACTIVE:0101:1231:1234:0000:2359
ACTIVE:0101:1231:5:0000:2300
ACTIVE:0101:1231:7:2300:0000

 

Debugging done by me so far: 
- Map is not located in TopskyMapsLocal.txt. Actually we don't even use that file.
- I removed the folder line. Still gives me the same fault after reloading the maps.

I have a feeling, that it has to do with using multiple activation lines: Once I remove two and leave only one, Topsky seems to be happy. This is with the FOLDER-line removed.

 

EDIT: With a folder line or more than one active line, I always get the fault message. I dont think this exact behaviour is intentional, is it? 

Edited June 10, 2020 by Jan Doehring

[Juha Holopainen]

The error message is intentional with the folder set. Previously the folder name was just silently changed to "AUTO" as all automatically activating maps are supposed to be in that folder. I haven't looked but I bet the error-checking code is now enforcing the "no folder" rule a bit too eagerly. With the folder name automatically set to "AUTO" by the first ACTIVE line, the code then raises an error when it sees a folder name set while reading the second ACTIVE line. I'll get that fixed eventually but it'll take at least a couple of weeks.

[Oliver Gruetzmann (961224)]

The error appears with no FOLDER line and several ACTIVE lines.

I get the error with this entry:

MAP:Tower CTR ETSI
ZOOM:7
STYLE:Dash
COLOR:greysector
LINE:N048.47.10:E011.20.50:N048.49.20:E011.44.45
LINE:N048.49.20:E011.44.45:N048.43.35:E011.48.00
LINE:N048.43.35:E011.48.00:N048.37.45:E011.24.00
LINE:N048.37.45:E011.24.00:N048.47.10:E011.20.50
LINE:N048.47.10:E011.20.50:N048.47.10:E011.20.50
ACTIVE:0101:1231:7:2300:0000
ACTIVE:0101:1231:1234:0000:2359
ACTIVE:0101:1231:5:0000:2300

Commenting out two of three ACTIVE lines makes them work again.

[Oliver Gruetzmann (961224)]

I've had two CTDs without errors in the last days.

Not sure if they're related to Topsky, but they happened after the update to the last beta. Might also be related to the GRPlugin crashes I've had (but didn't encounter after fixing the GRpluginMaps file).

First Crash produced a dump in AppData\Local\CrashDumps as well as a dump in the EuroScope directory, second crash only in CrashDumps directory (see time stamps).

I'm not sure if I still use the debug version of grplugin, but I think so.

Oliver.

EDIT: Crashes only happened on the main instance, first one some minutes into the session, second one roughly 1,5 hours into the session.

CrashDumps.7z

Edited June 15, 2020 by Oliver Gruetzmann

[Juha Holopainen]

I’ll have a look, hopefully I can find the cause this time. It’ll be a week or so until I’m anywhere near a computer though, but I’ll get around to it eventually.

[Matisse VanWezer (1385143)]

Hey

Just wanted to let you know that the reapplying/assuming feature doesn't seem to work here at EBBU. 

Then I just had two more questions.

What's the difference between "(2+)" and "unselected track" for the tag items? I still haven't figured that one out yet...

And  secondly, are all of these mode S downloaded tag items functional? Only DHDG and DRC seem to be working. If not all are functional what was the reasoning about adding them in anyway? Future proof? Perhaps it works on something else?

 

Thank you!

[Oliver Gruetzmann (961224)]

21 hours ago, Matisse VanWezer said:

What's the difference between "(2+)" and "unselected track" for the tag items? I still haven't figured that one out yet...

From the dev manual:

Quote

Tag items marked “(0-1)” are only displayed when the track is unconcerned or notified, items with “(2+)” when the track is in any other state. Other items are shown in all states

You can add or change items based on the state (for example, NFL while inbound your sector, XFL when tracked).

[Ricardo Sousa (1110850)]

Toggle route draw on the departure list for aircraft on the ground draws the route correctly, but only for a few seconds, 2 at most, actual time it shows varies. Works without problem on aircraft tags though.

 

side note, i've not had any crashes or issues with activation lines, but we only have areas with active lines, multiple of them for the same area sometimes even, we dont have nothing for maps

[Thomas Ljung (1253198)]

43 minutes ago, Ricardo Sousa said:

Toggle route draw on the departure list for aircraft on the ground draws the route correctly, but only for a few seconds, 2 at most, actual time it shows varies. Works without problem on aircraft tags though. 

For me it doesn't work at all from all lists. Have changed to Euroscope equivalent function. 

[Juha Holopainen]

@Oliver Gruetzmann, sadly the crash dumps do not point to any plugin code. I've forwarded the dumps to Gergely, perhaps he can see if the crash was due to EuroScope, and if not, then which one of the plugins...

@Matisse VanWezer, as the manual (General part, Appendix 1) says, most of the mode S items are blank as the information is not available in the network data. Even the DRC item is just the calculated value as no downlinked value is available. The only one of the mode S items that actually shows a downlinked value is DHDG. Perhaps the data will be available in the future, who knows, but for now most of the items act like no data is received -> blank.

The route draw was changed to be automatically removed after a specific time if no tag was shown. This was done to avoid getting routes stuck on the screen if for some reason the flight was removed from the list, for example by another controller logging on in that airspace. The timer would automatically refresh when a detailed tag was drawn to keep the route displayed. Looks like I need to figure out another way to get around this issue.

[Juha Holopainen]

@Oliver Gruetzmann, Gergely could not debug the crash dumps as he had already moved on to newer code. Please use the new EuroScope beta r25, hopefully we'll have better luck with that if the crash happens again.

[Oliver Gruetzmann (961224)]

55 minutes ago, Juha Holopainen said:

@Oliver Gruetzmann, Gergely could not debug the crash dumps as he had already moved on to newer code. Please use the new EuroScope beta r25, hopefully we'll have better luck with that if the crash happens again.

Thanks for the feedback. Still waiting for the next one. They somehow happen 2 or 3 times and disappear after that.

[Juha Holopainen]

On 18/06/2020 at 22:16, Matisse VanWezer said:

the reapplying/assuming feature doesn't seem to work

Based on some testing, it would seem that when the plugin is notified of a track disconnecting by EuroScope, the flightplan data and information whether the track was assumed or not are already lost, so the code had nothing to save anymore. I've tested a workaround which saves the data with each position update, and it seems to work at least in a test setup. The downside is the additional code being run - the data being saved for all assumed tracks on each position update rather than just when an assumed track actually disconnects - but with all the recent performance improvements in the code, I think I can live with this setback.