[GEN][ZH] Initialize supplyTruck variable

[helmutbuhler]

• Follow up for [GEN][ZH] Fix uninitialized supplyTruck variable in AiPlayer::onUnitProduced() #653

So I did a bunch of automated testing with about 1400 replays (that's about 20 days of combined gametime). All these replays

• did not mismatch when they were originally played (that is stored in the replay)
• have at least 2 human players
• have at least one AI player
• were played on a compatible 1.04 or 1.05 retail version

I checked to leave the supplyTruck variable uninitialized and initialized to true. The end result was that not a single replay mismatched with it initialized to true. (I already confirmed that initializing to false causes mismatches, so I didn't check that again)

So I suggest to initialize it. Why?

• I already confirmed that enabling some logging in StateMachine::internalGetState will cause mismatches when the variable is left uninitialized. (See [GEN][ZH] Fix Mismatch in Release Build when Logging is enabled #759)
• Some future changes in very different areas can cause mismatches in the future
• Even in the current version, leaving it uninitialized can potentially cause mismatches when two peers happen to have different stack memory there (that's quite difficult to check though)

I realize that some tests were already made where it was concluded to leave it uninitialized. But those tests were made on a version that added some logging in the function with the uninitialized variable. That likely skewed the results. I also asked for replays that were used in those tests, but have received none so far.

If there is demand I can upload the replays I tested with. I will also hopefully be able to make a PR with the automated testing code soon.

I can also conditionally initialize the variable to false on newer compilers, if that would be more logical (I haven't studied the code that uses that variable much).

[Mauller]

Based on the subsequent code that the uninitialised variable was hitting, the correct initialisation value should be false.

If we think it is better to initialise this to true then set the VC6 specific variable to initialise to true, this way we maintain the correct behaviour when removing VC6 support.

[xezon]

Can we figure out what user facing behaviour is changing when it is set to false?

[Mauller]

It's code specific to construction vehicles that aren't also supplytrucks.

if (!supplyTruck && unit->isKindOf(KINDOF_DOZER)) {
	if (m_dozerQueuedForRepair) {
		m_repairDozer = unit->getID();
		m_dozerQueuedForRepair =false;
	} else {
		m_buildDelay = 0;
		m_structureTimer = 1;
	}
}

Essentially dozers will always be treated as though they are also supply trucks and not have variables relevant to them being set properly.

[helmutbuhler]

Fair enough. I just changed it as requested.

[xezon]

It's code specific to construction vehicles that aren't also supplytrucks.

Can you please figure out what changes user facing? Does it fix a bug?

[xezon]

Could we verify this observation with AI match?

[Mauller]

We should be able to spot it if we play against a large map with all other slots filled with AI.

In theory the playback should show:

• With the value set to false: Dozers should not idle after being constructed and should go about building something.
• With the value set to true: Dozers may idle for a random period before constructing something.

[roossienb]

So in essence the outward effect would be that a newly constructed dozer would not immediately go about constructing a new building as was originaly intended for the AI to do. And instead it could idle for an random period till the build delay timers ran down.

Based on my earlier logging, the delay would be between 0 and 60. I presume those are frames, so up to roughly two second delay for building anything.

[xezon]

2 seconds is not much :D

[DayV-git]

I can create an AI to test this but I'm not exactly sure what conditions should be generated. m_buildDelay is set to 0 in many cases, including when AI queue buildings for construction (in buildSpecificAIBuilding).

[xezon]

Very nice investigation. Reads plausible to me that changing the stack would introduce mismatches with that uninitialized variable.

[aliendroid1]

I also checked the crc codes that are generated for each object with supply truck initialized and uninitialized and could not find any difference on both vs6 and vs22

[xezon]

I think this change needs test in multiplayer with AI, because this is where originally the incompatibility was reported.

[roossienb]

I think this change needs test in multiplayer with AI, because this is where originally the incompatibility was reported.

iirc specifically when one uses a SH client and the other 1.04, while playing against multiple AI opponents.

[roossienb]

I think this change needs test in multiplayer with AI, because this is where originally the incompatibility was reported.

I'll ask the QA team

[sorcerer86pt]

Testing Report

Procedure:

• Used 6 person map
• 2 Human players
• 4 AI players (Medium difficulty)
• 1 used vanilla exe, other used this one
• one game has created with this fixed exe, the other 2 was with vanilla

Results:

• 1st Test, 2 Human USA vs 4 GLA AI Players, Vanilla Host: No Mismatch
• 2nd Test, 2 Human China vs 4 China, Vanilla Host: No Mismatch
• 3rd Test, 2 Human GLA vs 4 USA, Fixed Exe as Host: No Mismatch

Proof:

• Zip with all 3 replays: Replays.zip
• Discord thread: https://discord.com/channels/951133504605917224/1370785137435869296

[xezon]

Looks good.