bugfix(input): Block all button presses except ESC during scripted camera scenes

[xezon]

It is possible to call user camera action during cinematic scenes. For example set a Bookmark with CTRL+F1, and then press F1 during a cutscene: the camera jumps there.

The fixed logic prevents all button presses except ESC when the input is disabled.

[greptile-apps]

Greptile Summary

This PR adds a targeted keyboard-input guard to WindowTranslator::translateGameMessage in both Generals and Zero Hour builds. When TheInGameUI->getInputEnabled() returns FALSE (i.e. during scripted camera/cinematic scenes), all MSG_RAW_KEY_DOWN and MSG_RAW_KEY_UP events except KEY_ESC are now consumed (returnCode = WIN_INPUT_USED), preventing actions like camera-bookmark jumps from firing during cutscenes. The fix mirrors the already-existing mouse-input guard in the same function and is applied identically in both codebases.

Confidence Score: 5/5

Safe to merge — minimal, focused fix with no regressions on mouse handling or the existing ESC-to-exit-movie path.

The new logic is a clean extension of the pre-existing mouse guard pattern; both affected files are changed identically, the ESC carve-out is intentional and correct, and the only note is a minor P2 observation about key-down vs key-up asymmetry that has no current impact.

No files require special attention.

Important Files Changed

Filename	Overview
Generals/Code/GameEngine/Source/GameClient/MessageStream/WindowXlat.cpp	Adds a guard in the MSG_RAW_KEY_DOWN/UP case to consume all non-ESC keys when TheInGameUI input is disabled, matching the existing mouse-input guard pattern; logic is correct and consistent.
GeneralsMD/Code/GameEngine/Source/GameClient/MessageStream/WindowXlat.cpp	Identical guard added for Zero Hour; code is in sync with the Generals counterpart and follows the same logic.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[MSG_RAW_KEY_DOWN / MSG_RAW_KEY_UP] --> B[winProcessKey via TheWindowManager]
    B --> C{returnCode == WIN_INPUT_USED?}
    C -- Yes --> H[Key consumed]
    C -- No --> D{key == KEY_ESC AND movie playing AND allowExitOutOfMovies?}
    D -- Yes --> E[stopMovie\nreturnCode = WIN_INPUT_USED]
    E --> H
    D -- No --> F{returnCode != WIN_INPUT_USED\nAND key != KEY_ESC\nAND input disabled?}
    F -- Yes --> G["returnCode = WIN_INPUT_USED\n(NEW GUARD — blocks bookmarks etc.)"]
    G --> H
    F -- No --> I[Key passes through to game handlers]

Loading

Prompt To Fix All With AI

This is a comment left during a code review.
Path: Generals/Code/GameEngine/Source/GameClient/MessageStream/WindowXlat.cpp
Line: 313-318

Comment:
**ESC key-down event still propagates during disabled input**

When input is disabled, the new block correctly lets `KEY_ESC` through, but it makes no distinction between `KEY_STATE_DOWN` and `KEY_STATE_UP`. That means both the key-down and key-up ESC events reach further handlers. The existing movie-escape guard above already scopes its own action to `KEY_STATE_UP`, so this is mostly harmless today. Just worth noting in case any future handler acts on ESC key-down during a cinematic and produces an unintended side-effect. No immediate bug, but the pairing with the movie-escape logic above is slightly asymmetric.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "bugfix(input): Block all button presses ..." | Re-trigger Greptile}

[Skyaero42]

Looks good

[Caball009]

This could use a tweak because it also applies to replays, so e.g. fast forward doesn't work.

[xezon]

Fast Forward during cutscenes?

[Caball009]

Scripted camera scenes. Some custom maps have those, especially at map start.