Skip to content

bugfix(saveload): Keep the dark low power appearance on disabled objects when saving - #3127

Draft
bobtista wants to merge 2 commits into
TheSuperHackers:mainfrom
bobtista:bobtista/bugfix/save-clears-low-power-appearance
Draft

bugfix(saveload): Keep the dark low power appearance on disabled objects when saving#3127
bobtista wants to merge 2 commits into
TheSuperHackers:mainfrom
bobtista:bobtista/bugfix/save-clears-low-power-appearance

Conversation

@bobtista

@bobtista bobtista commented Aug 13, 2026

Copy link
Copy Markdown

Fixes #3126. Follow up for #1651, which changed TintEnvelope::m_sustainCounter from UnsignedInt to Real.

The retail compatible save path still round-trips that counter through an UnsignedInt. SUSTAIN_INDEFINITELY is 0xfffffffe, and (Real)0xfffffffe rounds up to 4294967296, which is out of range for UnsignedInt — so converting it back is undefined, and on MSVC it yields 0 (checked on both x86 and x64). Because TintEnvelope::xfer assigns the converted value back into m_sustainCounter, this fires on save as well as load: the live counter becomes 0, the envelope leaves its sustain branch on the next update and calls release(), and the object stops being drawn dark while it is still disabled. RETAIL_COMPATIBLE_XFER_SAVE defaults to 1, so this is the shipping path. It also writes 0x00000000 where retail wrote 0xfffffffe, defeating the byte compatibility the guard exists to preserve.

Affected are the objects drawn dark indefinitely: unpowered and otherwise disabled objects, subdual damaged objects, and frenzied objects.

Now maps the sentinel explicitly in both directions so the v1 stream keeps retail's 0xfffffffe, and only assigns the serialized value back when loading, so saving can no longer change live state. Finite sustain values serialize exactly as before, so existing saves are unaffected.

Verified in game on a clean build of main using the reproduction in #3126. An unpowered Patriot Missile System loses its dark drawing within seconds of a save on main, and keeps it with this change:

Before:
R_MAIN_post15

After:
FIX_F_post15

Save/load round trip checked in all combinations: loading a save that was made while a structure was unpowered restores the dark drawing every time — save written by this branch loaded by this branch, save written by main loaded by this branch, and save written by main loaded by main. Drawable::xfer resets m_prevTintStatus on load, so the effect is re-triggered from the object's disabled status regardless of the stored counter. That is why the defect only shows in the session where the save happened, and why existing saves are unaffected either way.

Generals is replicated in a separate commit; the code and the fix are identical there.

Todo:

  • Test that an unpowered structure stays dark across a save
  • Test save/load round trip restores the dark drawing
  • Replicate to Generals

@bobtista bobtista self-assigned this Aug 13, 2026
@bobtista bobtista added Bug Something is not working right, typically is user facing Minor Severity: Minor < Major < Critical < Blocker labels Aug 13, 2026
@bobtista bobtista added the Saveload Is Saveload/Xfer related label 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 Saveload Is Saveload/Xfer related

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Low power structures lose their dark appearance after saving the game

1 participant