Coloured vs uncoloured names

[Luke-Jr]

A recent commit ("uncolored name in HUD fatest speed") prompted me to post this thread dealing with name colouring...
Why *shouldn't* the HUD use coloured names? Further, why shouldn't *all* player-visible displays use coloured names?

[Z-Man]

It *was* unsafe in the past to use the colored names directly, players could abuse trailing unfinished color codes to eat characters after their name. Since a while, this is no longer an issue, because the server filters all strings sent by the client for these constructs (whoops, writing this I uncovered a loophole caused by the player name truncation, fixing...).

Now that you mention it, there are now in total five different ways to get the player name:
ePlayerNetID::GetNameFromClient() returns the name just as the client sent it, with all dangerous stuff not filtered already by the networking system. Clientside renames have an immediate effect.
ePlayerNetID::GetColoredName() returns a clean version of the player name with color codes that only is updated between rounds (to avoid stat whoring and name change spam). The trailing color code will always be white. (not yet in CVS)
ePlayerNetID::GetName() returns the same, with all color codes removed.
ePlayerNetID::GetUserName() for now returns the color-code cleared name with whitespace replaced by underscores. The Highscore tables have been adapted to use this. Later, this will perhaps change semantics to become a real user name, the one that's used for authentication. Kick commands accept this name variant, so people called "1 2 3" are less of a pain.
Lastly, there is the streaming operator:

Code: Select all

tColoredString output;
output << player;

will, if player is a ePlayerNetID reference, fill the output with the player's name, colored with his bike's color.

As Luke points out, there is no technical reason not to use the streaming operator or GetColoredName() when screen output is prepared. It's a purely aesthetic decision whether GetName() should be used instead.

[Luke-Jr]

The trailing color code will always be white. (not yet in CVS)

Why? The only purpose of this would be if you could assume the enclosing string was white, which may or may not be the case. I would suggest adding a colour-set after all names in the string composition itself in those few cases where it makes a difference (none AFAIK).

will, if player is a ePlayerNetID reference, fill the output with the player's name, colored with his bike's color.

Why not prefix his bike's colour to the GetColoredName function and return that?

As Luke points out, there is no technical reason not to use the streaming operator or GetColoredName() when screen output is prepared. It's a purely aesthetic decision whether GetName() should be used instead.

Perhaps a player-set option to use colours? IIRC, there already is one (unused?)...

[dlh]

The HUD has always used uncolored names, but players with color-codes in their names were an exception, and now they are not.

I would not want colored names showing up above the cycle, or in the HUD. In player chat is fine with me.

Before in the master server browser names with color code in them color-infected the whole user list, this is fixed, however I also think color code should be removed from this list as well.

Players with color code in their name also color-infected vote messages (Player 1 voted against poll kick Player 1), the camera controls menu (well, I guess you color infected yourself), the greeting message (same here), when you change places on ladder/rounds/matches, and maybe some more.

For the most part, I just want things to be consistent. If the display of a name doesn't use the player's trail color, then the color-code from the name should be removed also.

[Luke-Jr]

The HUD has always used uncolored names,

A bug.

I would not want colored names showing up above the cycle, or in the HUD.

Your loss, but don't force it on everyone else...

Before in the master server browser names with color code in them color-infected the whole user list, this is fixed, however I also think color code should be removed from this list as well.

If anything, it should be fixed so the cycle colours apply to those w/o codes.

Players with color code in their name also color-infected vote messages (Player 1 voted against poll kick Player 1), the camera controls menu (well, I guess you color infected yourself), the greeting message (same here), when you change places on ladder/rounds/matches, and maybe some more.

Nothing wrong with that.

For the most part, I just want things to be consistent. If the display of a name doesn't use the player's trail color, then the color-code from the name should be removed also.

If the display of a name doesn't use the player's trail colour, then it should.

[Lucifer]

I would not want colored names showing up above the cycle, or in the HUD.

Your loss, but don't force it on everyone else...

Sounds like a prime candidate for a config option. I'm with nemo on this. When I see names in the HUD or over the cycle, I want clarity and I don't give a damn about the player's personal "style". The HUD and the names of players over the cycles is a tactical display, not a personality display, and needs to serve the purpose. Color-coded names can (but will not always) defeat that purpose.

Before in the master server browser names with color code in them color-infected the whole user list, this is fixed, however I also think color code should be removed from this list as well.

If anything, it should be fixed so the cycle colours apply to those w/o codes.

It would be nice, but the fundamental problem is the color code infecting the rest of the line in the list. If a server or player wants to have special color codes, that's fine, but it shouldn't bleed into other players or servers. There are a few that do, and that pretty much sucks. Giving one player the "right" to have color codes right now removes the "right" of players listed after that one to not have color codes.

Players with color code in their name also color-infected vote messages (Player 1 voted against poll kick Player 1), the camera controls menu (well, I guess you color infected yourself), the greeting message (same here), when you change places on ladder/rounds/matches, and maybe some more.

Nothing wrong with that.

Quite the contrary, colors bleeding from player names is a big problem. Server messages aren't necessarily consistent, and nobody in a serious tactical position has time to decipher bleeding color codes. The menus are UI and a player using color codes shouldn't be able to override the UI like that. I'm all for providing ways for players to customize the UI, but this isn't the right way to do that.

For the most part, I just want things to be consistent. If the display of a name doesn't use the player's trail color, then the color-code from the name should be removed also.

If the display of a name doesn't use the player's trail colour, then it should.

Better make it configurable, there are plenty of places (as previously mentioned) where the ability to read the name by the player doing the reading should override the other player's preference for color codes.

