scripts/4_World/Classes/BunkerBroadcastHandler.c, GenerateLockCode (around line 422):

1. lockCodeArray is created once, before the while (needGenerate) loop. When a generated code is rejected, the loop runs again and appends another lockCodeLength characters to the same array, so a 4-character code becomes 8. SetLockCode rejects that through ValidatePIN (maximum 6), but Bunker.c (around lines 136-137) still calls SetLockState(true). The bunker is then locked with no valid PIN while the broadcast announces an 8-digit code that can't be entered.

2. m_LockCodeHistory (line 154) is created holding "0000", and nothing ever adds a generated code to it. So the no-repeat check never prevents recent codes from coming back, and the only retry trigger is a code of exactly "0000".

1. Code review, or use a diagnostic build to force GetRandomChar to return '0' for the first generation.

2. The second generation appends to the first and returns an 8-character code.

3. The bunker locks and the announced code is rejected.

Expected result: The code is always lockCodeLength characters long and doesn't repeat any of the last LOCK_CODE_HISTORY_LENGTH codes.

Actual result: On a retry the code is twice as long and unusable, and recent codes can repeat.

Suggested fix:

while (needGenerate)
{
    lockCodeArray.Clear();                       // reset each attempt
    for (int i = 0; i < m_Config.bunkerSettings.lockCodeLength; ++i)
        lockCodeArray.Insert(GetRandomChar().AsciiToString());

    lockCode = string.Join("", lockCodeArray);
    if (m_LockCodeHistory.GetValues().Find(lockCode) > INDEX_NOT_FOUND)
        continue;

    needGenerate = false;
}
m_LockCodeHistory.Add(lockCode);                 // actually record it

Also cap the number of retries, and clamp lockCodeLength to the PIN maximum of 6 when the config is loaded.