Bug 3313 - recursive color escape codes
Status: RESOLVED FIXED
Alias: None
Product: ioquake3
Classification: Unclassified
Component: Misc
Version: GIT MASTER
Hardware: All All
: P2 minor
Assignee: Zachary J. Slater
QA Contact: ioquake3 bugzilla mailing list
URL:
Depends on:
Blocks:
 
Reported: 2007-08-15 00:46 EDT by /dev/humancontroller
Modified: 2009-10-03 17:16:13 EDT
1 user (show)

See Also:


Attachments
ClientCleanName() rewrite (1.45 KB, patch)
2008-03-30 14:43 EDT, /dev/humancontroller
ClientCleanName() rerewrite (1.45 KB, patch)
2008-03-30 15:24 EDT, /dev/humancontroller

Description /dev/humancontroller 2007-08-15 00:46:19 EDT
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.
Comment 1 Ludwig Nussel 2007-08-16 06:32:32 EDT
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.
Comment 2 /dev/humancontroller 2007-08-16 14:32:06 EDT
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?
Comment 3 /dev/humancontroller 2007-08-16 14:36:44 EDT
Oops, I mean, votes only - where proper decolorization should have been applied.
Comment 4 Tim Angus 2007-08-22 18:22:25 EDT
Can you point to the specific bit of code that is applying a second colour strip? SanitizeString/g_cmds.c?
Comment 5 /dev/humancontroller 2008-03-30 14:43:00 EDT
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.
Comment 6 /dev/humancontroller 2008-03-30 15:24:41 EDT
Created attachment 1716 [details]
ClientCleanName() rerewrite

whoops
Comment 7 Thilo Schulz 2009-10-03 17:16:13 EDT
Fixed in svn rev 1638. Note this change is gamecode specific.