Adam "amckern" Mckern wrote:
It sounds good, however, wont this be an open invite
to people shareing the same name, all but case's such
as Player and player? - think it over, and consider
what mygot might do if you do have the this hole
open...
Adam
I suppose it would, but it'd be no more dangerous then somebody changing
their name to an incomprehensible amalgamation of symbols, or doing
something crafty like naming themselves "P1ayer" (the l looks almost
exactly like a 1 in hl font sometimes, because they can always be kicked
by their steam id or # in the server. Additionally, the game dll could
always simply disallow the name change if somebody else already has a
non-case-equivalent name. However...
[EMAIL PROTECTED] wrote:
Worthy of note is that stringpool.cpp contains test_stringpool, which is a test for
that very case-insensitivity. CStringPool seems to be basically be a reinvention of
the std::set<std::string> wheel, but case-insensitive.
If somebody at Valve wrote a test case for it, it'll be best to leave it
alone.
Wow good catch! I saw the chat truncation thing once before, but chalked it up
to a networking glitch or something so I didn't report it. I should have
investigated further. Do you know how this bug trickles down to causing the
chat truncation?
It comes down to this line in sdk_hud_chat.cpp (and elsewhere)
const char *pName = sPlayerInfo.name;
if ( pName )
{
const char *nameInString = strstr( pmsg, pName );
if ( nameInString )
{
iNameLength = strlen( pName ) + (nameInString - pmsg);
}
}
pmsg is the message which was sent form the server. Since it comes from
the server, it has the original player name with capitalization wrong.
pName has the correct capitalization. Since strstr is a case-sensitive
search, it does not match, and this ends up causing the truncation
further down the line. If there was an stristr then you could replace it
with that and I think it would probably fix the tructation. However that
doesn't resolve the root of the problem, which is that the player name
is stored incorrectly in the server. I'd rather solve the player name
being stored correctly. If we resolve that, this strstr stuff will fix
itself.
I'm regrettably coming to the conclusion that string_t can't be used to
store the player name. I'm not sure how to make that plausable in
practice, because netname is stored in CPlayerState, which is in public
code and in use by the engine. I really don't want to pull any hacks,
for example ignoring and reimplementing netname, and I'm positive that
it's a very bad idea to change CPlayerState, as it's referred to by the
engine.
--
Jorge "Vino" Rodriguez
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
