fix(savegame): Use getFinalOverride in WeaponSet xfer load to match Object constructor

[bobtista]

Summary

Fixes weapon timing state corruption after loading a saved game by ensuring WeaponSet uses the same template override as Object.

Notes

• Object constructor calls getFinalOverride() on the template (Object.cpp:230)
• WeaponSet::xfer(LOAD) was using TheThingFactory->findTemplate() which returns the base template, not the final override
• This caused m_curWeaponTemplateSet to point to a different ThingTemplate's weapon sets than obj->getTemplate()
• The pointer mismatch in updateWeaponSet() triggered unnecessary weapon reallocation, resetting timing state

Fix

Add getFinalOverride() call in WeaponSet::xfer(LOAD) to match what Object does, ensuring consistent template pointers.

Testing

• Save game with units that have weapons mid-reload
• Load the save and verify weapons maintain their reload state
• Verify normal weapon switching still works correctly

Todo

• Replicate to Generals

[greptile-apps]

Greptile Summary

This PR fixes weapon timing state corruption on savegame load by ensuring WeaponSet::xfer(LOAD) resolves the same final template override that the Object constructor uses. Previously, findTemplate() returned the base template, causing m_curWeaponTemplateSet to point to a different template's weapon sets than obj->getTemplate(), which triggered spurious reallocation in updateWeaponSet() and reset reload timing.

• Adds tt = static_cast<const ThingTemplate*>(tt->getFinalOverride()) after the existing null check in the LOAD branch, directly mirroring the pattern at Object.cpp:211.
• The fix is correctly replicated to both Generals/ and GeneralsMD/ codebases.
• getFinalOverride() always returns at least this (never nullptr), so no additional null guard is needed after the call.

Confidence Score: 5/5

Safe to merge — the change is a minimal, targeted fix confined to the XFER_LOAD branch with no impact on the save path or normal gameplay codepath.

The one-liner mirrors an identical pattern already used in Object.cpp, getFinalOverride() is guaranteed non-null by its implementation (returns this when no override exists), the existing null check on tt before the call is preserved, and the fix is correctly duplicated to both game codebases.

No files require special attention.

Important Files Changed

Filename	Overview
Generals/Code/GameEngine/Source/GameLogic/Object/WeaponSet.cpp	Adds getFinalOverride() call in XFER_LOAD path to match Object constructor behavior, preventing template pointer mismatch and spurious weapon reallocation on savegame load.
GeneralsMD/Code/GameEngine/Source/GameLogic/Object/WeaponSet.cpp	Identical fix replicated to Zero Hour (GeneralsMD), maintaining parity between the two game codebases.

Sequence Diagram

%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
    participant XF as Xfer (LOAD)
    participant WS as WeaponSet::xfer
    participant TF as TheThingFactory
    participant TT as ThingTemplate (base)
    participant FO as ThingTemplate (final override)

    XF->>WS: xfer(LOAD)
    WS->>TF: findTemplate(ttName)
    TF-->>WS: tt (base template)
    Note over WS: Before fix: used base tt directly
    WS->>TT: getFinalOverride()
    TT-->>WS: tt (final override)
    Note over WS: After fix: use final override tt
    WS->>FO: findWeaponTemplateSet(wsFlags)
    FO-->>WS: m_curWeaponTemplateSet
    Note over WS: Now matches Object constructor's template pointer

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
    participant XF as Xfer (LOAD)
    participant WS as WeaponSet::xfer
    participant TF as TheThingFactory
    participant TT as ThingTemplate (base)
    participant FO as ThingTemplate (final override)

    XF->>WS: xfer(LOAD)
    WS->>TF: findTemplate(ttName)
    TF-->>WS: tt (base template)
    Note over WS: Before fix: used base tt directly
    WS->>TT: getFinalOverride()
    TT-->>WS: tt (final override)
    Note over WS: After fix: use final override tt
    WS->>FO: findWeaponTemplateSet(wsFlags)
    FO-->>WS: m_curWeaponTemplateSet
    Note over WS: Now matches Object constructor's template pointer

Loading

_{Reviews (4): Last reviewed commit: "fix(savegame): Replicate WeaponSet getFi..." | Re-trigger Greptile}

[xezon]

My first hunch here is that this change is a hack. Why is m_curWeaponTemplateSet set to something that satisfies the weapon flags but is not actually the real deal? It indicates that the issue is higher up.

[bobtista]

Ok, updated with a better approach.
When an Object is created (Object.cpp:230):
tt = (const ThingTemplate*)tt->getFinalOverride();
The Object uses the final override of the template.

But when WeaponSet::xfer(LOAD) restored weapon data (WeaponSet.cpp:231):
const ThingTemplate* tt = TheThingFactory->findTemplate(ttName);
m_curWeaponTemplateSet = tt->findWeaponTemplateSet(wsFlags);
It used findTemplate() which returns the base template, not the final override.

The fix is to just add t = (const ThingTemplate*)tt->getFinalOverride(); to WeaponSet::xfer(LOAD):

[Caball009]

Looks like a good change, but the title and issue description need to be updated (the summary is no longer in line with the current code change).

[bobtista]

Looks like a good change, but the title and issue description need to be updated (the summary is no longer in line with the current code change).

Updated

[bobtista]

Rebased again, this is ready for re-review