v1.3.0: What's progressed so far and ideas

[Kirollos]

Hello!

Since I am having some free time this month, I got interested again in doing more work on DiscordEuroscope and look for ideas to improve and make things easier for user-end. Most of the complaints I've heard the past couple of years were mainly related to customization which required modifying the source code and recompilation. Hence, it was my main priority to work on making everything configurable by the user.

The main purpose of this discussion topic is to share ideas to further improve v1.3.0 branch before release. I'd be more than happy to hear feedback, suggestions and contributions too!

Branch: https://github.com/Kirollos/DiscordEuroscope/tree/1.3.0

JSON Configuration File

JSON being a simple and dynamic method of configuration, rapidjson header library is used to serve the purpose of supporting JSON parsing.

This is the structure so far:

{
    "discord_appid": "477907858072272896",
    "discord_presence_large_image_key" : "es",
    "discord_presence_small_image_key" : "ttrks",
    "sweatbox_bypass" : false,
    "states" : {
        "idle": {
            "presence_small_image_key": "",
            "presence_large_image_key" : "",
            "state" : "",
            "details" : "Idle",
            "presence_small_image_text" : "lol i'm idle small text",
            "presence_large_image_text" : "lol i'm idle large text"
        },
        "playback": {
            "presence_small_image_key": "",
            "presence_large_image_key" : "",
            "state" : "",
            "details" : "Playback",
            "presence_small_image_text" : "",
            "presence_large_image_text" : ""
        },
        "sweatbox": {
            "presence_small_image_key": "",
            "presence_large_image_key" : "",
            "state" : "sweating someone",
            "details" : "Sweatbox",
            "presence_small_image_text" : "",
            "presence_large_image_text" : ""
        },
        "direct": {
            "presence_small_image_key": "",
            "presence_large_image_key" : "",
            "state" : "",
            "details" : "",
            "presence_small_image_text" : "",
            "presence_large_image_text" : "",
            
            "if_observer" : {
                "presence_small_image_key": "",
                "presence_large_image_key" : "",
                "state" : "Aircraft in range: {total_inrange}",
                "details" : "Observing as {callsign}",
                "presence_small_image_text" : "",
                "presence_large_image_text" : ""
            },
            
            "if_controller": {
                "presence_small_image_key": "",
                "presence_large_image_key" : "",
                "state" : "Controlling ({current_tracked} of {total_inrange})",
                "details" : "{rcallsign} {frequency}MHz",
                "presence_small_image_text" : "Total trakcs: {total_tracked}",
                "presence_large_image_text" : "{callsign}"
            },
            
            "if_supervisor": {
                "presence_small_image_key": "",
                "presence_large_image_key" : "",
                "state" : "",
                "details" : "",
                "presence_small_image_text" : "",
                "presence_large_image_text" : ""
            }
        }
    },
    "radio_callsigns": {
        "^HECC_CTR$": "Cairo Control Bandbox",
        "^HECC_(\\d+)(?:_)CTR$" : "Cairo Control ACC $0"
    }
}

The JSON object consists of the following:

1. Global elements

• discord_appid: The discord application ID. This defaults to the default appid created by me that has been used by default since the beginning. Now this can be configured as easy as modifying the json file.
• discord_presence_large_image_key: key of the large image in the assets page.
• discord_presence_small_image_key: key of the small image in the assets page.
• sweatbox_bypass: boolean to toggle whether to ignore the detection of sweatbox connection. true to treat sweatbox connection as a direct connect.

