MessageDelayMS uses an inverted unit conversion and has no practical effect

[bobtista]

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

InGameUI::update computes the in-game message timeout by dividing by both LOGICFRAMES_PER_SECOND and 1000, instead of converting milliseconds to logic frames:

const int messageTimeout = m_messageDelayMS / LOGICFRAMES_PER_SECOND / 1000;   // InGameUI.cpp:1885

For positive values this reduces to floor(MessageDelayMS / 30000) — wrong by a factor of about 900. It is not literally dead for every input, since values at or above 30000 do produce a non-zero timeout, but it has no practical effect: you would need roughly 900000 (15 minutes) to delay the fade by even one second. The same function already does the conversion correctly for military subtitles at InGameUI.cpp:4434.

The shipped value is MessageDelayMS = 75000 (in INIZH.big), so the timeout evaluates to 2 logic frames and message lifetime is governed entirely by the alpha drain that follows.

The game data has a matching error — MessageDelayMS = 75000 where 7500 was presumably intended — so that needs fixing in https://github.com/TheSuperHackers/GeneralsGamePatch2 when this lands, or the fade will be 75 seconds.

Reproduction Steps

1. Set MessageDelayMS to any value below 30000 in InGameUI.ini.
2. Trigger a UI message in game (saving produces "Game Saved" in the top-left).
3. The timing is unchanged regardless of the value — the timeout is 0 for anything under 30 seconds, and 2 frames for the shipped 75000.

Additional Context

Present in both games; Generals has the same line at Generals/.../InGameUI.cpp:1851, and its data value needs checking separately.

Related to but distinct from the render-rate fade of the same messages: that one governs how fast the alpha drains, this one governs when draining is allowed to start.