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

[19wintersp]

My suggestions for colours are as follows, with three options for how to map them to the various states: (edit: I have added Candidate as the provisional final choice; see later comments below)

Colour	RGB	Map A	Map B	Map C	Candidate
White	#ffffff	User	User	Auto	Auto, Unk
Grey	#cccccc	Auto, Unk	Auto, Unk	Unk
Yellow	#ffd800	Res, VAA	Res	Res, VAA	Res, VAA
Orange	#ff9529		VAA	User	User

I've suggested merging "Auto" and "Unknown" in most of these options since the distinction is unlikely to be interesting to most users, and that we are quite insistent with plugin updates means any newly-added allocators server-side can be accompanied by a plugin update to add corresponding new colours if necessary. The colour distinction between "Auto" and "User" is also fairly subtle in most of the options, since again the distinction is not too important to the controller, who should be able to remember what they themselves have changed, however if we feel it is likely to be used similarly to reservations, I have separated it better in option C. I've merged "Reservation" and "VAA" in two of the options since I again think the distinction is unlikely to be useful to controllers (in both cases, they indicate a higher priority), but if we do consider it important then option B can be used.

The colours themselves have been chosen to try to provide reasonably good contrast on all surfaces on which they appear, whilst at least somewhat matching most of the existing datablock symbology colours. Here's an (approximate) preview, with the bottom row in each pair being with the strip selected:

Comments welcome from all

[MrAdder]

Good colour selection IMO, will test it all once compiled again

[kristiankunc]

My take on the colours:
The fewer the better - we should not rely on controllers remembering more color codes than necessary. My favourite is scheme A where wer merge categories which require similar controller attention but imo the gray is barely distinguishable from the white, something which stands out a little more would be better. If there's a white A/C in the arrival list I would likely tell these apart but if not, I probably couldn't tell you which is which. Removing the gray in the A scheme and using white, yellow, orange sounds sensible to me.

[19wintersp]

I'll defer my final review until the colours are decided, but if you could try to fix the new "code smell" (I'm happy to ignore the shadowing ones; probably a result of some other include) before then that would be great.

edit: I've actually had a quick look at the code; could the addition of the new DEFAULT_UNKNOWN_COLOUR be reverted before I review, please? I think it makes far more sense to have it the previous way, where the colour we will "assign" to the Unknown "type" is actually just the fallback colour, since otherwise the DEFAULT_COLOUR becomes basically unused.

My take on the colours: The fewer the better - we should not rely on controllers remembering more color codes than necessary. My favourite is scheme A where wer merge categories which require similar controller attention but imo the gray is barely distinguishable from the white, something which stands out a little more would be better. If there's a white A/C in the arrival list I would likely tell these apart but if not, I probably couldn't tell you which is which. Removing the gray in the A scheme and using white, yellow, orange sounds sensible to me.

I agree the grey and white are fairly similar; my original justification for that was that the distinction between Auto and User is also fairly subtle. However, I can now see how User may need to be flagged more evidently for cases where pilots verbally report a stand request to eg. AIR before handover to GMC, to which end I'd agree with your suggestion. Comments still universally welcome, of course, but I'll update the table accordingly.

[MrAdder]

Sonar may still have 3 smells .... however will test this once its compiled

[kristiankunc]

Let's see what Patrick think but I probably wouldn't stress over them to much - it's only the three shadowing ones. And if nobody else has got anything with the colors you can bake those in as well now.

[19wintersp]

If the SonarQube analysis doesn't let you use using Source = ... in place of using enum ..., then I'd just ignore the warnings. As above, I think the colours are settled now, so please do ping me for review once those (and the other fixes I mentioned) are sorted

[kristiankunc]

Have all the commenst been resolved?

[MrAdder]

Yes, they have 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.

…

On Wed, 22 Apr 2026 at 19:31, Kristián Kunc ***@***.***> wrote: *kristiankunc* left a comment (VATSIM-UK/uk-controller-plugin#610) <#610?email_source=notifications&email_token=AA4XK7HNGCWQOKTHUO7CE6L4XEFWPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRZHA4TMMZUGY2KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJNLQOJPWG33NNVSW45C7N5YGK3S7MNWGSY3L#issuecomment-4298963464> Have all the commenst been resolved? — Reply to this email directly, view it on GitHub <#610?email_source=notifications&email_token=AA4XK7HNGCWQOKTHUO7CE6L4XEFWPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRZHA4TMMZUGY2KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJNLQOJPWG33NNVSW45C7N5YGK3S7MNWGSY3L#issuecomment-4298963464>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4XK7AAZ5R2AWQCGIAQ7J34XEFWPAVCNFSM6AAAAACWT4JD6OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEOJYHE3DGNBWGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[19wintersp]

Trivial things from a cursory overview; I will check fully once these are changed but hopefully that should be all.

[sonarqubecloud]

Quality Gate failed

Failed conditions
3 New Code Smells (required ≤ 0)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[VATSIMUK]

🎉 This PR is included in version 5.19.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