bugfix: Fix cases where supply units return to collect supplies after receiving player-issued commands

[Stubbjax]

This change fixes an issue where supply units would remain in a collection state if given a command during their initial path out from the Supply Center/Stash. This would cause them to either outright ignore commands (such as a construct or repair command) or resume collection after going idle (such as after completing a move command).

The issue is exacerbated if the supply unit is following a rally point.

Note

Supply Workers ignoring Stop commands is a separate issue not covered by this change.

Before

BEFORE.mp4

After

AFTER.mp4

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Honor Player Commands by Clearing Forced Supply Collection

🐞 Bug fix 🕐 20-40 Minutes

AI Description

• Clears forced supply collection when players redirect trucks, workers, or Chinooks.
• Prevents completed commands from restoring stale supply-gathering behavior.
• Guards behavior changes to preserve retail-compatible CRC builds.

Diagram

graph TD
  PC["Player Command"] --> ST["Supply Truck AI"] --> CS{"Player issued?"}
  CS -- Yes --> CL["Clear Supply Latch"] --> BH["Base Command Handling"]
  CS -- No --> BH
  WT["Worker Task"] --> CL
  CT["Chinook Transport"] --> CL

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Centralize cancellation in the supply state machine

• ➕ Could reduce explicit latch resets across specialized AI implementations.
• ➕ Would cover future transitions that leave supply behavior.
• ➖ May incorrectly cancel AI-driven forced collection during production exits or regrouping.
• ➖ Requires broader state-machine changes with greater gameplay and synchronization risk.
• ➖ Worker construction and Chinook transport transitions do not share one command path.

Recommendation: Keep the PR’s targeted resets. Clearing the supply-specific latch at player-command and mode-transition boundaries minimizes behavioral risk, while the retail CRC guards preserve compatibility. A centralized state-machine policy would be cleaner conceptually but could interfere with intentional AI-driven collection.

Files changed (8) +54 / -0

Bug fix (8) +54 / -0

SupplyTruckAIUpdate.hDeclare supply truck command interception +1/-0

Declare supply truck command interception

• Adds an 'aiDoCommand' override so supply trucks can cancel pending forced collection before delegating commands.

Generals/Code/GameEngine/Include/GameLogic/Module/SupplyTruckAIUpdate.h

ChinookAIUpdate.cppCancel forced collection when Chinooks begin transport duty +3/-0

Cancel forced collection when Chinooks begin transport duty

• Clears the forced-wanting latch when a landing Chinook discards supplies for transport duty. The change is excluded from retail-compatible CRC builds.

Generals/Code/GameEngine/Source/GameLogic/Object/Update/AIUpdate/ChinookAIUpdate.cpp

SupplyTruckAIUpdate.cppClear stale supply state on player commands +12/-0

Clear stale supply state on player commands

• Intercepts player-issued commands to disable forced supply collection, then delegates to standard AI command handling. AI-issued commands remain unchanged.

Generals/Code/GameEngine/Source/GameLogic/Object/Update/AIUpdate/SupplyTruckAIUpdate.cpp

WorkerAIUpdate.cppPrevent worker tasks from restoring supply collection +11/-0

Prevent worker tasks from restoring supply collection

• Clears forced supply collection during construction, transitions to dozer tasks, and general player-command reevaluation. All behavioral changes are guarded for retail CRC compatibility.

Generals/Code/GameEngine/Source/GameLogic/Object/Update/AIUpdate/WorkerAIUpdate.cpp

SupplyTruckAIUpdate.hDeclare Zero Hour supply command interception +1/-0

Declare Zero Hour supply command interception

• Adds the corresponding 'aiDoCommand' override to the GeneralsMD supply truck AI declaration.

GeneralsMD/Code/GameEngine/Include/GameLogic/Module/SupplyTruckAIUpdate.h

ChinookAIUpdate.cppCancel Zero Hour Chinook supply collection on landing +3/-0

Cancel Zero Hour Chinook supply collection on landing

• Mirrors the Chinook transport transition fix by clearing forced collection after supplies are discarded, outside retail-compatible CRC builds.

GeneralsMD/Code/GameEngine/Source/GameLogic/Object/Update/AIUpdate/ChinookAIUpdate.cpp

SupplyTruckAIUpdate.cppHonor Zero Hour player-issued supply truck commands +12/-0

Honor Zero Hour player-issued supply truck commands

• Mirrors player-command interception for GeneralsMD supply trucks, clearing the forced collection latch before base handling.

GeneralsMD/Code/GameEngine/Source/GameLogic/Object/Update/AIUpdate/SupplyTruckAIUpdate.cpp

WorkerAIUpdate.cppPrevent Zero Hour worker supply-state restoration +11/-0

Prevent Zero Hour worker supply-state restoration

• Mirrors latch resets across construction, dozer-task transitions, and player-command reevaluation in the GeneralsMD worker AI.

