Juha Holopainen Posted October 7, 2020 Report Share Posted October 7, 2020 (edited) A first beta of version 2.3.1 Main changes from version 2.3: Bug fix: brightness-controlled plugin colors will now properly respond to being changed in the settings even when the open ASR file specifies the "NoDraw" flag. Added option to customize rounding of metric levels, and to display specific levels in the metric mode of altitude related plugin menus Added option to filter non-departed tracks from MTCD processing (default setting is to filter until the track starts taxiing) Added settings to adjust some Airspace Management Window column widths Updated Areas and Maps data file syntaxes (hatch fills possible, text alignment adjustable in maps) The settings spreadsheet now includes a tab listing the added/changed/deleted settings since the previous release version. Only post bug reports and questions about the new features in this thread. Edited November 25, 2020 by Juha Holopainen 3 Link to comment Share on other sites More sharing options...
Ricardo Sousa (1110850) Posted October 10, 2020 Report Share Posted October 10, 2020 This was happening before, since maybe the last 2 or 3 betas at least. When transferring communications through CPDLC it writes down the vatsim logon of the next unit, instead of the one defined in TopSkyCPDLC.txt. I can't discard having something wrong in the setup but this is what I have: I expected it to send CONTACT MADRID CTL 133.750 instead. LECM didn't have CPDLC at the time, but the message should still be this even if the next unit isn't cpdlc Link to comment Share on other sites More sharing options...
Juha Holopainen Posted October 11, 2020 Author Report Share Posted October 11, 2020 If Madrid would have had CPDLC, the sent message would have been "CONTACT LECM 133.750 MADRID CTL". I'll adjust the code to send "CONTACT 133.750 MADRID CTL" when no CPDLC is detected (and "CONTACT <freq> <vatsim_login>" in case the RTF callsign isn't found in the data file). I'll leave the CPDLC logon out to avoid confusion when it's not detected as being online. Regarding the data file, the CPDLC logons should be unique to prevent problems. For example with the above setup, if "LE" is online and logged on as "LECM" on Hoppie, and "LEW" is online as well but logged on as something different on Hoppie or not at all, transferring aircraft to "LEW" will handover their CPDLC connection to "LE" (the plugin sees the transfer to "LEW", checks the data file for a matching Hoppie logon, finds "LECM", sees it being online, and then automatically hands over the CPDLC connection to it). 1 Link to comment Share on other sites More sharing options...
Michael Eyecold (1283788) Posted October 11, 2020 Report Share Posted October 11, 2020 I just noticed, that I didn't get a notification within ES for this update ;o) Cheers Link to comment Share on other sites More sharing options...
Ricardo Sousa (1110850) Posted October 12, 2020 Report Share Posted October 12, 2020 13 hours ago, Juha Holopainen said: If Madrid would have had CPDLC, the sent message would have been "CONTACT LECM 133.750 MADRID CTL". I'll adjust the code to send "CONTACT 133.750 MADRID CTL" when no CPDLC is detected (and "CONTACT <freq> <vatsim_login>" in case the RTF callsign isn't found in the data file). I'll leave the CPDLC logon out to avoid confusion when it's not detected as being online. Well, irl the message is always formated the same, regardless if the next unit provides cpdlc or not. You can only tell so by noticing if the next unit xxxx gets displayed or not. Practical example of this is LECM overflights with destination inside of LPPC, next unit LPPC will never show, eventually a CONTACT LPPC 132.305 LISBOA CTL message is sent, and then the cpdlc connection is just lost. (For context, as published LPPC is DLIC only, but in practice arrivals and departures never get any cpdldc, overflights do though) Again irl, the behaviour should be that it closes connection on receipt of the wilco response. Then the next unit takes takes over, and if there isn't one, it just dies. Side note, I have noticed that when ending cpdlc connections pilots are being displayed with at least one message, which judging by the cpdlc current message window is the service terminated message. We are never displayed this message irl, the connection just abruptly drops. Side of the side note, it would be nice to have a setting we could define how far in advance the logo auto accept function works, so say that notification should be done 10 minutes to yhe border, then it should accept the logon 10 minutes prior to active sector entry. Link to comment Share on other sites More sharing options...
Juha Holopainen Posted October 12, 2020 Author Report Share Posted October 12, 2020 The plugin's datalink functionality is a combination of reality, limitations imposed by VATSIM and Hoppie and simplifications to allow for the average user not being a trained professional. If improvements are made in the capabilities of the latter two, the combination can be made closer to the first. 1 Link to comment Share on other sites More sharing options...
Recommended Posts