feat(input): Use force attack to get the latest building orientation

[Caball009]

• Related PR: feat(input): Add ability to snap building rotation to 45 degree angles #1472

This PR allows the use of force attack (i.e. pressing CTRL) to get the latest building orientation that was used for the placement anchoring.

forcefire_building_orientation.mp4

TODO:

• Replicate in Generals.

[greptile-apps]

Greptile Overview

Greptile Summary

This PR adds a “latest building orientation” value to InGameUI and uses force-attack mode during building placement to reuse that angle when starting a new (unanchored) placement. The orientation is captured during placement confirmation in PlaceEventTranslator and then applied in InGameUI::handleBuildPlacements.

Key merge blockers:

• InGameUI.h now depends on RANDOM_START_ANGLE but doesn’t guarantee the defining header is included, which can break compilation in translation units that include InGameUI.h directly.
• The latest orientation is only persisted for the normal dozer construct flow; special-power construction placements don’t update it, so the feature will behave inconsistently depending on placement mechanism.

Confidence Score: 3/5

• This PR is close to mergeable but has a couple of functional/compile correctness issues to address first.
• Confidence is reduced by (1) a likely missing header dependency for RANDOM_START_ANGLE that can cause compile failures depending on include order, and (2) incomplete persistence of the latest orientation for special-power placement paths, which makes the feature inconsistent.
• GeneralsMD/Code/GameEngine/Include/GameClient/InGameUI.h; GeneralsMD/Code/GameEngine/Source/GameClient/MessageStream/PlaceEventTranslator.cpp

Important Files Changed

Filename	Overview
GeneralsMD/Code/GameEngine/Include/GameClient/InGameUI.h	Adds latest building orientation getter/setter and member; introduces compile dependency on RANDOM_START_ANGLE without ensuring definition is included.
GeneralsMD/Code/GameEngine/Source/GameClient/InGameUI.cpp	Initializes/resets latest orientation and applies it during unanchored placement when force-attack mode is active.
GeneralsMD/Code/GameEngine/Source/GameClient/MessageStream/PlaceEventTranslator.cpp	Stores latest orientation on successful normal placement, but not for special-power placements.

Sequence Diagram

sequenceDiagram
  participant PET as PlaceEventTranslator
  participant UI as InGameUI
  participant BA as BuildAssistant
  participant MS as MessageStream

  PET->>UI: getPendingPlaceType()
  PET->>UI: isPlacementAnchored()
  alt anchored & click
    PET->>UI: getPlacementAngle()
    PET->>UI: getPlacementPoints()
    PET->>BA: isLocationLegalToBuild(world, build, angle, ...)
    alt legal
      PET->>MS: appendMessage(MSG_DOZER_CONSTRUCT[_LINE])
      PET->>MS: appendRealArgument(angle)
      PET->>UI: placeBuildAvailable(nullptr, nullptr)
      PET->>UI: setLatestBuildingOrientation(angle)
    else illegal
      PET->>UI: displayCantBuildMessage(lbc)
      PET->>UI: setPlacementStart(nullptr)
    end
  end

  note over UI: During subsequent placements (not anchored),
  note over UI: handleBuildPlacements may override angle with
  note over UI: latestBuildingOrientation when force-attack mode is active.

Loading

[xezon]

Nice feature.

[Caball009]

Nice feature.

Thanks. I'm not sure if you tested it, but I think it's good if someone tests this to verify the new behavior is desirable before it's merged.

[xezon]

@Stubbjax

[greptile-apps]

