Juha Holopainen Posted March 3, 2020 Report Share Posted March 3, 2020 (edited) A new beta version is available: TopSky plugin version 2.2.1 beta 11 Main changes from beta 10: Selections in Track Control Window are now radar screen specific Issues reported in the beta 10 thread addressed, except for the DCL issue when ADEP=ADES which I have not been able to reproduce, and there have been no further reports or logfiles about it. All intended plugin items now respond to the scale settings. Edited June 24, 2020 by Juha Holopainen 6 Link to comment Share on other sites More sharing options...
Oliver Gruetzmann (961224) Posted March 3, 2020 Report Share Posted March 3, 2020 Sorry for not getting back, about the other topic: It's a bit of frustration about the implementation, which, obviously, lead to other problems on FSLabs side. About Hoppie Airborne Client: It sends out Telex and the reply by ATC will be via Telex as well when using the Hoppie ATC client. The CPDLC part is invented by someone else. Hoppie himself states on his site: "The telex window is constructed with large quantities of similar messages in mind, to cater for the typical PDC case for a busy airport area." About the CDA: No, it doesn't work - this would need to be implemented correctly on the aircraft (the hoppie client doesn't allow an answer as well). See the example here: http://www.hoppie.nl/acars/prg/atc/ ("The Telex Window") Don't think this can be changed anyway, so - disregard. For now it doesn't work anyway on the FSLabs side so I don't use it. Link to comment Share on other sites More sharing options...
Juha Holopainen Posted March 5, 2020 Author Report Share Posted March 5, 2020 Okay, in order to not confuse new readers: The above is not a bug. On the plugin side the datalink clearance process is working as intended. On the message format level it's not handled exactly realistically but that's due to limitations of the Hoppie network (more specifically, the other clients on it). To make it work on FSLabs products, the necessary allowances would need to be made on their end. The reference to the DCL issue in the release notes is to a case reported in the beta 10 thread where a datalink clearance request for a local flight was not shown to the controller. That one I still consider a possible bug, pending more information. Link to comment Share on other sites More sharing options...
Jakob Arne Bronstad (1000634) Posted March 8, 2020 Report Share Posted March 8, 2020 (edited) Having problems with TopSky not taking the range/assigned SQ in SSR.txt document. Is this a bug or is anyone else have the same problem? Yes I have selected plugin under local settings CALLSIGN:MDT:LTR:BNO OR RANGE:2601:2677 ADEP:EN ADES:EN OR RANGE:4276:4277 REMARKS:TEST Edited March 8, 2020 by Jakob Arne Bronstad Jakob Brønstad Sectorfile Department Polaris FIR Link to comment Share on other sites More sharing options...
Juha Holopainen Posted March 9, 2020 Author Report Share Posted March 9, 2020 There are no known issues related to this and on my setup it's working. Check the reported state of the SSR codes data file in the Plugin Status menu. Link to comment Share on other sites More sharing options...
Jakob Arne Bronstad (1000634) Posted March 9, 2020 Report Share Posted March 9, 2020 The reported state is no errors. The plugin also taking SQ codes that is not in the SSR.txt file. Jakob Brønstad Sectorfile Department Polaris FIR Link to comment Share on other sites More sharing options...
Juha Holopainen Posted March 9, 2020 Author Report Share Posted March 9, 2020 The state is either "ok", "no data" or "bad data". If it's "ok" and a code other than one in the file is assigned, one possibility is that there were no possible codes available in the file, either no free codes in the assignable ranges or no assignable codes due to restrictions in the specified ranges. Link to comment Share on other sites More sharing options...
Christoph Paulus Posted March 24, 2020 Report Share Posted March 24, 2020 Hi Juha, I'm Chris, developer of the CPDLC/AOC Client, a Hoppie client to simulate the Airbus system (www.dalpi.de). I got contacted due to some problems with my software and TopSky regarding PDC. As there is no universal PDC standard, everyone handles the PDC differently. When vSMR came out a couple of years ago, I changed my software to be fully compatible with vSMR (which requires a telex as input and then sends out the PDC via CPDLC (without logon)). My question is, what kind of request does your software need (CPDLC/Telex), does it need a specific format and what does it send to the aircraft? You can also contact me directly: info at dalpi de. Best regards, Chris Link to comment Share on other sites More sharing options...
Juha Holopainen Posted March 24, 2020 Author Report Share Posted March 24, 2020 Hi Chris, we actually had some discussions back in early 2017, but it seems it was all about CPDLC. Since I did all sorts of testing to be compatible with both the original Hoppie client and yours, I either missed some tests or you changed your code after my tests. I'll email you with more details. Link to comment Share on other sites More sharing options...
Michael Eyecold (1283788) Posted March 30, 2020 Report Share Posted March 30, 2020 (edited) Hi Juha, currently having the problem, that I can not send "free text" as an answer via CPDLC to pilots (Current Msgs), as the "send"-button is free in space (can not reach it - window closes automaticly). Already talked to other ATC who have same issues. Will send a screenshot if needed. Didn't make one yet. Thanks for your great work Edited March 30, 2020 by Michael Eyecold 1 Link to comment Share on other sites More sharing options...
Juha Holopainen Posted March 30, 2020 Author Report Share Posted March 30, 2020 Sounds like I've added stuff to the window without remembering to increase the window area accordingly, I'll fix that. As a reminder to everyone, the ability to send these manually composed free text messages is intended for situations where the plugin fails to parse a downlink correctly leaving no other way to answer it. Any clearances uplinked using this method will not be displayed in the track labels and the responsibility for composing an understandable message lies with the controller typing it. 1 Link to comment Share on other sites More sharing options...
Michael Eyecold (1283788) Posted March 31, 2020 Report Share Posted March 31, 2020 Thank you Juha! Just wondering: is there currently any other chance to deny a direct request via CPDLC? Link to comment Share on other sites More sharing options...
Juha Holopainen Posted March 31, 2020 Author Report Share Posted March 31, 2020 All answers to direct-to downlinks are done using the NPT menu, see plugin manual chapter 4.14 1 Link to comment Share on other sites More sharing options...
Jan Doehring (1356262) Posted April 4, 2020 Report Share Posted April 4, 2020 I might have found a bug: When openning the extended tag of an assumed aircraft it stays open forever. Non-concerned aircraft seem to work and the extended tag closes after moving your mouse of the tag. I have yet to find the "trigger", but I think it has to do with the dummy item. Link to comment Share on other sites More sharing options...
Juha Holopainen Posted April 5, 2020 Author Report Share Posted April 5, 2020 A missing dummy item in your tag definition perhaps? Since the non-concerned tracks work, the dummy item is present in the 'untagged' level tag. I'd guess it's missing from the 'tagged' level tag. Link to comment Share on other sites More sharing options...
Jan Doehring (1356262) Posted April 5, 2020 Report Share Posted April 5, 2020 Yes, indeed. There was a misplacement in the tag. So, thats working as it should now... However, with "Dummy item - non-detailed" in the assumed and "Dummy item - detailed" in the detailed tag, the route draw disappers once I move my mouse from the assumed tags. Is that an intended behaviour? Link to comment Share on other sites More sharing options...
Juha Holopainen Posted April 6, 2020 Author Report Share Posted April 6, 2020 Yes, that's correct. 1 Link to comment Share on other sites More sharing options...
Bjoern Helge Smaavollan (1055999) Posted April 8, 2020 Report Share Posted April 8, 2020 Possible Bug When using A-version of plugin it is not possible to set dct to WPT/VOR/NDB by using the AHDG vector as stated in manual. Is this per design or is it a bug, as the manual on this point doesn't differentiate between A and B? Link to comment Share on other sites More sharing options...
Juha Holopainen Posted April 8, 2020 Author Report Share Posted April 8, 2020 It is per design, the manual doesn't seem to be up to date on that part. If desired, the functionality can be enabled in the settings. For example using Shortcut_AHDG_NoFixes_Combo=0x12 gives the functionality described in the manual (that's the default setting in type B). Link to comment Share on other sites More sharing options...
Jakob Arne Bronstad (1000634) Posted April 18, 2020 Report Share Posted April 18, 2020 In maps there might be a bug. when trying to use two different zoom levels in a map the map doesn't show. And negative values don't seem to work. QVOTE Dev manual. "There can be more than one zoom line in one map to hide parts of the map at different zoom levels. When the set value is negative, the following lines are not read when the radar screen is zoomed in more than the set value. when there is more than one zoom line in a map, their order is important (for example "ZOOM:5" has to be before "ZOOM:10" to have any effect as with zoom below 10 pix/nm the "ZOOM:5" line will never be read if it's after the "ZOOM:10" line...)" Jakob Brønstad Sectorfile Department Polaris FIR Link to comment Share on other sites More sharing options...
Juha Holopainen Posted April 18, 2020 Author Report Share Posted April 18, 2020 The negative values don't work, I'll fix that, but I have no problems with maps with two positive zoom levels defined. Link to comment Share on other sites More sharing options...
Adrian Bjerke (1339353) Posted April 18, 2020 Report Share Posted April 18, 2020 (edited) 6 hours ago, Juha Holopainen said: The negative values don't work, I'll fix that, but I have no problems with maps with two positive zoom levels defined. Could it be we have misunderstood the manual? We are attempting to create so a map is only displayed between certain zoom levels, for example between level 9 and 14, but it has no effect it seems like since it says displayed when you zoom past the point where it should be deactivated again. MAP:MSVA ENVA COLOR:MSVA FOLDER:MSVA ZOOM:9 ZOOM:14 FONTSIZE:=:10 STYLE:DOT MAP:MSVA ENVA COLOR:MSVA FOLDER:MSVA ZOOM:14 ZOOM:9 FONTSIZE:=:10 STYLE:DOT Neither of these has the effect that we are looking for. Edited April 18, 2020 by Adrian Bjerke Link to comment Share on other sites More sharing options...
Juha Holopainen Posted April 19, 2020 Author Report Share Posted April 19, 2020 The positive values allow the map processing to continue when the screen has more than the defined number of pixels per NM. To hide the map when zooming in, you'd need a negative zoom value, but they don't work in the current beta. Once they do, a map can be displayed between zoom levels 9 and 14 by defining ZOOM:9 and ZOOM:-14. 1 Link to comment Share on other sites More sharing options...
Jakob Arne Bronstad (1000634) Posted April 24, 2020 Report Share Posted April 24, 2020 On 18/04/2020 at 18:11, Juha Holopainen said: The negative values don't work, I'll fix that, but I have no problems with maps with two positive zoom levels defined. Is there an option to change the zoom on the same map based on whether you are CTR or APP? MAP:MSVA ENVA COLOR:MSVA FOLDER:MSVA ZOOM:9 FONTSIZE:=:10 STYLE:DOT Jakob Brønstad Sectorfile Department Polaris FIR Link to comment Share on other sites More sharing options...
Juha Holopainen Posted April 24, 2020 Author Report Share Posted April 24, 2020 No, you'll need two separate maps then 1 Link to comment Share on other sites More sharing options...
Recommended Posts