GeneralsMD/Code/GameEngine/Source/GameLogic/Object/Update/AIUpdate/WorkerAIUpdate.cpp

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

1. Repair commands retain supply latch 🐞 Bug ≡ Correctness

Description

WorkerAIUpdate clears m_forcePending only in aiDoCommand's default case, so player
AICMD_REPAIR and AICMD_RESUME_CONSTRUCTION commands skip the reset while a newly produced worker
remains AS_DOZER. Their newTask reset only runs when already AS_SUPPLY_TRUCK, allowing the
production latch to switch the worker into supply mode and override the accepted task on the next
update.

Code

Generals/Code/GameEngine/Source/GameLogic/Object/Update/AIUpdate/WorkerAIUpdate.cpp[R1048-1050]

+#if !RETAIL_COMPATIBLE_CRC
+				setForceWantingState(FALSE);
+#endif

Evidence

Supply-center production sets the force-wanting latch after issuing the exit-path command. The
worker state machine defaults to AS_DOZER, enters supply mode when that latch is set, and is
evaluated before the dozer submachine; meanwhile, repair and resume commands bypass the changed
default branch, and newTask only clears the latch inside an AS_SUPPLY_TRUCK check. The
GeneralsMD implementation mirrors the same command dispatch and reset placement.

Generals/Code/GameEngine/Source/GameLogic/Object/Update/ProductionExitUpdate/SupplyCenterProductionExitUpdate.cpp[120-129]
Generals/Code/GameEngine/Source/GameLogic/Object/Update/AIUpdate/WorkerAIUpdate.cpp[1002-1051]
Generals/Code/GameEngine/Source/GameLogic/Object/Update/AIUpdate/WorkerAIUpdate.cpp[665-681]
Generals/Code/GameEngine/Source/GameLogic/Object/Update/AIUpdate/WorkerAIUpdate.cpp[1211-1225]
Generals/Code/GameEngine/Source/GameLogic/Object/Update/AIUpdate/WorkerAIUpdate.cpp[1264-1298]
GeneralsMD/Code/GameEngine/Source/GameLogic/Object/Update/AIUpdate/WorkerAIUpdate.cpp[1002-1051]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Player repair and resume-construction commands bypass the newly added supply-latch reset because they have dedicated `aiDoCommand` switch cases. Clear the force-wanting latch for every accepted player command, including these special cases, in both game variants.

## Issue Context
Production exit sets the force-wanting latch after issuing its exit path. A worker can therefore still be in `AS_DOZER` when a player command arrives; the reset in `newTask` is insufficient because it is conditional on the worker already being in `AS_SUPPLY_TRUCK`.

## Fix Focus Areas
- Generals/Code/GameEngine/Source/GameLogic/Object/Update/AIUpdate/WorkerAIUpdate.cpp[1002-1051]
- Generals/Code/GameEngine/Source/GameLogic/Object/Update/AIUpdate/WorkerAIUpdate.cpp[665-681]
- GeneralsMD/Code/GameEngine/Source/GameLogic/Object/Update/AIUpdate/WorkerAIUpdate.cpp[1002-1051]
- GeneralsMD/Code/GameEngine/Source/GameLogic/Object/Update/AIUpdate/WorkerAIUpdate.cpp[665-681]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can show, collapse, or hide each part of a finding: code, evidence, and all

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-free-for-open-source-projects]

1. Repair commands retain supply latch 🐞 Bug ≡ Correctness

WorkerAIUpdate clears m_forcePending only in aiDoCommand's default case, so player
AICMD_REPAIR and AICMD_RESUME_CONSTRUCTION commands skip the reset while a newly produced worker
remains AS_DOZER. Their newTask reset only runs when already AS_SUPPLY_TRUCK, allowing the
production latch to switch the worker into supply mode and override the accepted task on the next
update.

Agent Prompt

## Issue description
Player repair and resume-construction commands bypass the newly added supply-latch reset because they have dedicated `aiDoCommand` switch cases. Clear the force-wanting latch for every accepted player command, including these special cases, in both game variants.

## Issue Context
Production exit sets the force-wanting latch after issuing its exit path. A worker can therefore still be in `AS_DOZER` when a player command arrives; the reset in `newTask` is insufficient because it is conditional on the worker already being in `AS_SUPPLY_TRUCK`.

## Fix Focus Areas
- Generals/Code/GameEngine/Source/GameLogic/Object/Update/AIUpdate/WorkerAIUpdate.cpp[1002-1051]
- Generals/Code/GameEngine/Source/GameLogic/Object/Update/AIUpdate/WorkerAIUpdate.cpp[665-681]
- GeneralsMD/Code/GameEngine/Source/GameLogic/Object/Update/AIUpdate/WorkerAIUpdate.cpp[1002-1051]
- GeneralsMD/Code/GameEngine/Source/GameLogic/Object/Update/AIUpdate/WorkerAIUpdate.cpp[665-681]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[tintinhamans]

Closes: #225