bugfix(pathfinder): Improve initialization of uninitialized variable in Pathfinder::classifyFence

[Caball009]

• Follow up for https://github.com/TheSuperHackers/GeneralsGameCode/ pull/1748
  ( the link is broken on purpose so it doesn't link, because I may close this draft PR if it doesn't work out )

This PR makes a small change to the initialization of the previously uninitialized variable in Pathfinder::classifyFence. I saw 4 places where the game eventually calls Pathfinder::classifyFence for maps with fences:

• map start: GameLogic::startNewGame
• map end: GameLogic::processDestroyList
• fence is toppled by a unit that drives over it: ToppleUpdate::applyTopplingForce
• fence is destroyed by flames or explosions: GameLogic::processDestroyList

I noticed there's an initialization pattern that the game appears to follow for the most part. The uninitialized values tend to be either very large (> 100'000) or 0. GameLogic::processDestroyList runs directly after PartitionManager::update which zero initializes > 20K of memory on the stack, which sets the uninitialized variables that are used in Pathfinder::classifyFence to 0, and they usually stay 0.

I also noticed that the destruction of an object drawable can modify the values as well, which is why the zero initialization is disabled after the first destroyed object. Naturally, there's no way to come up with a complete fix due to the nature of the issue, but the new initialization does the fix the mismatches in these two replays:

1v1 (25.05.17) [rank] arctic arena zh v1 BoYcaH^(nuke) vs NGE_Killer(gla).rep
1v1 (25.09.20) [rank] snowy drought zh v5 SR_MaD(stealth) vs Majesta(laser).rep

fixed_replays.zip

I have four replays in total that mismatched because of the uninitialized variable; two are fixed with this change, and two continue to mismatch:

00-43-03_2v2_player_fh_abed_HardAI.rep
1v1 (25.11.28) [rank] farmlands of the fallen zh v1 SR_MaD^(sw) vs Penguin(gla).rep

mm_replays.zip

TODO:

• Use Zero Hour only macros.

[Mauller]

These comments are no longer valid with your new code, they were associated with the prior removed initialised values

[Caball009]

Which part of the comment would you say has become invalid with the new code?