Codecov Report

Attention: Patch coverage is 13.02876% with 1028 lines in your changes missing coverage. Please review.

Project coverage is 30.79%. Comparing base (0cdf452) to head (7f4a883).
Report is 65 commits behind head on master.

@@             Coverage Diff              @@
##             master    #7108      +/-   ##
============================================
+ Coverage     30.75%   30.79%   +0.03%     
- Complexity    16826    17029     +203     
============================================
  Files          2936     2940       +4     
  Lines        285817   287606    +1789     
  Branches      49726    50210     +484     
============================================
+ Hits          87901    88565     +664     
- Misses       191624   192536     +912     
- Partials       6292     6505     +213     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Asked AI about the Java Doc failure. Says this.

1. Fix Javadoc Errors in Game.java
   Errors and warnings in Game.java include missing @param, @return, and @throws tags for certain methods.

Code Suggestions:
Method: getNextHiddenEntityNum Add the missing @param description for start.

/**
 * Retrieves the next hidden entity number.
 * 
 * @param turn the current game turn
 * @param start the starting point for the search
 * @return the next hidden entity number
 */
public int getNextHiddenEntityNum(GameTurn turn, int start) {
    // Method implementation
}

Method: removeFirstTurnFor Add the missing @param, @return, and @throws tags.

/**
 * Removes the first turn for the given entity.
 * 
 * @param entity the entity whose turn is to be removed
 * @return the removed game turn, or null if none exists
 * @throws Exception if an error occurs during removal
 */
public @Nullable GameTurn removeFirstTurnFor(final Entity entity) throws Exception {
    // Method implementation
}

Method: setAllReports Add the missing @param tag.

/**
 * Sets all reports for the game.
 * 
 * @param v a list of lists of reports to set
 */
public void setAllReports(List<List<Report>> v) {
    // Method implementation
}

2. Fix XML Tag Issues in TWGameManager.java
   The error indicates improperly closed tags in the Javadoc comments.

/**
 * <code>Report</code>s to. It may be empty, but not null.
 */

@HammerGS The Game.java stuff is outside my scope, but I can try fixing the tag error.

One of the recent changes has introduced an OOM at the end of the firing phase on very large matches; I've confirmed it's not in the old damage code so I'm taking this to Draft to find the issue.

Turns out early return escapes need to be replaced with something after they are removed.
Now with the deprecation updates as well.

Also, can you rename the "new" damage manager to something else?
Like "TWDamageManagerModular", the other one could be named "TWDamageManagerLegacy", this way we dont endup with any NTWDamageManagerNewNewThisOneFinal

If TWDamageManager needs both GameManager and Game... can't it use the game reference from the GameManager itself? Also, since it is so vital for it, would be best if the TWDamageManager had to be be initialized on its constructor with a TWGameManager, solving all possible error states because of bad initialization.

Are you familiar with the "Chicken and Egg" problem? 😸
I've created a mutual dependency between TWGameManager, which now cannot run a game without TWDamageManager, and TWDamageManager, which needs functions on TWGameManager to do its work.
This means that only one of them can instantiate the other within its constructor, not both.
Some languages would be able to resolve this with a double-pass approach under the hood, but it doesn't look like Java is one of them.
So one of the two classes cannot require the other for its constructor, and I decided that would be TWDamageManager as this seemed the simplest to deal with.

Further, while we currently automatically create a Game instance when instantiating TWGameManager, we may not always - and decoupling the Game instance from the TWGameManager instance makes for easier testing.

In the near future I plan to move more functionality out of TWGameManager into TWDamageManager, which should remove this mutual dependency, but for now I wanted to get the new damage handling code out and tested by players.

Also, can you rename the "new" damage manager to something else? Like "TWDamageManagerModular", the other one could be named "TWDamageManagerLegacy", this way we dont endup with any NTWDamageManagerNewNewThisOneFinal

I can do this, but the "Legacy" TWDamageManager is going away once we're comfortable with the new code, and the new code will replace its innards. So we'll only have TWDamageManagerModular for 1~2 releases.