ERROR: idRestoreGame::ReadSyncId: marker mismatch while reading ReadTrace at offset 696660 (got 0x00000034, expected 0x5934514f)

[y2keeth]

I know I have to fix my lwo models but did those cause this error? fixing them right now
openQ4 0.12.0

qconsole.log

[y2keeth]

fixed all those lwos
and got the same
ERROR: idRestoreGame::ReadSyncId: marker mismatch while reading ReadTrace at offset 696660 (got 0x00000034, expected 0x5934514f)

qconsole.log

[themuffinator]

Thanks for checking this twice — the fixed-model log gives us a useful answer: the LWO warnings did not cause this restore failure. Both logs reach the exact same ReadTrace marker mismatch at byte 696660, with the same unexpected value (0x34). The model warnings happen during media precache; this failure happens later while the game DLL is deserializing entity state.

The logs also show that this run is using the mod-owned module:

J:\gog\Quake 4\hidef2kbc72\game-sp_x64.dll (built Aug 18)

A sync marker is written immediately before each serialized trace. Reaching ordinary data (0x34) where that marker should be means the writer and reader stopped agreeing on the save layout somewhere earlier in the stream. Because preflight allowed restoration to begin, this is much more consistent with a save made by a different game-code/schema revision than with damaged bytes.

Could you try this one discriminating test without rebuilding or replacing that DLL in between?

1. Start a new game/map with the current Aug 18 DLL.
2. Make a new named save.
3. Load that new save immediately in the same run.

• If the new save loads, the older save is incompatible with the current custom GameLib build and will need to be recreated (or loaded with the exact DLL that wrote it).
• If the new save fails at ReadTrace too, we have a current writer/reader asymmetry to fix.

For the second case, please attach a zip containing the new slot's .save and .txt files, and share the exact openQ4-game commit/source tree used to build game-sp_x64.dll. Running once with developer 1 enabled would also expose the saved/current source fingerprints in the log.

I’m keeping this open as a bug/question until that same-build result is known. The custom AAS generateAllFaces parse warnings are separate as well; we can handle those independently after the restore path is settled.

[y2keeth]

the game-sp_x64.dll is the stock one 0.12.0 just had to put it in the mod folder for it to run use to work by just having +set fs_game_base baseoq4 in the bat file but does not work any more for some reason

[y2keeth]

anderson.zip

[y2keeth]

" The custom AAS generateAllFaces parse warnings are separate as well; we can handle those independently after the restore path is settled."
been wondering about those I did rebuild airdefense1

[y2keeth]

here is the map if that helps
airdefense1.zip

[themuffinator]

Thank you — the map archive helped. I inspected all five generated AAS files, and they confirm a separate openQ4 producer/consumer mismatch: our AAS writer emits generateAllFaces = 0, but the runtime parser recognizes only the neighboring generateTacticalFeatures key. That is why each file produces the three token warnings. I’ve split it into #137 so it can be fixed and tested independently.

This still does not cause the ReadTrace restore failure: the AAS files finish loading before the save stream reaches its exact four-byte schema displacement. I’ve now reproduced the save’s source fingerprint and identified that displacement as the swimSpeed field added after the attached v0.10 save was written. The compatibility decoder is in review in openQ4-game #7; I’m taking it through an actual windowed load test before calling it resolved.

[y2keeth]

ok cool, it was built from the stock q4 editor console if that matters

[y2keeth]

guess that explains some of the ai getting lost on my maps