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

Added Basic Force Generator Role Functionality to Scenario Random Unit Generation #4418

Merged
merged 3 commits into from
Jul 15, 2024

Conversation

IllianiCBT
Copy link
Collaborator

@IllianiCBT IllianiCBT commented Jul 15, 2024

All credit to SuperStucco. All I've done is duplicated their work to resolve git issues.

This PR should not be merged until it has been approved by @SuperStucco as the chance of errors creeping in while I transcribed their work is non-zero.

This is another chunky PR, touches lots of bits and pieces inside AtBDynamicScenarioFactory, some just for readability improvements (so I could follow along easily while testing). There's a minor interaction with pending #4164 (improved bomb selection), in that the populateAeroBombs(...) method gets called towards the bottom of the generateForce(...) method, but the two are complete independent.

Side note: due to the fixed MUL loading issue from #4213 and using similar functionality, did additional checking specifically for fixed MUL affects.

All these changes allow roles (EDIT: these are the force generator roles, from .../docs/RAT Stuff/rat-generator.txt) to be passed down from the 'generated force' level to the individual random unit selection. This has two immediate effects: artillery, and infantry in hostile environments.

Previously, artillery was read from a flag in the scenario settings and passed down through multiple levels using a specific boolean method parameter. That parameter has been removed, and the scenario flag is now used to add the ARTILLERY role to the force selection.

Infantry for hostile environments is an entirely new feature. When certain hostile conditions are present, either the XCT or MARINE roles are automatically added to the force selection for infantry, limiting what types of infantry are generated. Because there are so few official units that fit these parameters, a fall-back position has been included - if no explicit hostile environment infantry is available, normal infantry is generated and the armor kit is swapped out for hostile environment suits. As a bonus, under less hostile conditions that are still deadly to unprotected infantry, normal infantry will have their infantry kit swapped out for something appropriate e.g. snow/heatsuits for temperature, light environmental suits for low atmosphere pressure. The role selection and armor kit changes are applied to base scenario forces and scenario modifier forces, including infantry that is loaded into transport bays of APCs.

This PR adds in hooks to to allow force generator role filters to be added to the scenario template and scenario modifier XMLs. Each force can have an optional roleChoices element with one or more forceRole elements, using the same role formatting as the force generator XMLs. A single forceRole element will always be used while multiple instances will result in random selection. As an example, the HostileFacility.XML scenario template might look like this:

<scenarioForces>
   ...
   <entry>
            <key>Primary Opfor</key>
            <value>
               ...
               <roleChoices>
                   <forceRole></forceRole>
                   <forceRole>urban</forceRole>
                   <forceRole>urban</forceRole>
               </roleChoices>
               ...
            </value> 
   </entry>
   ...
</scenarioForces>

Two thirds of the time the Primary OpFor force will generate using the URBAN role, while the rest will be normal generation without roles (current behavior).

Similarly, the AlliedReinforcments.XML might look like this:

<forceDefinition>
    ...
    <forceName>Allied Ground Reinforcements</forceName>
    ...
    <roleChoices>
        <forceRole></forceRole>
        <forceRole>fire_support</forceRole>
    </roleChoices>
    ...
</forceDefinition>

Each time the modifier is used, it randomly chooses between standard generation and fire support.

Using an empty forceRole entry will select with no roles, as does not including the block (which is current behavior).

Multiple roles can combined using commas and no spaces e.g. "support,cargo". The more roles that are combined the smaller the number to choose from, so use with caution. Roles may have restrictions that are incompatible with other force properties e.g. the RECON role should not be used on a force that may generate heavy or assault weight units. Naturally these role selection elements have no affect on fixed MUL unit selection, but should still be omitted for clarity.

@codecov-commenter
Copy link

codecov-commenter commented Jul 15, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 10.24%. Comparing base (c90c6d2) to head (742997e).
Report is 1 commits behind head on master.

Additional details and impacted files
@@             Coverage Diff              @@
##             master    #4418      +/-   ##
============================================
- Coverage     10.26%   10.24%   -0.02%     
+ Complexity     5809     5808       -1     
============================================
  Files           924      924              
  Lines        126223   126432     +209     
  Branches      18698    18769      +71     
============================================
+ Hits          12952    12953       +1     
- Misses       111996   112204     +208     
  Partials       1275     1275              

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

@SuperStucco
Copy link

Thanks for this. A quick scan shows the high points are all there, so it gets a stamp of approval here.

factionCode,
new ArrayList<Entity>(),
new ArrayList<String>(),
factionCode, new ArrayList<>(), new ArrayList<>(),
Copy link
Collaborator

Choose a reason for hiding this comment

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

Minor stylistic nit: if arguments are expanded into a vertical list, each should be on a separate line so that the eye does not skip over them (as I did here, briefly thinking the new ArrayList<>() args had gone missing).

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Ah, that's a 'My Bad'. I'll fix it in a sec :)

Copy link
Collaborator

@Sleet01 Sleet01 left a comment

Choose a reason for hiding this comment

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

LGTM!

@Sleet01 Sleet01 merged commit ceb3256 into MegaMek:master Jul 15, 2024
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants