-
Notifications
You must be signed in to change notification settings - Fork 399
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
AI - Fix battle results when checking for submerging #4739
Conversation
Codecov Report
@@ Coverage Diff @@
## master #4739 +/- ##
============================================
- Coverage 23.16% 23.15% -0.01%
- Complexity 6185 6200 +15
============================================
Files 871 873 +2
Lines 70452 70776 +324
Branches 11256 11338 +82
============================================
+ Hits 16321 16389 +68
- Misses 52097 52348 +251
- Partials 2034 2039 +5
Continue to review full report at Codecov.
|
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 core fix looks good. The public API with a boolean parameter I think can become problematic, left some commentary, please let me know what you think.
return calculateBattleResults(t, attackingUnits, defendingUnits, bombardingUnits, true); | ||
} | ||
|
||
public ProBattleResult calculateBattleResults(final Territory t, final List<Unit> attackingUnits, |
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.
Nitpicking the API, any thoughts to removing the boolean parameter?
Looking at this diff, it looks like if calculateBattleResults
with the boolean parameter were made private, the boolean parameter could be made class-internal by adding something like:
public ProBattleResult calculateBattleResultsNoSubmerge(final Territory t, final List<Unit> attackingUnits,
final List<Unit> attackingUnits, final List<Unit> defendingUnits, final Set<Unit> bombardingUnits) {
final List<Unit> defendingUnits, final Set<Unit> bombardingUnits) {
return calculateBattleResults(t, attackingUnits, defendingUnits, bombardingUnits, false);
}
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.
I think you can argue it either way in this case given that the method is only used in one place. But I went ahead and added a method to avoid exposing the boolean.
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.
From my perspective it is the class boundary that makes the difference. Regardless thanks for the update.
Overview
Functional Changes
Manual Testing Performed