Tommaso Dalla Spada (1614361) With the latest beta the GS item in the labels seems to not work with our setup. Label=GND:DEP:0:ALRT,0,0:ASSR_E,0,1:COMM,0,1 Label=GND:DEP:1:CALLSIGN,0,0:WTC,0,1:DRWY,0,1 Label=GND:DEP:2:ATYP,0,1:GS,0,1 Label=GND:DEP:3:STS,0,0:RMK,0,1
Fatih Ilha (1885591) Tommaso Dalla Spada (1614361) can you tell me what did you do to make it has border like that? my current is like the your second picture. i want to make it look like the first picture.
Juha Holopainen (839337) @Tommaso Dalla Spada (1614361) Yes, sorry about that. One line of old redundant code caused the field to clear itself. As it was only a matter of removing that one line, I've compiled the plugin again with that fixed, just download the file again.
Mark-Julius Pikat (1051954) Bug 1: When loading the ground layout, I have LVP maps automatically enabled. Bug 2: In addition, maps causes following errors: [22:00:00] File GRpluginMaps.txt contains bad information: Line 910 : SYMBOL:HLS:N059.22.14.300:E024.33.14.898 // Alliku (Problem: Invalid longitude coordinate) // commenting slash at the end of the coordinate doesn't work anymore, and when removing those, I am getting another error: [22:01:45] File GRpluginMaps.txt contains bad information: Line 10272 : LINE:N059.25.04.556:E024.47.59.958:N059.25.04.634:E024.47.60.000 (Problem: Invalid line end position) (in previous versions those "60.000"-ending coordinates were drawing correctly)
Juha Holopainen (839337) (1) The LVP maps is probably an initialization order issue of some sort, as the correct maps appear at the next full minute when the map activation is automatically refreshed. I'll look into it. (2) Comments are supported only as their own lines. The function used by the code to read the last data field of a line may in some cases end up disregarding the comment text and thus provide the intended result, but it's a coincidence rather than design. It's always best to stick to the line syntax exactly as it is in the documentation - even if something else happens to work at one point, it may stop working later on. The same goes for invalid coordinate values - 60 seconds is not valid and instead of assuming the user meant the next full minute, the parser by design flags it as an error and forces the user to provide valid data.
Marius Linge (1621930) I'm unable to get GS working in labels with the following configuration. It seems that the label has allocated space for it, but no value is appearing. Label=GND:DEP:2:ATYP,0,0:WTC,0,2:GS,0,3:RMK,0,4 Label_GS=1,1,1,1
Juha Holopainen (839337) Marius Linge (1621930) I'm unable to get GS working in labels with the following configuration. It seems that the label has allocated space for it, but no value is appearing. The space before the RMK field looks about 4 whitespace characters wide as requested in your definition. Assuming you've read this thread before posting and downloaded the updated file, I'm not sure what the issue with the GS field would be as it seems to be working for me. @Hongye Rudi Zhang (1326158) The coordinate issue is a typo in the code. All the other formats should work fine but as changing all the coordinates in your files is probably not an option, you'll have to wait for the next update. Your Window_APP setting doesn't match with any of the possible options. You were likely going for the 6 parameter version <index>,<state>,<x>,<y>,<w>,<h> and are missing either the index or state parameter. @Sergej Singer (1407054) The code does currently work on the assumption that there are no duplicate "folder\name" entries and that it's therefore safe to stop looking after the first match is found. With airport-based filtering of the maps list, having duplicate entries in the data file is acceptable and I agree that the handling of them could be improved. Possibly the code could just look for the first map that would actually be drawn instead of the first in the data file - or just activate all matching ones. I'll evaluate the possible options.
Hongye Rudi Zhang (1326158) I got this error [19:00:51] File GRpluginMaps.txt contains bad information: Line 32 : COORD:N040.03.50.018:E116.36.41.223 (Problem: Invalid longitude coordinate) [19:00:51] File GRpluginStands.txt contains bad information: Line 3 : STAND:ZBAA:A106:N040.04.55.200:E116.35.00.600:25 (Problem: Invalid longitude coordinate) also [18:55:03] File GRpluginSettings.txt or GRpluginSettingsLocal.txt contains invalid data for item Window_APP (1,2160,1010,400,300)
Sergej Singer (1407054) Hi, I'm not sure if it should be considered feature or bug, but I have a problem. Let's say, I have 10 airport layouts and in every each of them there's a map for displaying Taxiway Labels. Every map is located in a folder "Labels" and called "Taxiways", so the path to every each of them is going to be Labels\Taxiways. As I found out, if you try to reference this map for a shortcut or for a OTHER_MAP_ACT, GRP will pick only the ever first defined map and ignore the rest 9, just like in TopSky. That's an issue. Of course the simplest solution would be to name every map differently, but that would eliminate the purpose to have simple names instead something like Label\EDDF Taxiways and so on. Would it be possible to make GRP (and TopSky as well in that matter) to pick up all the maps with the same name and turn them on, or make paths more specific like EDDF\Labels\Taxiways?
Marius Linge (1621930) Juha Holopainen (839337) Ground speed works again after updating to your hotfixed version. Thank you 😃
Luke Brown (1116943) Hi Juha, I'm adding the ability to mark stands with red labels if occupied etc. but it seems the only way to do this is make each label it's own map. This works functionally, but creates a rather large list in the maps folder. If I create a single map, if one stand is occupied, they all become red. Any better way of achieving this? for each stand for example I have two defintions: MAP:Stand Labels FOLDER:Dubai SMGCS FONTSIZE:-:2 ZOOM:800 ACTIVE:STAND:OCCUPIED:*:OMDB/F2 ACTIVE:STAND:ASSIGNED:*:OMDB/F2 ACTIVE:STAND:BLOCKED:*:OMDB/F2 ACTIVE:STAND:LIMITED:*:OMDB/F2 COLOR:SMGCS_TEXTSTAND TEXT:N025.15.17.465:E055.21.00.375:F2 MAP:Stand Labels FOLDER:Dubai SMGCS FONTSIZE:-:2 ZOOM:800 ACTIVE:STAND:OCCUPIED:OMDB/F2 ACTIVE:STAND:ASSIGNED:OMDB/F2 ACTIVE:STAND:BLOCKED:OMDB/F2 ACTIVE:STAND:LIMITED:OMDB/F2 COLOR:SMGCS_DUBCLOSED TEXT:N025.15.17.465:E055.21.00.375:F2
Juha Holopainen (839337) Luke Brown (1116943) Any better way of achieving this? Currently the "cleanest" option would be just to hide the maps from the list using the HIDDEN option but that does leave you without the possibility to toggle the map visibility.
Jonas Kuster (1158939) We get an issue with the MAXCODE restriction for a map. The TWY TYPE error is raised for any aircraft. The code is: COORDTYPE:TWYTYPE:NONE RESTRICTION:MAXCODE:E N046.13.31.214:E006.05.21.628 N046.15.05.267:E006.07.39.840 N046.14.52.194:E006.07.58.779 N046.13.18.192:E006.05.40.643 Anything has changed that I missed?
Juha Holopainen (839337) With the restriction maps, the order of the lines is important. The restriction conditions must be specified before the coordtype line. (Also if there's actually a space in front of the coordtype line in your data file, that'll cause any number of issues but the plugin should flag that as an unrecognized data line)
Jonas Kuster (1158939) Juha Holopainen (839337) Ok thanks. Changed the order. The space was created by the forum here when copying data.
Ricardo Sousa (1110850) ACTIVE:0507:1031:0:0000:2359 This line shows a map as automatic, but fails to activate the map. Using 1234657 instead of 0 for the SchedWeekdays works though
Juha Holopainen (839337) The code for the "0" weekdays expects the date in 6 digit format and as such, does not support recurring periods. I believe I fixed the same issue in TopSky and as the plugins share a lot of code in this area, it shouldn't be too difficult to implement the same fix for this plugin as well.
Jonas Kuster (1158939) Another issue I experienced today, probably related to other initialisation issues reported before: the APP window will initialise in the top left corner, half hidden. After removing some custom location and size parameters in my local settings, the window was small enough so that I could access the menu. When I click then on the APP window line, it will be initialised as I would expect it from the settings.
Juha Holopainen (839337) Jonas Kuster (1158939) Which setting or combination of settings leads to that behavior? Window_TSW_DefPos and Window_TSW_DefSize are both present at least in the current development code. They probably work in beta 2 already - just missing from the documentation - but if not, they will work in the future. The TSW and APP windows are created with the settings that are valid when the ASR is opened. I can see about making those windows respond to the settings reload as well, but are there some other settings that don't revert to the default values?
Jonas Kuster (1158939) A default position and size for the TSW similar to the APP window is not documented. Therefore I'm unsure if this would be supported. I was not able to try it due to the issues in the above thread. However, supporting this similar setting also for the TSW would be appreciated. A more generic issue is that while working and testing settings, when a line/parameter is removed from the files, the default parameters are not used when using the same instance of EuroScope and performing a reload of the GRP settings. The plugin default values are only considered once the ASR is closed and opened again. Is this a limitation of the environment or could this be fixed?
