Skip to content

Allow duplicate colors when map has LUA script#1888

Open
Flamefire wants to merge 4 commits intoReturn-To-The-Roots:masterfrom
Flamefire:duplicate-colors
Open

Allow duplicate colors when map has LUA script#1888
Flamefire wants to merge 4 commits intoReturn-To-The-Roots:masterfrom
Flamefire:duplicate-colors

Conversation

@Flamefire
Copy link
Member

@Flamefire Flamefire commented Feb 7, 2026

For e.g. campaigns the creator might intend duplicate colors so allow that.
This also resolves the issue where color set by LUA is changed as it is
still taken even though the conflicting players color might get changed
right afterwards so colors would be unique when the script is done.
That makes setting the colors dependent on the order which is hard.

This also makes the behavior consistent with the documentation.

Fixes #1884

This can be used to  `static_assert` the size of the `PLAYER_COLORS` array.
For e.g. campaigns the creator might intend duplicate colors so allow that.
This also resolves the issue where color set by LUA is changed as it is
still taken even though the conflicting players color might get changed
right afterwards so colors would be unique when the script is done.
That makes setting the colors dependent on the order which is hard.

Fixes Return-To-The-Roots#1884
@Spikeone
Copy link
Member

Spikeone commented Feb 9, 2026

@Flamefire I just had a look at the docu (probably for that one the first time):

SetColor(color or colorIdx)
Sets the players color by index or directly if its alpha value is not zero. Duplicate color values are possible, so you have to ensure unique colors if you want them!

So we can add any color? And can we maybe document the colorIdxs (guess there is an array somewhere). Also what does happen if we use an invalid index (guess just nothing)

RTTR_Assert(playerIdx < playerInfos.size());
RTTR_Assert(playerInfos.size() <= PLAYER_COLORS.size()); // Else we may not find a valid color!
// If either of those fails we may not find a valid color!
static_assert(PLAYER_COLORS.size() >= MAX_PLAYERS, "Not enough player colors defined!");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I fail to wrap my head around this - shouldn't player clolors always be more than MAX_PLAYERS?

Expected this rather to be PLAYER_COLORS.size() < MAX_PLAYERS

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's exactly what the assertion says: Assert at least as many colors as max players

RTTR_Assert(playerInfos.size() <= PLAYER_COLORS.size()); // Else we may not find a valid color!
// If either of those fails we may not find a valid color!
static_assert(PLAYER_COLORS.size() >= MAX_PLAYERS, "Not enough player colors defined!");
RTTR_Assert(playerInfos.size() <= PLAYER_COLORS.size());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also this one, shouldn't the same size work fine?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"assert" (roughly) means "make sure this is true" and <= includes "equal"

@Flamefire
Copy link
Member Author

So we can add any color? And can we maybe document the colorIdxs (guess there is an array somewhere). Also what does happen if we use an invalid index (guess just nothing)

Yes any color. I enhanced the documentation to refer to the array and stated that custom colors are ARGB.
An invalid index will cause the function to fail/abort. I didn't document this as it is clear this is an error and we don't document such things in similar places, e.g. for GetPlayer(idx)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Player Colors set by LUA not working correctly

2 participants

Comments