BUGFIX: Wrong calculation in team casualties of Bladeburner action #1672
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 are at least 2 regression bugs caused by the refactor in #1654.
Bug 1:
resolveTeamCasualties
does not short-circuit whenteamCount
is 0.With BlackOps,
minCasualties
is 1. IfteamCount
is 0,worstCase
is 0. When we callteam.getTeamCasualtiesRoll(action.getMinimumCasualties(), worstCase)
, it will callgetRandomIntInclusive(1, 0)
.getRandomIntInclusive
only accepts parameters in the form of(min, max)
.Bug 2:
humans
is not "clamped" properly. It should beconst humans = Math.max(action.teamCount - team.sleeveSize, 0);
.If
humans
becomes negative, all following calculations are wrong.For example: TeamSize = 3; SleeveSize = 3; TeamCount = 0; deaths = 1. In this case:
humans
is-3
.humanDeaths
is-3
.team.killRandomSupportingSleeves
is called with1 - (-3) = 4
.team.teamSize
= Math.max(3 - (-3), 3) = 6;These bugs were introduced because
resolveTeamCasualties
does not reuse the old logic:teamCount
is 0.humans
andhumanDeaths
.This PR rewrites the entire
resolveTeamCasualties
and reuses the old logic.For quick reference, this is how it was implemented:
Operation:
Black Operation: