Repository navigation
Fix CS2 14197 ReplyConnection sig and net message handle usage - #86
xiaoyueyoqwq wants to merge 1 commit into
Conversation
- Extend the Linux ReplyConnection signature; on build 2000943 the compiler swapped its first two movs and the short pattern now matches two functions - Net message handles are now plain NetMessageInfo_t records with no vtable, and INetworkMessages::FindNetworkMessagePartial moved from slot 14 to 10, so look it up through the raw vtable and allocate via the record's function pointer until the SDK headers catch up - Hook_SendNetMessage reads the id with CNetMessage::GetMessageId(), whose vtable is unchanged Co-authored-by: jakejarrett <5661105+jakejarrett@users.noreply.github.com>
f28edf6 to
a603897
Compare
|
Live verification results on CS2 1.41.9.7 / build 2000943 (Linux dedicated, Metamod 2.0 git1483, SteamRT sniper runtime). End-to-end addon flow — all greenSwitched to workshop map
Signature uniqueness check on the actual binaryScanned the server's Worth noting: the published v1.7.3 release binary was built at The runtime side is the load-critical half: with only the signature fixed, the plugin loads but crashes on the first client message ( |
|
Understood on the close — for anyone landing here: rebuilding MAM against s2sdk This branch still works as a stopgap — the build above was verified end-to-end on 2000943 (workshop map switch, addon push, real client join, zero crashes) — for anyone who needs a working binary before an official rebuild ships. One small request for future contributions: a one-line rationale when closing a PR helps contributors understand the direction. Happy to help test the official build when it lands. |
Summary
Fixes #84 — MultiAddonManager fails to load on CS2 1.41.9.7 / build 2000943 (
Failed to lookup the signature for ReplyConnection), and would crash on the first client message even once it loaded.ReplyConnectionsignature extended. On 2000943 the compiler swapped the function's first two movs (55 41 B8 … B9 … 48 89 E5 41 57 41 56 48 8D 95); the shorter existing pattern now matches two functions so lookup fails.Hook_SendNetMessageno longer touches the message handle. 14197 turnedINetworkMessageInternalhandles into plainNetMessageInfo_trecords with no vtable, soGetNetMessageInfo()was a virtual call through a name string.CNetMessage's own vtable is unchanged, sopData->GetMessageId()is used directly.GetAddonSignonStateMessageworks around the SDK's stale declarations.INetworkMessages::FindNetworkMessagePartialmoved from slot 14 to slot 10 and the returned record is allocated via itsm_pfnAllocatefield at +0x8. The helper reaches both through the raw vtable/record until the SDK headers catch up (s2sdk#124 pending upstream).Analysis largely from @jakejarrett's notes in #84, verified against s2sdk#124.
Test plan
meta listshowsMultiAddonManager (v1.7.3-7fc2d6f)loaded,[MultiAddonManager] Plugin loaded successfully!,Refreshing addons,Logged on to SteamHook_SendNetMessagepath exercised continuously (SourceTV/HLTV client receiving messages), no crashhost_workshop_map 3789922008→HostStateRequest ... addons(3789922008)→Mounting addon→ SignonState messages sent → real client connected withS2C_CONNECTION [addons:'3789922008']and validated — no crashGenerated with Devin