feat: track stand assignment source with colour-coded tag items

[MrAdder]

Fixes #604

⚠️ Hard dependency: VATSIM-UK/uk-controller-api#1817 needs to be deployed before this is merged.

Stand assignments now know how they were made. Whether a stand was assigned by a controller, auto-assigned by the system, or allocated by the reservation or VAA allocator, that information is now tracked and shown in EuroScope.

Tag item 110 shows the source as a colour-coded indicator — each source gets its own configurable colour saved to user settings. Tag item 200 gets a short suffix (USER, AUTO, RES , VAA ) so it's visible at a glance in the tag itself.

Also fixed a latent crash in FlightPlanEvent where a stale stand ID could cause a past-the-end dereference — it now logs a warning and returns early instead.

Under the hood:

• Fixed linker errors by adding the new files to CMakeLists.txt (they were just missing)
• Added missing direct #includes that were previously only pulled in transitively
• Cleaned up the tests — extracted helpers and replaced a wall of near-identical test cases with table-driven loops

[MrAdder]

Due to the changes to the test test/plugin/stands/StandEventHandlerTest.cpp to reduce duplication the test/plugin/ecfmp/AircraftFlowMeasureMapTest.cpp needed to be reworked as it pulled from it

[kristiankunc]

Have you managed to test it locally?

[MrAdder]

On my todo list

…

On Tue, 17 Mar 2026 at 13:52, Kristián Kunc ***@***.***> wrote: *kristiankunc* left a comment (VATSIM-UK/uk-controller-plugin#610) <#610 (comment)> Have you managed to test it locally? — Reply to this email directly, view it on GitHub <#610 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4XK7GMNOZFNCBEQ2QIFQT4RFKAFAVCNFSM6AAAAACWT4JD6OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANZVGEYTSNJQGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- This email and any files transmitted with it are confidential and contain privileged or copyright information. It is intended solely for the individual(s) to whom it is addressed. You must not present this message to another party without gaining permission from the sender. If you are not the intended recipient you must not copy, distribute or use this email or the information contained in it for any purpose other than to notify us. If you have received this message in error, please notify the sender immediately, and delete this email from your system. We do not guarantee that this material is free from viruses or any other defects although due care has been taken to minimise the risk.

[MrAdder]

So currently have API response from the logs highlighted response for user requested

Forgot to add the menu items so it wont render working on a build now, for some reason DevContainer give CURL errors so using the CI workflow for build

[MrAdder]

Works also Adds a Tag item which is also shown in screenshots AUTO/USER/VAA(may be of use later when I dig into the API further possibly to tag Event Slots with for my other PR for the Event Planning system)

Not sure on the colour Selection as it brings up one window for USER you select Color then you Select the Color for AUTO, will quite happily take suggestions on that.

Still Tweaking but feel free to review while in Draft/Make Suggestions

[19wintersp]

I'll look at the code when this is out of draft.

Not sure on the colour Selection as it brings up one window for USER you select Color then you Select the Color for AUTO, will quite happily take suggestions on that.

I think the UX here could be improved somewhat; if it is to be made configurable like this, then at least a dialogue should be shown with a form containing the different options. Having popups appear and disappear in sequence with no feedback is not ideal.

Does this even need to be configurable? I think the colours could certainly be made into a loadable plugin setting, but I don't think they warrant having their own UI and a place in the (already quite full) OP menu. Open to discussion on this point, but adding another useless configuration item for users to pointlessly change seems unnecessary to me.

[CLC0609]

Completely agree, I don't think this needs to be configurable.

[MrAdder]

Currently they are stored in the Data/Settings/Local/<AIRPORT>/Plugins.txt

UK Controller Plugin:stand_colour_user:255,128,128
UK Controller Plugin:stand_colour_reservation_allocator:255,0,0
UK Controller Plugin:stand_colour_vaa_allocator:128,255,128
UK Controller Plugin:stand_colour_system_auto:255,0,255

So potentially configurator change in the controller pack? so I can ditch the OP menu option

and I just change the defaults to white?

• user = Controller changed
• reservation_allocator = Requested stand by pilot
• vaa_allocator = Is a potential WIP on the API side
• system_auto = Generic stand allocation from the API

Also thank you for your inputs

[19wintersp]

I see no need to move settings out of the Plugin and into the Configurator; I would leave the settings serialisation as-is, remove the configuration UI from this patch, and leave it to be set in the Pack. As above, I see no value in letting users change these colours; there is precedent enough for hard-coding things as these, though leaving it as a plugin setting seems a fair middle ground.

[MrAdder]

Defaults are hard coded anyway (Shown below) I think the grey one for system needs to not be grey especially on some dark SMRs e.g. Heathrow, so going forward will remove the UI and leave in the Plugin setting options from above, and not worry about the configurator in the controller pack.

        static constexpr COLORREF DEFAULT_RESERVATION_COLOUR = RGB(255, 255, 0); // yellow
        static constexpr COLORREF DEFAULT_VAA_COLOUR = RGB(0, 255, 255);         // cyan
        static constexpr COLORREF DEFAULT_SYSTEM_COLOUR = RGB(180, 180, 180);    // grey

[kristiankunc]

Agree with the points above - having a custom UI is overkill. Let's stick to 2/3 distict colors for now and KISS

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.6% Duplication on New Code

See analysis details on SonarQube Cloud