Allow STEAM_0 in ProcessArgString#2512
Conversation
| /* Do we need to look for a steam id? */ | ||
| int steamIdType = 0; | ||
| if (strncmp(&info->pattern[1], "STEAM_", 6) == 0) | ||
| if (strncmp(&info->pattern[1], "STEAM_1", 6) == 0 || strncmp(&info->pattern[1], "STEAM_0", 6) == 0) |
| strcpy(new_pattern, "STEAM_"); | ||
| len = strlen(&info->pattern[7]); | ||
| /* Bound the copy so the "STEAM_" prefix, the copied bytes and the | ||
| strcpy(new_pattern, "STEAM_1"); |
There was a problem hiding this comment.
I think a comment about why the universe in the steamid is hardcoded to 1 here would be good as it's not obvious while reading the code.
There was a problem hiding this comment.
I don't think hardcoding STEAM_1 is right here. pTarget->GetSteamId() below is going to return with STEAM_0 on games that have the UseInvalidUniverseInSteam2IDs gamedata key enabled.
There was a problem hiding this comment.
okay time to rethink this then
There was a problem hiding this comment.
Alright so here's the new method. No more hardcoding to STEAM_1, instead the universe id gets changed based on whatever the game returns so that strcmp can succeed.
And to remain future-proof, this only happens if a STEAM_0 or STEAM_1 was provided. Say we ever support a STEAM_9 or whatever, there won't be any changes.
peace-maker
left a comment
peace-maker
left a comment
There was a problem hiding this comment.
As suggested here #1240 (comment) reusing the logic to only compare the account id and ignore the universe from the admincache might simplify the logic here, but this is fine too.
|
If this bugs out and needs refactoring again, I'll definitively make a bigger diff and share some funcs. Otherwise I just wanted to make something small for now |
3 participants
Fix #1240