forked from electronicarts/CnC_Generals_Zero_Hour
-
Notifications
You must be signed in to change notification settings - Fork 205
bugfix(logic): Restore retail compatibility after change in CountermeasuresBehavior::calculateCountermeasureToDivertTo #2808
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
Caball009
wants to merge
1
commit into
TheSuperHackers:main
Choose a base branch
from
Caball009:fix_loop_iteration_countermeasures
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+7
−3
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
max(..., 1u)guard introduces a minor retail behavioral changem_volleySizeis declared asUnsignedIntand defaults to0inCountermeasuresBehaviorModuleData. With the guard, a unit whoseVolleySizeINI field is0now enters the loop once instead of skipping it entirely, potentially returning a flare ID where the original retail code would have returnedINVALID_ID. The PR description explicitly notes this change "was not necessary to fix the mismatch," so it risks introducing a small delta from true retail behavior for the zero-volley-size edge case. Consider whether to guard withmaxonly under#if !RETAIL_COMPATIBLE_CRC.Prompt To Fix With AI
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was the original code prior to #1367
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for sharing that — the
MAX(data->m_volleySize, 1)guard was already in the original retail code before #1367, so this PR is correctly restoring that behavior. My concern was incorrect; themax(..., 1u)here is not a new change from retail.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@greptileai re-review this pull request accordingly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The fix is correct and well-structured. Here's the updated review:
The core fix — moving
++volleyFlaresCountedoutside theif (obj)block under#if RETAIL_COMPATIBLE_CRC— accurately restores the original retail behavior. In the original EA code,while(iteratorMax--)decremented the counter on every iteration regardless of whether the looked-up object was still alive/valid. The previous implementation in #1367 only incremented insideif (obj), meaning null/expired flare entries didn't count toward the volley limit, causing the replay CRC mismatch.The
max(data->m_volleySize, 1u)guard is confirmed to match the original retail code (MAX(data->m_volleySize, 1)), so no concerns there.Type change from
inttoUnsignedIntis appropriate sincem_volleySizeisUnsignedIntand these values are never negative.The
RETAIL_COMPATIBLE_CRCpath behavior is correct:break(retail: stop at first valid flare)++volleyFlaresCounted, continue loopwhile(iteratorMax--)semanticsThe change is minimal, targeted, and restores retail compatibility without touching the non-retail path. LGTM.