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

[themuffinator]

Thanks again for providing both the save and the map — the investigation is complete, and the compatibility repair is now merged.

The attached save is structurally valid; this was not save corruption and the LWO warnings were unrelated. Reconstructing the exact source fingerprint exposed three historical layout differences:

• an optimized MSVC build omitted the otherwise-empty idPhysics class frame because identical-code folding made two save functions share an address;
• the save predates idPhysics_Player::swimSpeed; and
• it also predates idPlayer::nextLiquidSurfaceSoundTime.

The repair uses declaration ownership instead of function-address comparisons for new saves, plus a narrowly fingerprinted decoder for this historical v3 layout. It was implemented in openQ4-game #7, carried onto the current modernization line by openQ4-game #8, and pinned/documented by openQ4 #139.

I reran your exact save in a windowed integrated build. It now passes the missing-physics frame, both historical fields, and the original ReadTrace failure. It continues until a later HiDef GUI-layout mismatch involving mon4.gui, which is expected with the supplied archive because it contains the save/map but not the complete matching HiDef GUI and asset set. A fresh stock save/reload also passed in active gameplay.

Could you please retest with the latest main build/package and your complete HiDef installation? Please remove the copied game-sp_x64.dll from the mod directory first. I also tested fs_game_base: current main correctly falls back to baseoq4/game-sp_x64.dll when the mod has a valid, complete mod.json. If fallback still fails for you, attach the fresh openq4.log and your mod.json, and I’ll trace that exact setup.

The generateAllFaces = 0 AAS warnings were fixed separately in #137 / #138. That parser fix removes the warnings, but it does not by itself prove that an AI navigation/connectivity problem is fixed; if AI still gets lost after rebuilding and testing the map, please open a focused issue with the map area and observed route so we can investigate it cleanly.

I’ll keep this issue open for your confirmation.

[y2keeth]

crashed but maybe this md5 model listed it used the baseoq4/game-sp_x64.dll thoqconsole.log

[y2keeth]

replace that md5 model with the stock ones so new crash while playing the intro cinematic

qconsole.log

[y2keeth]

got it to load