_{2 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Wrong modifier state used

This change keys off isInForceAttackMode(), but the PR description says this behavior should be enabled by holding CTRL during placement. In this codebase isInForceAttackMode() is a broader UI state (used in selection/command translation), and it can be true outside of the “holding CTRL while placing” scenario. That means building placement orientation can be overridden unexpectedly whenever force-attack mode is active.

If the intent is “only while CTRL is held during placement”, use the same input source that sets/reflects the CTRL modifier state for placement (or explicitly check the modifier key in handleBuildPlacements).

Prompt To Fix With AI

This is a comment left during a code review.
Path: GeneralsMD/Code/GameEngine/Source/GameClient/InGameUI.cpp
Line: 1620:1622

Comment:
**Wrong modifier state used**

This change keys off `isInForceAttackMode()`, but the PR description says this behavior should be enabled by holding `CTRL` during placement. In this codebase `isInForceAttackMode()` is a broader UI state (used in selection/command translation), and it can be true outside of the “holding CTRL while placing” scenario. That means building placement orientation can be overridden unexpectedly whenever force-attack mode is active.

If the intent is “only while CTRL is held during placement”, use the same input source that sets/reflects the CTRL modifier state for placement (or explicitly check the modifier key in `handleBuildPlacements`).

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

[Stubbjax]

A few notable issues:

1. When holding CTRL during building placement mode (especially for the first time), the building is rotated in an unexpected way that can throw the user off. For example, a War Factory or Command Center rotates from facing SW to E.

2. The rotation is cached even if the building does not end up being placed.

3. The cached rotation persists between games.

I think there is a fundamental conflict with the existing 45° snapping behaviour in its current form. It is somewhat distracting and possibly confusing to initially see the building rotate to a seemingly arbitrary angle upon holding CTRL, particularly when the desired behaviour is exclusively the 45° snapping. It feels more like a bug than a feature.

I'd be interested to discuss what pain points this feature is addressing. Is it commonly desirable to rotate multiple buildings to share a non-standard angle? If so, the current implementation feels quite fragile as it's very easy to accidentally lose the cached rotation, and it's only really feasible when such aligned buildings are placed consecutively.

See Stubbjax review

[Caball009]

@Stubbjax Thanks, that's good feedback. I fixed issues 2 and 3, also the first time that's mentioned in 1.

it's only really feasible when such aligned buildings are placed consecutively.

That's the primary purpose. I think it's particularly convenient when building multiple drop zones or black markets. I find placement anchoring a bit clunky. It's alright for a single building, but if I have multiple buildings that I'd like to build with the same orientation it's somewhat inconvenient.

I made some changes that should make the experience better. Would you mind trying it again, and let me know if it's more to your liking?

[greptile-apps]

_{3 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Additional Comments (1)

GeneralsMD/Code/GameEngine/Source/GameClient/MessageStream/PlaceEventTranslator.cpp
Orientation not persisted
The new “latest building orientation” is only saved in the normal placement path (after MSG_DOZER_CONSTRUCT[_LINE]), but this special-power construction path (MSG_DO_SPECIAL_POWER_AT_LOCATION) exits without calling setLatestBuildingOrientation(angle). If players place structures via special powers, the feature won’t update and CTRL/force-attack reuse will reflect an older orientation.

Prompt To Fix With AI

This is a comment left during a code review.
Path: GeneralsMD/Code/GameEngine/Source/GameClient/MessageStream/PlaceEventTranslator.cpp
Line: 233:260

Comment:
**Orientation not persisted**
The new “latest building orientation” is only saved in the normal placement path (after `MSG_DOZER_CONSTRUCT[_LINE]`), but this special-power construction path (`MSG_DO_SPECIAL_POWER_AT_LOCATION`) exits without calling `setLatestBuildingOrientation(angle)`. If players place structures via special powers, the feature won’t update and CTRL/force-attack reuse will reflect an older orientation.

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

[Stubbjax]

I made some changes that should make the experience better. Would you mind trying it again, and let me know if it's more to your liking?

It's a good improvement, though clicking an invalid location causes the cached rotation to be lost, which is unexpected and undesirable.

That's the primary purpose. I think it's particularly convenient when building multiple drop zones or black markets. I find placement anchoring a bit clunky. It's alright for a single building, but if I have multiple buildings that I'd like to build with the same orientation it's somewhat inconvenient.

How practical is this during a real game? There is a highly specific list of assumptions:

1. The player has enough money to afford and consecutively place a number of such buildings
2. The player does not rotate another building afterwards, or else they can no longer align any subsequent buildings
3. The player desires their buildings to be on an odd or non-45° angle
4. The player intends to daringly pack such buildings tightly together (where a shared alignment makes more sense)

ALIGN.mp4

It's unlikely that such a player would not align their buildings with the map (90°) or the default orientation (45°). There's also no way to align another building relative to any non-standard existing ones with an offset of 90° or 180° (e.g. if a player has a bunch of 75.42° Supply Drop Zones, how would they align an Air Field at 165.42°?).

It feels like the feature could have limited use cases in casual scenarios where aesthetics are prioritised over strategy - in which case I'd suggest time or convenience is less of a concern and the existing snapping behaviour is already adequate and less prone to frustration. Considering the feature's fragility and rigidity, its highly visible visual conflict with the existing snapping behaviour, and the counterintuitive and clunky nature of a modifier key actively changing state, it may even be seen as more of a hindrance than an improvement.

I would suggest the implementation and more importantly the design be reconsidered. Is such a feature needed?

Alternatively, can the existing snapping behaviour be improved? How is it clunky or inconvenient?