It is possible to input such strings, that when stripped from color code escape squences in one pass, would result in a color coded string (expected to have no color codes).
For example ^^14noob is the player's name. The ^1 squence will activate a red color istead of writing ^1. (So the name will look like a default (white) "^" followed by a red "4noob".) When we need to display the name without colors (or one specific color), we ignore ^N sequences. This results in a printing of ^4noob, in which ^4 is recongnized as a blue color escape code! (Resulting in a blue "noob" output.)
I recommend a function that processes the string until there is nothing to strip. At the end of execution, the function guarantees no remaining color codes.
void Q_StripColorEscapes( char *str ) {
qboolean wasColored;
char *src, *dst;
do {
wasColored = qfalse;
dst = src = str;
while( *src ) {
if( *src == Q_COLOR_ESCAPE && *( src + 1 )
&& *( src + 1 ) != Q_COLOR_ESCAPE ) {
wasColored = qtrue;
src += 2;
while( *src ) {
if( *src == Q_COLOR_ESCAPE && *( src + 1 )
&& *( src + 1 ) != Q_COLOR_ESCAPE ) {
src += 2;
continue;
}
*dst++ = *src++;
}
*dst = '\0';
break;
}
dst++;
src++;
}
} while( wasColored );
}
TODO:
- Implement this. This function should be used for all user-inputted strings that need color escape code stripping (not just names).
- To optimize, for every player name there should be a pre-stored stripped string.
where are names interpreted twice? An already stripped name shouldn't be parsed for color codes again, that's the real bug and if there are such places they need to be fixed.
I see it everywhere - console, votes, scoreboards. OK, I see it in Tremulous, and it should work for Q3 too, as I see it in every other Q3 based game, even commercial ones.
Although I agree that we rather need to fix the color reinterpretation bug. You wasted my code! :)
Close this and this and submit a new appropriate one?
Created attachment 1715[details]
ClientCleanName() rewrite
Ok let's get back to this bug. The actual bug differs from what I've written.
ClientCleanName() disallows black color, and leading or >3 consecutive spaces. (Although I disagree. What's wrong with black?) The problem is in the way ClientCleanName() handles color codes. For example, an often used convention: a name like "x^^0w" will have black after cleaning. Also, there's a buffer overflow possibility when handling a long name ending with spaces! Thus, a function rewrite: ^0 are turned into ^7, buffer safe, etc.
Created attachment 1715 [details] ClientCleanName() rewrite Ok let's get back to this bug. The actual bug differs from what I've written. ClientCleanName() disallows black color, and leading or >3 consecutive spaces. (Although I disagree. What's wrong with black?) The problem is in the way ClientCleanName() handles color codes. For example, an often used convention: a name like "x^^0w" will have black after cleaning. Also, there's a buffer overflow possibility when handling a long name ending with spaces! Thus, a function rewrite: ^0 are turned into ^7, buffer safe, etc.
Created attachment 1716 [details] ClientCleanName() rerewrite whoops