You said:
ChatGPT said:
I’ll inspect the executable and PDB for movement-related symbols, identify the stair-speed calculation, patch the smallest possible instruction sequence, and verify the modified PE still parses cleanly.
The PDB is intact and contains private symbol names such as MaxPlayerSpeed, movement vectors, ground-hit helpers, and the original source-object paths. I’m narrowing this to the player movement routine rather than applying a broad speed constant change.
You said:
ChatGPT said:
That hypothesis is more likely: the bug could be a velocity vector whose horizontal component stays at full walking speed while an independent vertical component is added during step-up, producing a total magnitude near √2. I’ll test for that pattern specifically—normalization/clamping after the vertical adjustment—rather than looking for a stair-only multiplier.
The symbols confirm the split: get_movement_vector and update_player_control generate a planar request, while walk_manifold_move_by_internal maps that request onto walkable geometry. The likely fix point is therefore the manifold traversal’s “distance consumed” accounting, not the input-speed constant.
The player routine confirms the mechanism exactly: it requests an XY displacement, the manifold supplies the new Z, and later code deliberately measures only the flattened XY delta. I’m implementing a localized hook at that one player-movement call: after the normal manifold query, it rescales and re-queries only when the resulting 3D displacement exceeds the requested planar distance.
Your diagnosis was right. The game requests a horizontal displacement, the walking-manifold code adds the corresponding vertical displacement, and subsequent movement accounting ignores that vertical component. On a 45° incline, the resulting 3D displacement approaches √2 times the intended speed.
I patched the player movement call so that when traversal adds vertical movement, it rescales the horizontal request and repeats the manifold calculation. Flat-ground movement is unchanged; collision-limited movement is excluded from the correction.
Patched executable SHA-256:
76f5740e77027ae92317f4a3b01f23b1c5dbaafbcdabf46a7e231b7b571a857d
The patcher verifies that the source executable has SHA-256:
0d582f75aca9ee30d09c9a78ba73cdc19eb99b29c8b36b9fcf3b82fa318a42f6
Back up the original and place the patched executable beside the game files under the expected executable name. I validated the PE structure, unwind metadata, branch targets, and emulated flat, uphill, and downhill movement. I could not perform an actual in-game launch from this Linux environment, so runtime behavior still needs testing in the game.
You said:
ChatGPT said:
The first patch was too invasive. It added an eighth PE section and increased the executable by 512 bytes; the game appears to reject that structural change while initializing its assets, before the movement hook can run.
I rebuilt it as an in-place, same-size patch:
-
File size remains exactly
6,854,656bytes. -
Section count remains
7. -
SizeOfImageremains unchanged. -
The original zero PE checksum remains unchanged.
-
The hook occupies unused padding inside an existing section.
Discard the earlier patched executable, restore the original, then replace it with this version under the original filename:
Corrected executable SHA-256:
687d8be72390952b70b8406decaa79710b2cc54427fcdf2aaaf05658cba45c77
I still cannot launch the complete game here, so this removes the identified PE-layout problem but needs an actual startup test. If this version produces the same asset error, that would indicate a whole-file integrity check rather than sensitivity to the added section.
You said:
ChatGPT said:
I found the guard in app_init:
RVA 0x0006723B load critical-asset sentinel RVA 0x00067246 compare sentinel with 0 RVA 0x00067249 JE fatal_error_data_corruption
The jump leads directly to the block that passes fatal_error_data_corruption to os_fatal_error. I replaced that six-byte conditional jump with six NOPs and combined it with the constant-speed movement patch.
Executable SHA-256:
3998a371957bbc7c6dd50da2b3855bd3cfe890d2582fc435df8c153c96634275
The executable remains the original size, with seven sections and the original SizeOfImage. Restore the original executable first, then place this version under the game’s expected executable filename.
This suppresses the fatal dialog, but if the sentinel indicates a genuine asset-loading failure rather than merely an integrity mismatch, execution may fail later. I still cannot perform the Windows launch test in this environment.