Hello!
For those who don’t know me, I am Kirollos, the author of the DiscordEuroscope plugin which has been providing the rich presence feature for EuroScope controllers since 2018. Ever since that, I have not done much development except a few commits that have not even seen a full release.
I’m writing this topic to introduce the progress of the new version v1.3.0 that I have been working on the past couple of weeks. The progressed work so far achieves the following major points:
Easy configuration using JSON. Users will no longer need to recompile the solution to implement their own version of rich presence).
Implementation of some sort of custom logic via the config file.
Radio callsigns can match callsigns using regex.
I’d like to hear from the community their thoughts on the ideas I’ve shared so far and any improvements/suggestions to be committed before the release are appreciated!
Would it be possible for the plugin to automatically load the callsigns and active (prim freq activated, not depending on callsign) position from the ESE file?
Till now, the ES PlugIn environment does not expose radio callsigns registered in the ESE file.
The old and new implementation of custom config for radio callsign were designed to overcome this problem. This may change in the future if the new PlugIn interface allows us to do so.
Moreover, I’m thinking of extending the radio callsign detection using primary frequency as an extra parameter rather than fully relying on matching with the logon callsign. What do you think about that?
A number of plugins allow to specify the (relative) path of the ese file, which will then be parsed by the plugin. Maybe this could also be an option?
Alternatively, it would be helpful if the position format of the ese file is recognised, so that simply the part of the ese file can be copied to the plugin config. The need for a specific format means just a lot of work so that the plugin can read this info.
I wrote some code to parse the .ese file which turned out to be working good. Do you think it would be better to force-pair the radio callsigns with the primary frequencies instead of the logon callsign? I may actually add an option for the user to choose between the pairing method whether it should be the logon callsign or the primary frequency.
I don’t know when you would prefer callsign over frequency, as the frequency controls which position you are handled as, directly connected with airspace ownership etc
In case you have the same frequency used multiple times, but at different airports, which can easily be the case for ground and tower positions, if they are far away from each other. But since the range of these station is quite limited, this could be possible even within a single sector file.
Indeed. I’m working on combining both the callsign ICAO (i.e XXXX from XXXX_*_YYY) and its primary frequency for a more accurate match. I’ll finalize this addition and publish a pre-release DLL for the public to test.
The option to load the radio callsigns from the [POSITIONS] section of the sector’s .ese file has been implemented. Therefore, the “radio_callsigns” structure has been changed to the following:
true: parse and load the radio callsigns from the [POSITIONS] section of the located .ese file.
false: load the radio callsigns from the custom section which supports literal and regex callsigns.
path_to_ese
type: string
value: Absolute or relative path to the directory that has the required .ese file. Note that the relative path should be relative to the path of the DiscordEuroscope.dll!
For example if we have the following tree, The relative path would be ..\\..\\ and the absolute path would be D:\\ZZZZ-Install-Package_20230126160923-230101-0001\\:
[!WARNING]
Relative path would be preferred if the configuration is to be shipped in a package for end-users where the structure of the directories are the same for all users. The absolute path will always be different from a machine to another.
custom is an array of objects where each object consists of three elements:
callsign: (string): The literal callsign or regex formula to match the callsign
frequency: (string) (optional): Frequency of the station for a stricter matching.
rcallsign: (string): The radio callsign.
Parsing from .ESE file
Since parsing the radio callsigns from positions is not provided by EuroScope’s PlugIn API, it was suggested by members of VATSIM that locating and parsing the .ese file manually would be a better alternative, as some people would prefer to load callsigns directly from the sector files rather than have a dedicated list for the plugin. The logic of this system is that the system will decide the radio callsign based on the combination of the primary frequency of the controller and the prefix ICAO of their callsign. This will prevent two stations having the same frequency to be confused, as well as preventing missing a slightly modified callsign.
Examples:
If we have two stations defined HExx_GND and HEyy_GND where both are quite far from each other physically and they both have the same frequency 121.900 MHz. If the controller is on the HExx station, the system will decide the radio callsign based on:
The controller is selecting their primary frequency to 121.900 MHz.
The controller is holding a callsign that begins with HExx, even if it is slightly derived from the original callsign like HExx_P_GND.
If we have a single station defined as HECC_3_CTR with a primary frequency of 126.600 MHz:
As long as the controller is primary on 126.600 and their callsign begins with HECC, it will always refer to the radio callsign of HECC_3_CTR.
Testing
I’d appreciate testing all the items discussed beforehand with feedback to whether we should further improve any feature introduced and/or whether there are bugs discovered to fix. New ideas are also encouraged!
Every commit pushed to the branch v1.3.0 will be automatically built by GitHub and will be passed to the Releases page of this repository.
This update post is reflecting on the prelease tag 1.3.0-pre-20240414-0733Z.
Thanks
Thanks to Max and Jonas for their input and feedback!
Can the relative path also hold parts of the file name to ensure a correct match? Because one might have multiple ese files (from different FIRs) and it would be important that the “correct” one is used also when using a relative path.
I may look into adding an optional element in the config object whether to target specific .ese files with regex or wildcard matching the file names. But the code I wrote is going to loop through all existing .ese files in the given directory and parse them all; If a callsign is found twice it is ignored. Do you think this can cause problems? From my experience I’ve only seen a single ese file for the whole sectorfile so I’ve never encountered multiple .ese file in the same package. Thus my question if you think it’s recommended to filter the found .ese files with a defined prefix.
Ah ok. I think if you loop through all the ese files this will be fine, too. I agree that there is usually only one sectorfile for one FIR/vACC. But if a controller is active in multiple FIRs/vACCs (maybe as a visitor) there may be multiple files. Depends also a bit on the folder structure you use. The one used by GNG (which is widely used in Europe) is that the sct/ese file are in the root Europscope data folder, and other data is then in a separate folder named after the FIR/vACC.
My initial idea was just because there is a similar option for plugins like GRP. But the situation is not exactly the same. So I think your approach is fine for the purpose of your plugin.
I’d like to announce that v1.3.0-rc1 has been released for the public to test and provide feedback. I am looking forward to fully releasing v1.3.0 before Christmas
Unfortunately, I have not yet written a proper changelog for the RC but it’s mostly concluded from the original post + the updates mentioned in the discussion thread.
