Juha Holopainen Posted October 3 Report Share Posted October 3 (edited) Changes from beta 5: Minor changes to area label layouts and mouse areas Updated Areas data file syntax (Categorydef line changed) Adjusted colors used in the Predicted Traffic and Operations Rate windows Upper wind & temp area must be defined in the settings to be able to download data (HTTP_GRIB_[Latitude/Longitude]_[Min/Max]) Bug fixes Edited October 18 by Juha Holopainen Link to comment Share on other sites More sharing options...
Mark Jansen (810676) Posted October 4 Report Share Posted October 4 (edited) Not sure if it's a bug or intentional, but I've noticed that the station requesting/initiating a ROF, doesn't get ROF displayed in the tag anymore. The receiving station does get it displayed as expected. That's different from v2.4 where both the requesting/initiating and receiving stations got ROF displayed in the tag. Mark Jansen Navigation & Sectorfiles Department Dutch VACC Edited October 5 by Juha Holopainen Link to comment Share on other sites More sharing options...
Juha Holopainen Posted October 5 Author Report Share Posted October 5 For the COOPANS setup, both controllers should see the indication (for the other setup, only the receiving one). I can think of a couple of things that may have broken this that should be easy to fix, hopefully it's one of them. Link to comment Share on other sites More sharing options...
Martin Loxbo (811805) Posted October 5 Report Share Posted October 5 This is what it looks like when I try to edit the End Time. Looks like the click areas for the various columns are shifted somehow. Link to comment Share on other sites More sharing options...
Juha Holopainen Posted October 6 Author Report Share Posted October 6 17 hours ago, Martin Loxbo (811805) said: This is what it looks like when I try to edit the End Time. Looks like the click areas for the various columns are shifted somehow. Yes, a typo in the code. After defining one of the click areas, instead of shifting the click area left edge right by X characters for the next definition, the code sets it at X characters from the line start, causing the following areas to be misaligned and overlap some of the previously defined ones. 1 Link to comment Share on other sites More sharing options...
Mark Jansen (810676) Posted October 7 Report Share Posted October 7 Quote For the COOPANS setup, both controllers should see the indication (for the other setup, only the receiving one). I can think of a couple of things that may have broken this that should be easy to fix, hopefully it's one of them. We're using the COOPANS (B) setup indeed. Would be great if you could verify that ROF is working as it should. Mark Jansen Navigation & Sectorfiles Department Dutch VACC Link to comment Share on other sites More sharing options...
Luke Brown (1116943) Posted October 8 Report Share Posted October 8 (edited) Hi Juha, unsure when this problem was specifically introduced. I have areas defined in TopSkyMSAW.txt. It seems to add an extra area of the same size to every definition. This seems to be repeated for all of the lines defined using the same format. Those defined with polygons rather than min lat/lon seem to be unaffected. Appreciate you taking a look. Cheers. Example below, the third column of rectangles shouldn't be there. Edited October 8 by Luke Brown (1116943) Link to comment Share on other sites More sharing options...
Juha Holopainen Posted October 8 Author Report Share Posted October 8 1 hour ago, Luke Brown (1116943) said: unsure when this problem was specifically introduced. I have areas defined in TopSkyMSAW.txt. It seems to add an extra area of the same size to every definition. This seems to be repeated for all of the lines defined using the same format. Those defined with polygons rather than min lat/lon seem to be unaffected. Appreciate you taking a look. Cheers. This is a display problem only, no warnings will be given in the extra area. I can't remember the reasoning behind it, but I've probably added the extra area as a safeguard against rounding issues near the easternmost edge and then forgot to hide it in the debug drawing. I'll get it sorted one way or another. Link to comment Share on other sites More sharing options...
Bence Bozi (1300686) Posted October 9 Report Share Posted October 9 Since this update, the active area labels do not show start/end times with this CATEGORYDEF: CATEGORYDEF:LHD:6:7:20:8:9:10:1:1:1:1:1 All option are 1 (ON). What can be the problem? In Airspace TSA menu, i see the start and end times. Link to comment Share on other sites More sharing options...
Juha Holopainen Posted October 11 Author Report Share Posted October 11 The display of the times is no longer available by default in the COOPANS=0 setup. The availability and default visibility in the reduced label can be set using the Areas_Label_* settings, and the default visibility setting can then be overridden in the category definition (the availability must be set though as it's system-wide setting that's used to tell if the item can ever be displayed in the label). For the times, it would be Areas_Label_Times=1,0 (or 1,1). Link to comment Share on other sites More sharing options...
Bence Bozi (1300686) Posted October 11 Report Share Posted October 11 1 hour ago, Juha Holopainen said: Az idők megjelenítése alapértelmezés szerint már nem elérhető a COOPAN S=0 beállításban. Az elérhetőség és az alapértelmezett láthatóság a csökkentett címkében az Areas_Label_* beállításokkal állítható be , majd az alapértelmezett láthatósági beállítás felülírható a kategóriadefinícióban (az elérhetőséget azonban be kell állítani, mivel ez egy rendszerszintű beállítás, amely azt jelzi, hogy a elem bármikor megjeleníthető a címkén). Az időkhöz ez lenne: Areas_Label_Times=1,0 (vagy 1,1). Thank you! Link to comment Share on other sites More sharing options...
Ricardo Sousa (1110850) Posted October 12 Report Share Posted October 12 (edited) Spoiler Small feature request for a future version, proper SID/STAR allocation acknowledgment function: Right now when you select a procedure from the SID or STAR menu it is inserted on the flight plan but is displayed as "allocation acknowledged" straight away on the sector lists. My proposal is: A new function called "Acknowledge SID allocation", same for STAR. All the function does is append a "+" to the beginning of the fpl for SIDs, and at the end for STARs. SID/STAR allocation color also checks for the "+", and only if its present does it change colors. There's an edge case that needs to be taken into account, that is if you try to acknowledge a procedure that was automatically selected by EuroScope, hence doesn't have the "DIVAM4A/22L" string in the flight plan, the acknowledge function needs to also add the procedure, so "DIVAM4A/22L+". End goal is to have this function assigned to right clicking the SID or STAR field on the Sector List to acknowledge an allocation, and being able to pick different procedures without them getting acknowledged right of the bat. Afaik, this is closer to the behavior of the real thing. Bit of a janky solution I admit, but hey it seems to work... I tested around in sweatbox with both SIDs and STARs, manually adding the "+" to the flight plant. Everything still worked, route was drawn correctly, could still pick another procedure (and it removes the "+" if it was present too). There's a mention of the "+" symbol in https://www.euroscope.hu/wp/non-standard-extensions/ which is what inspired me. I think it was some left over from VRC days? I certainly remember seeing it a bunch in the US some years ago. Anyway I've added the logs of those sweatboxes in case they help, I played around with AFR10TL on the SID and TAP168U on the STAR files. nevermind, this feature already exists Edited October 12 by Ricardo Sousa (1110850) nevermind, I was asking for a feature request that already exists Link to comment Share on other sites More sharing options...
Recommended Posts