Skip to content
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

Fix 5229: Multi-Trac units not firing energy weapons #5248

Conversation

Sleet01
Copy link
Collaborator

@Sleet01 Sleet01 commented Mar 14, 2024

There were a couple issues in the MultiTargetFireControl planning track:

  1. Energy weapons, or any weapon that doesn't actually track ammunition, would be skipped due to the way iterating over ammo was set up.
  2. All firing plans were being assessed as if the shooter were an Aerospace unit, which include much stricter heat penalties. As a result, Princess would be much less likely to fire multiple high-heat weapons in the same turn, even for 'Mechs.

TODO: since MultiTargetFireControl iterates over every target, for every weapon, for every possible arc, there is a good chance that we are calculating the same to-hit chances several times for given target-weapon pairings. We could speed this up by caching results in a map, similar to TAGging is now being tracked.

This should not affect Energy-only Bay Weapons.

Testing:

  • Ran all 3 projects' unit tests,
  • Ran version of fix on provided save game,
  • Created new game for full fix with multiple Multi-Trac units.

Close: #5229

@@ -2598,7 +2598,8 @@ FiringPlan getBestFiringPlan(final Entity shooter,
ammoConservation);
final FiringPlan plan = determineBestFiringPlan(parameters);

LogManager.getLogger().info(shooter.getDisplayName() + " at " + enemy
// Debug logging; Princess does her own info logging
LogManager.getLogger().debug(shooter.getDisplayName() + " at " + enemy
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

General optimization suggestion: for methods that are called many times, calling logging methods (especially within a loop) leads to a performance decrease, even if the logging level doesn't result in the message being logged. Let's make the adjustment to comment this out as we don't really need the info outside of direct debugging.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can just do the debug logging alongside the Princess-level .info() logging, which is once per unit per round.

Copy link
Member

@NickAragua NickAragua Mar 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure. This particular logging is is once per unit per enemy per round. Granted, it's during the firing phase which doesn't really have performance issues usually, but still.

@@ -78,6 +79,10 @@ public FiringPlan getBestFiringPlan(final Entity shooter,

if (currentPlan.getUtility() > bestPlan.getUtility()) {
bestPlan = currentPlan;

// Debug logging; Princess does her own info-level logging
LogManager.getLogger().debug(shooter.getDisplayName() + " - Best Firing Plan: " +
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As per the other logging comment - this is in a loop so we want to eliminate it.

@Sleet01 Sleet01 merged commit a5c2f85 into MegaMek:master Mar 18, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants