[0.50.0-SNAPSHOT] Maxim (I) & potentially other large transports generate with vast amount of infantry beyond loading capacity

[Tzahr]

Environment

04:19:47,749 INFO [mekhq.MekHQ] {main}
mekhq.MekHQ.initializeLogging(MekHQ.java:303) - Starting MekHQ v0.50.0-SNAPSHOT
Build Date: 2024-07-27T01:16:03.359732465
Today: 2024-08-01
Origin Project: MekHQ
Java Vendor: Eclipse Adoptium
Java Version: 21.0.3
Platform: Windows 11 10.0 (amd64)
System Locale: en_GB
Total memory available to MekHQ: 4 GB
MM Code Revision: e86f08fde087d229498e46e9697a41466897653e
MML Code Revision: bea7884b61319d3b2c803a0fa65988008638e6ef
MHQ Code Revision: 12c84d7

EDIT: This issue initially described multiple, different bugs. I have left everything originally reported intact, but the main error under investigation here currently is the second one described, referring to the generation of large amounts of infantry and BA. I will open new issues for the others as they occur in the new release. Everything that follows is unaltered.

Description

Attached is a campaign including a contract scenario that has two (2) tank bases and one (1) artillery base. Regenerating bot forces on that scenario will commonly cause:

• Very consistent: certain forces associated with special modifiers (like artillery and tank bases) generate twice. This pretty consistently leaves this scenario to generate 2x artillery OPFOR and 3x Tank Reinforcement OPFOR on top of Primary OPFOR.
  

• Uncommon: causes Tank Reinforcement OPFOR to generate very large numbers of infantry and Battle Armour. This also occurs randomly on normal generation (e.g. in the wild), the most extreme case generated 400+ units of infantry and BA.
  

• Rarely: generates forces without any units, leaving only Primary OPFOR populated.
  

This has occurred repeatedly. I started encountering the anomalous infantry / BA generation in the wild, causing me to frequently regenerate bot forces, which lead me to observe the first and third anomalies.

Files

mekhq.log
TestScenarioSave.zip
custom mechfiles.zip

[Tzahr]

This is a naturally generating Primary OPFOR for me on a scouting encounter:

The vast majority of these units are infantry or BA.

[IllianiCBT]

How frequent is this issue? Trying to get a sense of scope.

[Tzahr]

The naturally occuring infantry horde happens quite frequently. A very rough guess would be 15-20% frequency on ground contracts. I literally observed it happening moments ago in the wild doing scouting on the same save.

[IllianiCBT]

Just with Wobbies, or any faction?

[Tzahr]

I have encountered it most frequently with the Wobbles, but also with other factions. I dug into the campaign records and found this one too:

[Sleet01]

May be an instance of #2792, which was never resolved.

[Tzahr]

I decided to load into the lobby with one of the lesser offenders of the infantry horde issue, and noted this:

I wonder if it is relevant; #2792 refers to excessive Mech forces, while I am only experiencing this specifically with infantry and BA. A theory might be that it is attempting to generate a full load for the transports, but failing to satisfy this for whatever reason, causing it to potentially continuously generate additional forces to transport.

[Tzahr]

Investigated this further on a second incidence.
I can confirm that it tried to load the overwhelming majority of the units into a single Maxim (I) Heavy Hover Transport a second time. Suspect at this time that this is a bug with how Princess generates and assigns units to troop carriers like the Maxim (I).

EDIT: this also explains why this was a very common issue with Tank Reinforcements since I suspect that has a higher incidence rate of generating transports capable of causing this bug to manifest. I will try to monitor to see if I encounter any unbugged Maxims (I), because if it reliably does this with every Maxim (I) it generates, we have a vector.

[Tzahr]

Encountered the bug again, this time mission generated x2 Maxim (I).
Upon loading into the lobby, the game froze for about a minute while loading OPFOR, and then displayed errors for being unable to load a ream of BA and infantry into both Maxims seperately.

At this stage, I am 99% convinced this is a bug with the Maxim (I) specifically.

[repligator]

After smashing out some breakpoints, it looks like the issue is with mekhq/campaign/mission/AtBDynamicScenarioFactory.java , specifically the portion beginning with line 736.
// Units with infantry bays get conventional infantry or battle armor added
After passing through this, the Primary OpFor (18 tanks and/or APC's, including several Maxim I's) became 18 APC's and/or tanks and 369 units of infantry or BA. On the same scenario, Enemy Tank Reinforcements (6 tanks and/or APC's, once again including a Maxim I), received 854 additional units of infantry and BA.

mekhq.log
so_many_blakists_1st Rimward Hussars30690117.cpnx.gz

[Sleet01]

After smashing out some breakpoints, it looks like the issue is with mekhq/campaign/mission/AtBDynamicScenarioFactory.java , specifically the portion beginning with line 736. // Units with infantry bays get conventional infantry or battle armor added After passing through this, the Primary OpFor (18 tanks and/or APC's, including several Maxim I's) became 18 APC's and/or tanks and 369 units of infantry or BA. On the same scenario, Enemy Tank Reinforcements (6 tanks and/or APC's, once again including a Maxim I), received 854 additional units of infantry and BA.

mekhq.log so_many_blakists_1st Rimward Hussars30690117.cpnx.gz

Whoa, good job tracking that down!

[SuperStucco]

The Maxim (I) is one of the few 'large' APC type units, capable of carrying multiple platoons of most types of infantry. When transports are assigned infantry in MekHQ it runs on a loop to generate infantry until there isn't any room; there may be some problems with actually associating those extra infantry with the carriers, so it will loop over and over generating infantry without an exit.

With the build scripts in flux and pending updated documentation, and the OIF stuff, I'm in a bit of a holding pattern as I don't want to be fighting a bunch of structural stuff that I don't understand on top of working out the code problems. Hopefully things will be smoothed out once 50.0 goes online, if not before. If it hasn't been looked at by then, I'll see what I can do.

[Sleet01]

#4601 is definitely the same issue. Closing that as a dupe.

[Tzahr]

As this report actually reports two issues:

• The Maxim (I) transport capacity bug
• Duplication of forces on contract regeneration

I'm going to refocus this one about just the transport error, and open a new issue for the force duplication on regeneration bug.