[Tank Program]

I'm in agreement with limiting the presence of color-coded names. To me color codes in the HUD, on top of cycles, just don't fit the style of the game. There is probably a reason the guy who wrote the code for player names over the cycles made them white, so white they should stay. I think there is such a thing as too much color. And color in the console where player names should be green or red, because that's how it was written, turning out to be neon pink, is quite a bit distracting to the game. Having the score tables become unaligned is also very distracting, but there it's fine to have the colors, so they're there. Chatline is fine, so they're there, because they don't interrupt the feel of the game in those places. In the server browser where you get one and all of a sudden, BAM, color hits you, where everything else is white sort of looks like a bug... Which it is... So fine, Luke, if you want the colors to display there, it can be a config option, but just as you do not wish to force whiteness upon everyone, conversely, you should not force color upon everyone, and white should be default. I'd also just like to point out that I've never heard people ever mention wanting their colors to show in their name above their cycle, in the master server list, or any place else where names are normally white...

[Luke-Jr]

Luke, if you want the colors to display there, it can be a config option, but just as you do not wish to force whiteness upon everyone, conversely, you should not force color upon everyone, and white should be default.

Never said I wanted to force everyone to have colours... If I didn't state it, I was hinting at an option

I'd also just like to point out that I've never heard people ever mention wanting their colors to show in their name above their cycle, in the master server list, or any place else where names are normally white...

Well, I'm not sure coloured names over cycles is a good idea, but it was specifically for the master server list and HUD that I added a colourcode in my nick-- which, now that I think about it, was a workaround for the bug of inconsistent colours when I should have just fixed that.

[Self_Destructo]

It isn't a good idea.... but I have a question.....

When I put a nice fancie colored name that starts out with my bike color then fades into my tail color the whole name is not passed through to the server (I"m guessing).... Therefore I get The first 2 letters of my name in the start color and a color code as the rest of my name. Am I correct to guess that this is because the whole name is not passed to the server????

[dlh]

Bug in GetName()? The master server list should be removing color codes from names, same with vote messages.

Code: Select all

virtual tString GetUsers()		const
    {
        tString ret;

        for ( int i = se_PlayerNetIDs.Len()-1; i>=0; --i )
    {
        ePlayerNetID* p = se_PlayerNetIDs(i);
            if ( p->IsHuman() )
            {
                ret << p->GetName() << "\n";
            }
        }

        return ret;
    }

[LETE]

It isn't a good idea.... but I have a question.....

When I put a nice fancie colored name that starts out with my bike color then fades into my tail color the whole name is not passed through to the server (I"m guessing).... Therefore I get The first 2 letters of my name in the start color and a color code as the rest of my name. Am I correct to guess that this is because the whole name is not passed to the server????

Your name can only be 15 characters long, or rather, only fifteen of the characters you put into the config file will be displayed. So, Self_Destructo + (an 8 character HTML color code) = 22 characters, so I would expect, you would get cut short.

[Z-Man]

Luke: The reason to put the white color code at the end of GetColoredString was that then you see immediately whether your particular output routine is using the right color codes after the name independently of whether you use color codes in your name yourself: it will be white (which is the right color most of the time) instead of whatever you want. But you're right, prepending it with the player's color code does the same job and leads to better consistency. We don't need four variants of ways to display a name. So, now GetColoredName() always returns a name colored according to the cycle's colors or the player's color codes.

About the length cutoff: We're now in a position to be able to change the rules. We can place a cutoff at 15 REAL characters (color codes not counted) and, say, 32 TOTAL characters (color codes counted). But keep in mind that custom color codes are an undocumented and unsupported feature as the color coding is subject to change at any time.

I'm in favor of adding a general way for clients to filter out other clients' color codes sometime, see here:
https://sourceforge.net/tracker/index.p ... tid=657951
Of course, the 0x scheme will have to be reworked for that.

About making the colored/uncolored choice a configuration item: there can be such a thing as too much user configurability. At a certain point, things become too complicated for the average user to understand (heck, it's sometimes too complex for myself), so they don't dare to touch anything. Sometimes, it's required to just make a choice as the developer to do something THIS way. I think this is the case here. Since the original implementors explicitly made the names white in the HUD by removing the color codes and the majority agrees it's a good thing, I think we should just keep it. Of course, if anyone wants to actually do the work of making this configurable, sure, go ahead.

On a semi-related side note (the complexity thing made me think of it), how about splitting settings(_dedicated).cfg in several sections (still one file), one with easy to understand options (speed, arena choice...), one with delicate options (CYCLE_TIME_TOLERANCE...) and one "don't touch the red button" section with all the things that are basically just configurable so we developers can fine-tune them without messing with the code (like the new camera line-of-sight checking settings)?

Nemo: Why should this be a bug? GetName() returns a name without color codes, which is what we want here (I guess, discussion pending).

[dlh]

Nemo: Why should this be a bug? GetName() returns a name without color codes, which is what we want here (I guess, discussion pending).

It is not removing the color codes, that is why I mentioned it. The master browser should be removing color codes from the users list (unless I am totally off-track).

[Z-Man]

Ah, yes. The code you posted gets executed on the server side, so the recent change does not affect it. If we want to disable colored names in the master server completely and today, we have to filter color codes in nServerInfo.cpp (where you added the color code bleeding prevention).

[Luke-Jr]

Ah, yes. The code you posted gets executed on the server side, so the recent change does not affect it. If we want to disable colored names in the master server completely and today, we have to filter color codes in nServerInfo.cpp (where you added the color code bleeding prevention).

Not to mention the filtering must be done client-side in order to allow an option..