darkpanda
Dark Prince
- Joined
- Oct 28, 2007
- Messages
- 829
OK, Let's suppose you are right How to fix this ? I tried setting ax to FFFF but then it seemed the program ended up outside of it's normal instructions, though I could be wrong.
How does your tool solve it ? I would assume setting AX or some pointer to 0/nil but perhaps FFFF is used as a nil indicator.
JCivED works with gamesave files (.SVE and .MAP), that do contain the "nextUnit" values.
For detection the source is available here: https://sourceforge.net/p/jcived/co...dd/civ/logic/validation/IntegrityChecker.java
It basically verifies integrity between a unit's "nextUnit" value, and the data of the designated "nextUnit": does "nextUnit" exist (=not destroyed=unit type not 0xFF) ? Is "nextUnit" really on same square (compare x and y) ? If more than 1 unit on a square, do they properly reference each other or one of them has "nextUnit" pointing to "null" (0xFF) ?
I realize the current code does not take into account your specific case: unit.nextUnit == unit... Maybe needs an update
The fixing itself is contained in another file (legacy code being slowly moved around): https://sourceforge.net/p/jcived/co...dev/src/dd/jcived/edition/GameSaveEditor.java
This code simply takes all detections output from the previous code, then recomputes the unit stacks pointers properly by checking square contents, units' positions and existence.
By collecting multiple save games right before this bug happens it might become possible to find the location in the computer program where this happens.
It would work by setting a watch on the next pointer and checking if the value becomes the same as the original/entity itself.
Then loading each save games, playing a couple of turns, and then hoping the watchpoint/databreakpoint condition gets triggered.
Data breakpoint:
Unit.Next = Unit
Or perhaps some more complex breakpoint, checking different locations, but mostly the same idea.
Then maybe an executable patch could be created to fix civ1.exe so that this never happens again ! =D That be great/awesome ! =D
Creating patches is among my hobbies
However, I suspect unit stack errors happen in many various cases.
In fact CIV.EXE contains several bugs, of varying occurences and amplitudes... So it may not be just one place to fix this...
As for detection, it seems especially tricky, because the stack data corruption may occur well before the acutal hanging, and since you can have up to 128 units per civ (8 civs max), that makes A LOT of places to monitor for "nextUnit" values.
Indirect efforts at the moment are more in the way of rebuilding a perfect clone, "including bugs" , by meticulously reversing CIV.EXE. But it is a very long path...