Skip to content

bugfix(gui): Convert MessageDelayMS to logic frames so the setting takes effect - #3133

Draft
bobtista wants to merge 2 commits into
TheSuperHackers:mainfrom
bobtista:bobtista/bugfix/message-delay-units
Draft

bugfix(gui): Convert MessageDelayMS to logic frames so the setting takes effect#3133
bobtista wants to merge 2 commits into
TheSuperHackers:mainfrom
bobtista:bobtista/bugfix/message-delay-units

Conversation

@bobtista

@bobtista bobtista commented Aug 13, 2026

Copy link
Copy Markdown

Fixes #3131.

InGameUI::update computed the message timeout as m_messageDelayMS / LOGICFRAMES_PER_SECOND / 1000, dividing by both instead of converting milliseconds to logic frames. For positive values that reduces to floor(MessageDelayMS / 30000), which is wrong by a factor of about 900 and has no practical effect at any realistic setting. The same function already does the conversion correctly for military subtitles at InGameUI.cpp:4434.

Now converts through ConvertDurationFromMsecsToFrames, rounding partial frames up as that helper documents, so the timeout is the configured delay expressed in logic frames.

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.

Predicted total message lifetime at 30 render / 30 logic FPS, including the existing alpha drain:

MessageDelayMS total lifetime
3000 9.2 s (matches today's behaviour)
5000 10.0 s
7500 11.2 s
75000 75.4 s

Measured on MD_CHI01 with the shipped MessageDelayMS = 75000, posting a message at logic frame 300 and logging the computed timeout and the message's age when it is removed:

messageTimeout message lifetime
before 2 frames 277 frames (9.2 s)
after 2251 frames 2263 frames (75.4 s)

Verified in game by instrumenting the message alpha and setting the delay to 3400 ms, which converts to 103 logic frames. The message stayed at full alpha through age 100 and only began draining after the timeout:

message age (logic frames) alpha
85 / 90 / 95 / 100 255
105 254
110 249

Age 100 is the telling one: the existing fade amount becomes non-zero there, so on current main (where the timeout evaluates to 2 frames) the message is already draining by then. Holding to 103 shows the configured delay is what gates the fade.

Todo:

  • Land the matching MessageDelayMS change in GeneralsGamePatch2
  • Test that a UI message holds for the configured delay
  • Replicate to Generals

@bobtista bobtista self-assigned this Aug 14, 2026
@bobtista bobtista added Bug Something is not working right, typically is user facing Minor Severity: Minor < Major < Critical < Blocker labels Aug 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Bug Something is not working right, typically is user facing Minor Severity: Minor < Major < Critical < Blocker

Projects

None yet

Development

Successfully merging this pull request may close these issues.

MessageDelayMS uses an inverted unit conversion and has no practical effect

1 participant