Jump to content

TopSky plugin 2.2.1 beta 11


Juha Holopainen
 Share

Recommended Posts

Juha Holopainen

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 by Juha Holopainen
  • Like 6
Link to comment
Share on other sites

Oliver Gruetzmann

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.

Annotation 2020-03-03 191957.png

Link to comment
Share on other sites

Juha Holopainen

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

Jakob Arne Bronstad (1000634)

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 by Jakob Arne Bronstad

Jakob Brønstad
Sectorfile Department Polaris FIR

Email.png

Link to comment
Share on other sites

Juha Holopainen

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

Jakob Arne Bronstad (1000634)

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

Email.png

Link to comment
Share on other sites

Juha Holopainen

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

  • 3 weeks later...
Christoph Paulus

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

Juha Holopainen

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

Michael Eyecold (1283788)

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 by Michael Eyecold
  • Like 1
Link to comment
Share on other sites

Juha Holopainen

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.

  • Like 1
Link to comment
Share on other sites

Michael Eyecold (1283788)

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

Jan Doehring (1356262)

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

Juha Holopainen

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

Jan Doehring (1356262)

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

Bjoern Helge Smaavollan (1055999)

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?

0

Link to comment
Share on other sites

Juha Holopainen

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

  • 2 weeks later...
Jakob Arne Bronstad (1000634)

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

Email.png

Link to comment
Share on other sites

Juha Holopainen

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

Adrian Bjerke (1339353)
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 by Adrian Bjerke

Adrian Bjerke
Training Director

Link to comment
Share on other sites

Juha Holopainen

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.

  • Like 1
Link to comment
Share on other sites

Jakob Arne Bronstad (1000634)
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

Email.png

Link to comment
Share on other sites

  • Juha Holopainen locked and unpinned this topic
Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...