Skip to content

Reimplement the immediate synchronization hash command - #222

Open
Krarilotus wants to merge 1 commit into
sourcehold:mainfrom
Krarilotus:feat/sync-check-command
Open

Reimplement the immediate synchronization hash command#222
Krarilotus wants to merge 1 commit into
sourcehold:mainfrom
Krarilotus:feat/sync-check-command

Conversation

@Krarilotus

@Krarilotus Krarilotus commented Sep 6, 2026

Copy link
Copy Markdown
Contributor

Reimplements the message that players use to exchange their synchronization hash, lag and match time. Sending reads the local player's values; receiving updates the resolved sender's values so the game's existing synchronization checks can use them.

CommandCheckSync at SHC 0x480B10 declares a ten-byte immediate command and uses the fixed parameter buffer. Preserve the native field order (2-byte lag, 4-byte hash, 4-byte match time), actor selection, and the size/timestamp-only behavior during received scheduling or unknown phases. This PR adds one readable C++03 implementation using the existing resolvers.

Validation:

  • The normal full OpenSHC.dll CMake build now passes with MSVC 2005 SP1 and a Microsoft-signed Windows SDK manifest tool. This resolves the earlier bundled mt.exe crash; the DLL has its embedded manifest and no deployment was performed.
  • All 203 function bytes match the original SHC body after binding resolver references to native addresses. Mapping Extreme's two player-field offsets and native addresses also gives a 203-byte match against its original body.
  • 1,280 native serializer/phase/player/ring/cursor cases per variant pass, including stack and nonvolatile registers. Only the low-level memory-copy body is a stand-in; the command and serializer use native instructions. Supplementary investigation tooling remains local.
  • Linked reccmp reports 75.47%, with unmatched global/serializer resolver identities. The normalized byte comparison above is distinct from that linked score; this is not a claim that the whole DLL is byte-identical.

This does not implement hash generation, resynchronization, Steam transport or multiplayer replay. The implementation was checked against the existing Ghidra database and original executables while investigating immediate-message capture in the recorder. Based on current upstream main; generated headers and resolver activation flags are unchanged.

@Krarilotus

Copy link
Copy Markdown
Contributor Author

The build limitation is resolved: the normal full OpenSHC.dll target now passes using the existing MSVC2005 SP1 compiler and a Microsoft-signed Windows SDK manifest tool. All 2,560 original serializer/command cases still pass; the C++ commit is unchanged and no DLL was deployed. The description now reflects the successful full build.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant