Camera position starts at the wrong spot when player has a non ASCII character in their display name

[MrS-ibra]

Prerequisites

• I have searched for similar issues and confirmed this is not a duplicate

Game Version

• Command & Conquer Generals
• Command & Conquer Generals: Zero Hour
• Other (please specify below)

Bug Description

If a non host player has a non ASCII character in their display name, their camera position will be pointed at the wrong spot upon game start.
This happens because when a match starts, the game needs to figure out which slot belongs to the local player so it can point the starting camera at their base. It does this in a fragile way by:

1. Taking the local players display name
2. Converting it to ASCII
3. Searching all slots for a name that matches the converted result (which possibly means this can cause issues if two players have the same name, and if this is done the same way in other places like the actual start position of a CC, but I have not tested)

			AsciiString slotNameAscii;
			slotNameAscii.translate(slot->getName());
			if (slot->isHuman() && game->getSlotNum(slotNameAscii) == game->getLocalSlotNum()) {
				localSlot = i;
			}

localSlot never gets updated, and stays at 0 which would be whoever is on slot 0 (the host) when the game needs to decide where to start:

GameSlot* slot = game->getSlot(localSlot);
Int startPos = slot->getStartPos();
startingCamName.format("Player_%d_Start", startPos + 1);

Reproduction Steps

1. Start the game with the non host client having a non-ascii character in the name
2. Camera start position will be pointed at the host's base

Additional Context

• This is a retail bug.

[Mauller]

Ah so this must explain why this would happen at times but we could not reproduce it.

the AsciiString class does not properly support non Ascii characters, there is a PR to support UTF-8 within AsciiString, but i do not know if this will then allow AsciiString to properly handle non Ascii characters when passing things back into windows functions etc.

This is also what caused non latin user names to crash when i implemented the alternative code for handling user paths.

[bobtista]

GameLogic.cpp converts the slot name wide→narrow with translate() (which just truncates each character), then getSlotNum() converts it back narrow→wide and compares against the real slot names. Anything above the 8-bit range pukes, so no slot matches and localSlot stays 0.

#2528 fixes the translate() stubs to do real UTF-8 conversion, which makes the round trip lossless and would fix this lookup

We could also fix this by just not converting at all - the multiplayerIsLocal check a few lines up already compares the UnicodeStrings directly. Comparing by IP or slot index instead of name would also avoid the duplicate-name problem