Commshare colour update breaks colours of the teams in spectator panel UI

[GoogleFrog]

There is no red team yet red is used to name South. Ideally the single South team would be red for consistency but idk how to make this work in partial commshare.

[ArchShaman]

An idea struck: With @Sprunk 's new PlayerRulesParam we can inflict the original teamID of the player as Commshare_OriginalTeam. On PlayerChange, we can then update the colors if that team has isCommsharing. The problem with this is it might not be the lowest cost solution.

Player initiates commshare -> if they're the last player on the team, isCommsharing is inflicted -> team colors updates. Assign red to the lowest enemy teamID without isCommsharing. Vola?

[sprunk]

Localcolors widget obeys some TRP as an ID override. When the last player from team X merges onto team Y and X < Y, Y's current value (if any) of this TRP is pushed onto a stack (so that unmerge does not screw things up) and then set to X.

[ArchShaman]

I noticed something interesting in some tests: Sometimes the colors are not the same for all people. For instance, in a game with ResignLobsters, resign and _Shaman, I found that ResignLobsters saw _Shaman as blue, _Shaman saw ResignLobsters as green, and resign saw _Shaman as green and ResignLobsters as blue.

Could this be related information? I'm struggling to understand what causes this bug. Sorry.

[sprunk]

https://github.com/ZeroK-RTS/Zero-K/blob/master/LuaRules/Gadgets/game_share_mode.lua#L206

Is this ordering of any importance? If merging was always unto the lower ID it would fix this ticket.

[ArchShaman]

Not too important. It's for squad-squad mergers. I thought having the logic of "whichever is bigger, merge them." But lower ID simplifies it a bit.

PS: Excuse my ignorance but what's a TRP? I tried googling it and saw nothing useful.

[sprunk]

team rules param

[ArchShaman]

Oh! That makes a lot of sense. Thanks.

[sprunk]

According to #1861 "merge onto lower id" won't work because it would break the leader invariant.

I've extended the isCommsharing TRP to contain more info so it should be easy to just do an override directly in the local colours widget.

[ArchShaman]

Probably what should happen is that squad merge should work exactly like player merge. That's a simple change though I think.

[sprunk]

Squad merge now works like player merge https://github.com/ZeroK-RTS/Zero-K/commit/d802d31b32279b223caac372bf0a19962a96337b

[sprunk]

After some thought this is just a specific case of a more general problem, where the team is represented by (say) Red who initially was a player but then stops being one with varying hardness of his condition.

• What if Red resigns? This is the only case where there will definitely be no red units, all the ones below are revertible.
• What if Red is AFK?
• What if Red had all his stuff killed?
• What if Red had all his stuff killed except 1 solar in the corner?

Comshare (especially entire allyteam) is different to those though in that it typically happens right from the start and persists so probably should still be handled even if the others aren't. The others are something to ponder about.

[CrazyEddieTK]

In my new spec panel (WIP) I intend for the team colors to be hardcoded to nice shades of red and blue, regardless of the individual colors of the individual players remaining either of the teams, with the expectation that in a two-team game one team will always have redish/warm colors and the other will always have blueish/cool colors.

I use individual player colors for 1v1 only.

Consider using that approach in the current spec panel as well.

[sprunk]

The current approach is pretty much that except the specific shade obeys your teamcolor settings.