bugfix(namekeys): Remove hardcoded NameKeyIDs from dummy strings for modded files

[Caball009]

• Related issue NameKeyGenerator and order of initialization of singleton classes are tightly coupled to CRC #2347
• Follow up for fix(filesystem): Decouple File System from NameKeyGenerator and its CRC influence #1516

Perhaps it's best to keep the issue open because it touches on a larger issue that this PR does not fix.

#1516 adds three strings with hardcoded name key IDs. This PR fixes the following issue:

Unfortunately, hardcoding the IDs doesn't work for modded files. This became apparent after this replay started to mismatch after #1516 at 4:00: TEOD_0986_P11.zip mod files This mod expects the three strings to have IDs 265 - 267.

I've added a second commit with debug assertions for the correct name key ID with unmodded files to help us detect undesirable additions or removals of name keys.

TODO:

• Check hash and name key ID values for Generals.
• Replicate in Generals.

[greptile-apps]

Greptile Summary

Fixes name key synchronization issue between vanilla and modded game files by replacing hardcoded file paths with generic dummy strings.

Key Changes:

• Removed addReservedKey() function that hardcoded file paths at specific IDs (97-99)
• Added syncNameKeyID() to create 3 generic dummy strings after TheAudio initialization
• Added verifyNameKeyID() with debug assertions to detect unexpected name key ID deviations in unmodded files
• Simplified nameToKey functions by removing conditional key reservation logic

Impact:

• Modded files (like TEOD) can now have different name key sequences without causing replay mismatches
• Maintains CRC compatibility by ensuring consistent relative ordering across all clients
• Debug assertions help catch future initialization sequence changes that could break compatibility

Confidence Score: 5/5

• This PR is safe to merge with no identified risks
• The fix is well-designed and directly addresses the root cause: hardcoded IDs don't work for modded files. The new approach creates dummy strings at a consistent initialization point, ensuring all clients maintain the same relative name key ordering. Debug assertions provide safety against future regressions. Code quality is excellent with clear comments explaining the change
• No files require special attention

Important Files Changed

Filename	Overview
GeneralsMD/Code/GameEngine/Include/Common/NameKeyGenerator.h	Added public methods syncNameKeyID() and verifyNameKeyID() to replace the private addReservedKey() function, improving the API design
GeneralsMD/Code/GameEngine/Source/Common/GameEngine.cpp	Added verification calls at strategic initialization points and synchronized name key IDs after TheAudio initialization
GeneralsMD/Code/GameEngine/Source/Common/NameKeyGenerator.cpp	Replaced hardcoded file path logic with generic dummy strings, simplified name-to-key functions by removing conditional key reservation

_{Last reviewed commit: b8b15db}

[xezon]

Use new line.

Multiple times.

[xezon]

I suggest to preserve the original strings for context

[Caball009]

Yeah, I can use the strings that were added in #1516.

Those strings depend either on registry language and / or use sound track names that can be changed by mods, though.

[xezon]

It is mainly about preserving the context for what these strings are for the next person to look at it.

[Caball009]

That's fair.

[xezon]

This means you can merge nameToLowercaseKeyImpl into nameToLowercaseKey entirely as it was originally.

Four times.

[xezon]

Instead of adding the syncNameKeyID function, how about just calling nameToKey 3 times here?

[Caball009]

I wanted a better place for a TSH comment that's not in the middle of an enormous function that's not really related.