[GEN][ZH] Initialize supplyTruck variable #820
Conversation
…n logging is enabled
| Bool supplyTruck = false; | ||
| #endif | ||
| // TheSuperHackers @fix helmutbuhler 05/05/2025 Fixes uninitialized variable. | ||
| Bool supplyTruck = true; | ||
|
|
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Can we figure out what user facing behaviour is changing when it is set to false?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Fair enough. I just changed it as requested.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
So yeah in essence setting the supplyTruck value to false for non VC6 fixes a bug.
There was a problem hiding this comment.
Could we verify this observation with AI match?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
Very nice investigation. Reads plausible to me that changing the stack would introduce mismatches with that uninitialized variable. |
xezon
added
Major
|
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 |
| @@ -1041,14 +1041,11 @@ Bool AIPlayer::isLocationSafe(const Coord3D *pos, const ThingTemplate *tthing ) | |||
| void AIPlayer::onUnitProduced( Object *factory, Object *unit ) | |||
| { | |||
| Bool found = false; | |||
| // TheSuperHackers @fix Mauller 26/04/2025 Fixes uninitialized variable. | |||
| // To keep retail compatibility this needs to remain uninitialized in VS6 builds. | |||
There was a problem hiding this comment.
I suggest leave the original comments and reword them instead.
There was a problem hiding this comment.
Can you do that? I'm not sure what you want.
| #else | ||
| Bool supplyTruck = false; | ||
| #endif | ||
|
|
iirc specifically when one uses a SH client and the other 1.04, while playing against multiple AI opponents. |
I'll ask the QA team |
So I did a bunch of automated testing with about 1400 replays (that's about 20 days of combined gametime). All these replays
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 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).