Avoid dark and duplicate nametag colors #708
Conversation
This keeps the original behavior but improves it slightly by avoiding very dark colors and reducing the chance of duplicate nametag colors between players
|
Why avoid dark nametag colors? |
Lpsd
left a comment
Lpsd
left a comment
There was a problem hiding this comment.
Not too sure about the approach here - also is there a specific issue you're trying to address by restricting darker colors?
| r = math.random(lowerBound, upperBound) | ||
| g = math.random(lowerBound, upperBound) | ||
| b = math.random(lowerBound, upperBound) | ||
| until (r + g + b) > 200 |
There was a problem hiding this comment.
For the most unlucky player in the history of MTA, this could return a value under 200 even if they waited for an infinite amount of time
The lower bound would need increasing to ensure the three values always have a sum larger than 200, or you would need to lower the check itself (i.e (r + g + b) > 149 given current lower bounds).
| r, g, b = generateColor() | ||
| key = colorToKey(r, g, b) | ||
| if not usedColors[key] then | ||
| break |
There was a problem hiding this comment.
This doesn't seem like the right approach.
Technically there are 206³ (8,741,816) possible keys (RGB color combinations) given 206 possible configurations (50-255 range) per value. However we're only attempting to generate a color 10 times before giving up if they've already been used.
Whilst technically not an issue given the huge amount of possible combinations/keys, it's still a logically flawed approach given the previously mentioned factor of luck; and the simple fact this isn't optimal/efficient.
A better approach would be to generate a limited size pool of random colors on resource start (equal to the max player count) and then select a random one to assign to a player. Once assigned, pop from the active pool, place into an "inactive" list/array (indexed by player) and return back to the pool once the player disconnects (so the color can be used again).
This ensures players are all assigned unique colors, without needing to iterate at all to find an unused value (since we generate one at random first try). You may also wish to implement additional logic to ensure the active pool colors aren't too similar when initially pre-allocating the pool.
3 participants
This keeps the original behavior but improves it slightly by avoiding very dark colors and reducing the chance of duplicate nametag colors between players