Track additional characteristics in Scenario

[AaronGullickson]

This PR refactors some features out of AtBScenario into Scenario and adds some additional features to Scenario. This PR is tied to the Story Arc PR #2997, and should allow creators to create pre-made scenarios for story arcs. However, it is generalizable enough that it could have other potential uses as well.

Current State

I believe this PR is ready for review. I am going to look and see what I can clean up based on the automated reports, but feel free to give feedback at this point.

Refactoring

The following variables and related methods were re-factored out of AtBScenario to Scenario:

1. botForces and botForcesStubs. This allows basic scenarios to include pre-loaded OpFor and Allied units. I also borrowed code from AtBGameThread and inserted it into GameThread so that these botForces are actually loaded. At a basic level, this feature can include a fixed set of entities listed in the BotForce object, but I also added an additional class described below that can do randomization of botForces. There is another variable in AtBScenario for allies (alliesPlayer) but I did not refactor this variable because allies can be created in BotForce simply enough by assigning them to team 1 (always the player's team).
2. Map generation variables, specifically terrainType, mapSizeX, mapSizeY, map, and usingFixedMap. These function identically as they did in AtBScenario.
3. PlanetaryConditions variables. I also added additional variables for temperature, electro-magnetic variables, and blowing sand. These variables are not currently used by AtBScenario but could be added.
4. The start variable that gives the starting deployment position of the player's units.

I don't believe any of these changes will affect AtB functioning at all because AtBScenario inherits from Scenario and I made sure to keep methods the same. I did have to give some of the variables protected rather than private access because the initialize method in AtBScenario assigns some of these variables directly.

I also did not need to do anything to ScenarioObjectives. These were already a part of the basic Scenario object and they can be used more or less directly, although I did need to make a few changes to make sure they were checked for in basic scenarios and not just AtB games.

GUI changes

I made a variety of changes to ScenarioViewPanel so that all of these new features in scenario will actually show up to the player. I borrowed quite a bit from AtBScenarioViewPanel but ScenarioViewPanel involves no dynamic buttons just information. I also did a lot of cleanup on the code there to make it more compact and produce a more pleasing display. Here is an example of the new look:

New Features

BotForceRandomizer

I wanted people to be able to create randomized BotForces as well as fixed ones. I also wanted these to be able to scaled to variable player deployments. I originally thought I could just use or rework the code from ScenarioForceTemplate and AtBDynamicScenarioFactory. However the logic of these objects is quite complex and difficult to separate from the expectations of AtB game play.

So, instead, I created a new class called BotForceRandomizer that can be added to a BotForce as a variable. It is a lightweight object that just tracks some parameters for random generation such as faction, quality, unit type, and skill level. The code for generating units borrows substantially from code in AtBDynamicScenarioFactory but is much, much simpler. Part of the reason for this is that, players/creators can mix fixed unit lists and random forces in BotForces. So rather than try to consider all the very specific cases that AtB needs to consider like artillery, aeros with bombs, dropship support, etc., this class is set up so that creators can specify special stuff like that in fixed units and then just roll for the remaining units.

I currently have two scaling techniques which are specified in a private enum. The first is just BV. The second is an "adjusted weight" scaling. This is basically just the total weight of units, but those weights are "weighted" by unit type. So tank weight only counts for 60% of mech weight and so forth. This is loosely based on some old point based systems used in Battletech products. The idea is that this balances forces based on rough unit type and weight parity but does not adjust for skill level, tech level, etc. Right now the unit type weights used are hard coded but this could be made user editable in the future. It should also be easy based on the way I have this set up to add other scaling methods in the future.

Right now the generator works pretty decently, but there is definitely room for improvement. My initial goal here is just to get the architecture set up and then tinker with the details later based on how it plays.

ScenarioDeploymentLimit

This feature enables limits on what units the player can deploy to a scenario. All of the parameters for this leave in the ScenarioDeploymentLimit class and an instance of this class can optionally be added to Scenario. If it is not present, then limits are not enforced. Limits are enforced in the following way.

• allowedUnitTypes - This List defines what unit types can be deployed to the scenario. If it is empty, then all unit types are accepted.
• quantityLimit. This variable places a maximum value on units that can be deployed. That maximum limit is flexible depending on the value of QuantityType and CountType enums in ScenarioDeploymentLimit. QuantityType can be PERCENT or ABSOLUTE. If PERCENT is used then quantityLimit is treated as a percent of the player's valid forces for the scenario. So you could set the limit to be 50% of the player's forces for example. What exactly quantityLimit measures can be changed by CountType which can be BV or UNIT. If BV, then quantity limits are based on BV. If UNIT then the limit is number of units. So, quantityLimit=50, QuantityType=PERCENT, and CountType=UNIT would allow the player to field half of their eligible units to the scenario.
• requiredPersonnel - this can be used to require certain personnel in the scenario by their UUID
• requiredUnits - just like requiredPersonnel but for units

Most of these limits are enforced by the canDeployForces and canDeployUnits methods in Scenario, which I refactored from AtBScenario. The methods in AtBScenario are unchanged and just override the super methods. I also added a new Scenario#canStartScenario method that is checked in the GUI to see if all of the scenario buttons should be enabled, which helped to clean up some real messy code. Again AtBScenario has an override method for this that adds one additional condition.

[Windchild292]

In general this looks good. However, there's a bunch of comments with changes of varying severity, with the largest and most significant being issues in MekHqXmlUtil usage and File I/O in general. Outside of that the comments are largely related to missing brackets, spacing, other text accessibility, and some light code enhancements.

Also, there's a lot of places in BotForceRandomizer and ScenarioDeploymentLimit that could be converted to use streams to improve their readability, but that's just a personal opinion.

[AaronGullickson]

Thanks for the very detailed review @Windchild292. I have made all of the requested changes except the two cases of modernizing the XML file I/O. Can you tell me a class that is fully modernized so I can use it as an example?

[AaronGullickson]

Thanks for the very detailed review @Windchild292. I have made all of the requested changes except the two cases of modernizing the XML file I/O. Can you tell me a class that is fully modernized so I can use it as an example?

Never mind I think I fixed this in the latest commit.

[Windchild292]

Just a few remaining spacing/brackets issues, then this will be good to merge

[Windchild292]

I just realized these are enums being parsed through their ordinals instead of names...

I've added a note to fix this, as it can cause migration issues, and to move the file I/O for behaviour settings to that file.

(Nothing to do, just commenting on something I noticed and how I'm planning on fixing it)

[Windchild292]

I'd normally suggest using the new array writing methods instead of this.

However, this is a magic number we'll need to convert to an enum... and this method is so much easier to convert. Just a comment for future implementations, please don't do it here.

[AaronGullickson]

Ok @Windchild292. Think I got all of them.

[Windchild292]

Approved pending CI (just for safety)