2. State elements
   Apart from the global elements mentioned above, any of the following states can have the higher priority of the image keys over the global one declared beforehand. If the keys are left as an empty string, the global keys are used.
   1. Idle state
   • presence_small_image_key: Image key to use for the idle state only. If left empty, the global one mentioned in the global section is used instead.
   • presence_large_image_key: Same as above
   • state: State message for the idle state.
   • details: Details message for the idle state.
   • presence_small_image_text: Image text for the idle state.
   • presence_large_image_text: Image text for the idle state.
   2. Playback state
   • presence_small_image_key: Image key to use for the playback state only. If left empty, the global one mentioned in the global section is used instead.
   • presence_large_image_key: Same as above
   • state: State message for the playback state.
   • details: Details message for the playback state.
   • presence_small_image_text: Image text for the playback state.
   • presence_large_image_text: Image text for the playback state.
   3. Sweatbox state
   • presence_small_image_key: Image key to use for the sweatbox state only. If left empty, the global one mentioned in the global section is used instead.
   • presence_large_image_key: Same as above
   • state: State message for the sweatbox state.
   • details: Details message for the sweatbox state.
   • presence_small_image_text: Image text for the sweatbox state.
   • presence_large_image_text: Image text for the sweatbox state.
   4. Direct state
      Same story as mentioned in the other three states. But there are two additional points to consider:
   • There are additional states inside the direct state if the direct state is an observer, a supervisor or a controller state. Each state has its own optional section which can be completely removed from the JSON file if not needed.
   • The custom elements in the direct states can have variables in them which are internally processed by the plugin in runtime. This allows full customization however the user wants.
3. Radio Callsigns
   radio_callsign is an object that consists of:
   • the key: the callsign matching criteria (supports regex with matching results replacement in the radio callsign)
   • the value: The Radio Callsign text
     Example:

"radio_callsigns": {
    "^HECC_(\\d+)(?:_)CTR$" : "Cairo Control ACC $0"
}

This will match any callsign in the format of HECC_xx_CTR where xx is any amount of digits and the radio callsign would be processed as Cairo Control ACC xx

The concept of global vs local elements

Would there be a better way to implement the global and local elements?

The variables

The currently implemented variables are the following:

• {callsign}: Callsign (example: HECA_APP)
• {rcallsign}: Radio Callsign (example: Cairo Director)
• {frequency}: Frequency in format xxx.yyy (example: 119.050)
• {current_tracked}: Current number of tracked aircraft by the controller
• {total_tracked}: Total number of aircraft tracked by the controller
• {total_inrange}: Total number of aircraft in range of the controller

My inquiries on this section:

• At the moment only direct connections are processing the variables mentioned above. Would you guys think it is viable to also include the other modes to process these variables? (except idle ofc).
• Ideas of any more variables that can be implemented?

Radio callsigns and regex

The old system had a basic text file parser that has to read every single line and look for a callsign in order to register it to its corresponding radio callsign. This proved to work fine but it would eventually break if a variant callsign was used. This led me to come up with the idea of using regex, where it can allow you guys to freely choose the matching criteria of the callsign and map it to its radio callsign.

Thus, I came up with this design:

"radio_callsign": {
    "callsign regex" : "radio callsign",
    ...
}

I'm now having second thoughts of changing the structure of this object to be an array of objects instead. To look something similar to the following snippet but I wanted to poll it here first if it would be better?

"radio_callsign": [
    {"regex": "regex callsign here", "rcallsign": "radio callsign here"},
    {"const": "constant callsign here", "rcallsign": "radio callsign here"},
    ...
]

Feedback and Contribution

The main purpose of this discussion topic is to share ideas to further improve v1.3.0 branch before release. I'd be more than happy to hear feedback, suggestions and contributions too on this topic or privately on Discord!

[Kirollos]

Update 14/04/2024

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:

"radio_callsigns": {
    "config": {
      "load_from_ese": false,
      "path_to_ese": "..\\..\\"
    },
    "custom": [
      {
        "callsign": "^HECC_CTR$",
        "rcallsign": "Cairo Control Bandbox"
      },
      {
        "callsign": "^HECC_(\\d+)(?:_)CTR$",
        "rcallsign": "Cairo Control ACC $0"
      }
    ]
  }

• load_from_ese
  • type: boolean
  • values:
    • 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\\:

D:\ZZZZ-Install-Package_20230126160923-230101-0001
│   aeronav_copyright.txt
│   Profile.prf
│   ZZZZ-Install-Package_20230126160923-230101-0001.ese
│   ZZZZ-Install-Package_20230126160923-230101-0001.rwy
│   ZZZZ-Install-Package_20230126160923-230101-0001.sct
│
└───ZZZZ
    │
    └───Plugins
            DiscordEuroscope.dll
            DiscordEuroscope_config.json

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:
  1. The controller is selecting their primary frequency to 121.900 MHz.
  2. 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!