Implemented Force Generation 3, Including Clan Bidding & Batchall System #4865
Conversation
This file contains 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
Replaced `calculatePlayerForceWeightClass` with `randomForceWeight` for generating force weight class.
Simplified weight class handling, force generation logic, and bot selection processes. Improved readability and maintainability by consolidating imports and removing redundant code. Adjusted weighted tables in `atbconfig.xml` to streamline scenario configurations.
Refactored the skill generation logic in StratConSkillGenerator to streamline skill level calculations and removed redundant bonus handling. Also cleaned up logging in AtBDynamicScenarioFactory and removed an unnecessary skill generator type setting.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #4865 +/- ##
==========================================
Coverage 10.31% 10.31%
- Complexity 5872 5885 +13
==========================================
Files 944 946 +2
Lines 131403 131798 +395
Branches 19064 19131 +67
==========================================
+ Hits 13548 13589 +41
- Misses 116539 116895 +356
+ Partials 1316 1314 -2 ☔ View full report in Codecov by Sentry. |
Added logging for force generation and BV culling in AtB Dynamic Scenario Factory. Adjusted BV budget handling with a new multiplier for more accurate force balancing. Simplified BV budget calculations by removing redundant multiplications.
|
I've loosened up unit culling (when a force is over budget). Now, instead of just checking 'am I over budget' it now only starts culling if the resulting force is >25% over budget. The original system was too consistently producing under budget forces. |
Removed a debug logging statement from AtBConfiguration and refactored AtBScenarioModifierApplicator to simplify method calls by using static imports and dynamic force weight generation.
Introduced a new campaign option to use Generic Battle Value for balancing bot forces. This change ensures scenarios can utilize an average battle value independent of pilot skill, offering varied difficulty depending on opponent type. Updated relevant methods and UI components to support this new option.
|
Added an option to balance based on Generic BV instead of True BV (enabled by default) |
Introduced a new campaign option to use Generic Battle Value for balancing bot forces. This change ensures scenarios can utilize an average battle value independent of pilot skill, offering varied difficulty depending on opponent type. Updated relevant methods and UI components to support this new option.
…neration3 # Conflicts: # MekHQ/src/mekhq/campaign/force/Force.java # MekHQ/src/mekhq/campaign/mission/AtBDynamicScenarioFactory.java
Removed redundant forceBV recalculation before logging and moved balancingType determination for concise code. This change improves efficiency by eliminating unnecessary loops and ensures that forceBV and balancingType are determined only when needed.
Added a forceStandardBattleValue parameter in multiple BV calculation methods to allow optional usage of standard BV. Implemented bidding away of forces for Clan factions to create more balanced engagements. Adjusted various components to handle this new logic appropriately.
Implemented a new option "useVerboseBidding" for detailed Clan force bid reporting. Added logic to dynamically adjust and supplement bot forces during scenario generation to maintain balance. Enhanced methods for Clan and mixed unit generation accordingly.
Incorporated new logic to initiate Batchall with detailed prompts and enhanced user interactions. Added functionality to adjust bot forces based on player responses and introduced localized resource strings for varied Batchall statements.
Ensured Batchall initiation occurs only for non-player forces by checking the team's alignment before calling the method. Also adjusted the reporting of bidding results to apply the same condition, preventing unnecessary reporting for player forces.
Replaced static HTML tag with a localized string for the batchall conclusion message in AtBDynamicScenarioFactory.java. Added new localized string "batchallConcluded.text" in AtBDynamicScenarioFactory.properties to facilitate this change.
Updated the AtBDynamicScenarioFactory to randomly select between two different conclusion texts for batchall reports, adding variability to the report generation. The two possible texts are "Bargained Well and Done" and "Well-Bargained and Done".
Replaced the fixed Battle Value multiplier with a dynamic honor rating system for different Clans based on the timeline. Added the `getHonorRating` method to calculate the honor rating and adjusted the bidding logic accordingly. This makes the bot's behavior more realistic and aligned with Clan honor practices.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
MekHQ/src/mekhq/campaign/mission/AtBDynamicScenarioFactory.java
Dismissed
Show dismissed
Hide dismissed
|
Added Clan bidding and batchall mechanics. Flipping this to live. It's now feature complete and I'm going back to bug fixes. |
rjhancock
reviewed
Sep 22, 2024
rjhancock
reviewed
Sep 22, 2024
rjhancock
reviewed
Sep 22, 2024
MekHQ/src/mekhq/campaign/mission/AtBDynamicScenarioFactory.java
Outdated
Show resolved
Hide resolved
|
I'm getting multiple bachall transmissions for each scenario. One from each of the enemy commanders. IE one from the primary OPFOR, then one from the infantry, then one from the irregulars. BA is also generating as escorts for offboard artillery. CBS302530250117.cpnx.gz |
|
So multiple Batchalls, one per enemy bot force, is intentional. There was a discussion about having it trigger once per contract. I'm torn as to which is the best option. Off-board units and aerospace certainly shouldn't get random BA tagging along, though. I didn't think to exclude them. |
|
Got some feedback from QA, so I'm going to switch this to draft while I do some reworks to the Batchall system |
Moved Batchall initiation logic to AtBContract for better encapsulation. This involved removing redundancy from AtBDynamicScenarioFactory and incorporating related resource strings into AtBContract.
Converted string concatenations to `String.format` for generating log messages in `AtBDynamicScenarioFactory`. This change enhances readability and consistency in logging output for force generation, culling, and final force statistics.
IllianiCBT
changed the title
|
Flipping this once again from Draft to Live. At this point any remaining issues can be resolved in a future PR, I think we need to get this merged and tested so further changes can be made using 'real' data. |
Added Campaign parameter to updateEnemy method and enhanced batchall logic for Clan enemies. Removed redundant deriveRoleFromUnitType method. These changes streamline enemy updates and improve modularity within the mission handling framework.
… functionality Implemented the Fame and Infamy module to track faction fame levels and batchall statements. Introduced the `BatchallFactions` and `FameAndInfamyController` classes for managing batchall usage and fame data. Updated relevant methods in `Campaign` and `AtBContract` to integrate this new feature, including XML writing and greeting adaptations.
|
Ok, now I'm finished for real. The only change impending is replacing the last couple of placeholders in one of the resource bundles, but that can be added post-merge. |
Replaced the version string retrieval method with detailed faction-specific handling using a switch statement. Improved the batchall dialog by adding tooltips and refactoring the refuse confirmation dialog for better user interaction. Switch statement also added for better management of faction icons.
Refactored dialog creation and handling for refusal and noBatchall scenarios to use JDialog and improve user experience with more interactive components. Made minor adjustments to variable initialization and fixed a string concatenation issue in BatchallFactions.java. Updated the ranks.xml version to reflect these changes.
HammerGS
approved these changes
Sep 25, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Requires #6021
This PR aims to retool our OpFor generation system for StratCon to provide a better play experience for our users.
First of all, this PR adjusts the AtB force generation tables used to generate formations of a certain weight. The old AtB system identified what weight force it wanted to generate and then rolled a 'die'. Depending on the roll the final force would be at weight, or lighter. What this meant is that a target 'heavy' lance could be aimed for, but three light lances would be spawned instead. Now, if the OpFor is meant to get a 'heavy' lance, they will always get a 'heavy' lance, though the exact make-up of that lance will vary.
Speaking of which, the lance compositions (what weight unit goes into what weight of lance) have been reworked to match the tables on 265 of TW.
Regarding what weight force should be generated. Previously, this would be based on the mean weight of the player force. Now it is randomized, based on the random force weight table on p265 of TW. Furthermore, this is rolled on a per-bot basis. Previously, one roll would be made and applied to all bot forces. Now each force will make a separate roll. That means bot A might bring an 'assault' force, while bot b might favor a 'medium' force.
Difficulty modifiers were being applied twice. Now they are not. Whoops!
The main beneficiaries of these changes will be Aerospace players and players with very large BV forces (25K+ per lance). However, with the other changes made previously, I think the overall feel and experience of fighting MekHQ OpFors will be greatly improved.
The following images show a regular OpFor with C-rated equipment vs. the following lance. Note that all pilots are 'legendary' (0/1).
Old System
New System
Oh and I added a dynamic Batchall system for the clans, nothing big ;)