Game compatibility reports (tested & working)

[Hackerprod]

Any game you've tried against SKYNET — post your results here, working or not. Template per entry:

• Game / AppID:
• Revision tested (optional — commit, release tag, or just "latest" / date if you're not sure):
• Mode: Local / Dedicated server / both
• Result: works / partial / broken
• Notes: flows tested, issues found, workarounds

Doesn't matter if it's Dota 2, another Source/GoldSrc title, or something else entirely — any AppID you've exercised is useful data.

[micro-chief]

Game / AppID: Left 4 Dead / 500
Revision tested: latest local build + local unpushed fixes
Mode: Local / co-op
Result: works, with an intermittent stability issue
Notes: Tested yesterday with two players. Lobby/joining and normal co-op gameplay worked well, and we were able to play through multiple missions. However, after several missions the game would occasionally crash without any obvious warning or preceding failure. We haven't isolated the cause yet.

[micro-chief]

Game / AppID: Dota 2 / 570
Revision tested: latest local build + local unpushed lobby fixes
Mode: Local / Dedicated server
Result: partial / currently blocked during match connection
Notes: Tested with two players. We fixed the lobby flow locally and were able to get both clients into the lobby/room successfully. The next stage failed when connecting to the match: the host was able to enter, but the second client failed to connect. On that machine, the client appeared to ignore the -insecure launch option while SDR Certificates were enabled. We stopped the test at that point, so this still needs more investigation. The Dota lobby fix is currently local and has not been pushed to my fork yet.

[micro-chief]

Small update on Dota 2 / AppID 570:
I continued testing the dedicated-server connection path with two clients.
The lobby/team-slot flow itself is now working correctly. Both players can join the same lobby and choose their slots.
The current blocker appears later, during the actual game-server connection.
What I found:

• localhost connections are stable;
• remote connections to either the host/listen server or dedicated server fail;
• Dota shows:
  “Valve Anti-Cheat was unable to verify that your machine is secure. Failure to fix this may result in the inability to play online.”
• the server/client are already being launched with -insecure;
• SDR/P2P setup still progresses far enough to exchange certificates/ICE information;
• the remote player is eventually marked disconnected while the local player remains connected.
  So at this point I am not sure whether this is:
• missing LAN/server metadata;
• trusted/insecure session-state mismatch;
• a missing GameServer policy response;
• or some Dota-specific requirement for non-local connections.
  I am currently checking whether Dota expects an explicit LAN flag / local-server state in addition to -insecure.
  If anyone knows which Steam/GameServer state Dota uses to distinguish a local insecure server from a normal online/VAC-secured server, that would be very helpful.

[micro-chief]

Small follow-up on Dota 2 / AppID 570:
I made some progress on the dedicated-server connection issue.
I tested both the client and dedicated server with sv_lan 1.
This changes the behavior quite a lot:

• the VAC / “machine is not secure” popup no longer appears;
• the client now actually starts the game-server connection automatically;
• the dedicated server receives the SteamNetworkingSockets connection and the normal S2C_CHALLENGE -> C2S_CONNECT flow begins;
• the correct client SteamID is seen by the server.
  The current failure is now much more specific.
  The client first tries the public address and gets:
  NETWORK_DISCONNECT_REJECT_LANRESTRICT
  When including 192.168.x.x / 127.0.0.1, where the connection reaches CNetworkGameServerBase::ConnectClient, but the server rejects it with:
  NETWORK_DISCONNECT_REJECT_NOLOBBY
  So at this point the problem no longer looks like basic connectivity, SDR transport, or the client failing to initiate a connection.
  The dedicated server is already connected to the GC and receives the lobby SO cache, so I am now looking at the server-side lobby/session association and what exact lobby/member state Dota expects before admitting the player.
  This also suggests that the earlier VAC/trust popup was tied to the non-LAN / online connection path rather than the dedicated server itself being unreachable.
  Current status:
• lobby flow: working
• dedicated server startup/registration: working
• GC assignment: working
• automatic client connection: working with sv_lan 1
• server admission: blocked by NETWORK_DISCONNECT_REJECT_NOLOBBY
  If anyone knows which Dota lobby/session fields are checked internally when returning NETWORK_DISCONNECT_REJECT_NOLOBBY, that would be very useful.

[Hackerprod]

Pushed a fix: d97bd06 (fix(gc): subscribe dedicated server before broadcasting lobby update).

What was wrong

In SKYNET server/GC/570/modules/Lobby.ts, attachServer() (the function that associates a dedicated server with a lobby) was doing this, in order:

1. broadcastLobby(ctx, lobby, 0n, true) - sends an incremental update to the dedicated server's SO cache.
2. sendTo(ctx, lobby.serverSteamId, Msg.SOCacheSubscribed, ...) - sends the full subscribe for that same cache.

That's backwards. A SO cache client (which is what the dedicated server is, on its own GC session) can't meaningfully apply an update to an object it hasn't subscribed to yet - subscribe has to come first, since it's what establishes the object in the first place.

My hypothesis: this ordering bug is why the dedicated server's own internal lobby-membership state ends up incomplete/inconsistent, which is what your server-side engine check is reading when it decides to reject a connecting client with NETWORK_DISCONNECT_REJECT_NOLOBBY - the server never properly finished absorbing the lobby roster before your later connect attempt.

The fix

Swapped the order - subscribe first, then broadcast the update to lobby members only (the server doesn't need a redundant update right after it already got the full state via subscribe).

Caveat

I could not test this against a real Dota 2 client/dedicated-server pair - our machine's GPU died and we currently have no way to run the actual game locally. This is verified to build cleanly and pass the existing GC self-check, and I traced the message-ordering logic carefully, but it has not been confirmed against the real repro you have. Would you be able to test this against your dedicated-server + remote-client setup and report back whether NOLOBBY is gone?

If it's not the (whole) fix, the other candidate from my notes worth checking next: attachServer is called from 5 different GC message handlers during server startup (gameServerHello, gameServerInfo, lanServerAvailable, serverAvailable, lobbyInitialized) and each one unconditionally reassigns lobby.serverSteamId = ctx.steamId - if any of those arrive with a different SteamID than the others (different game-server session/pipe reporting in at different stages), the cache push could still end up targeting a stale session. I didn't find evidence this actually happens, but I also couldn't rule it out without live tracing.

[micro-chief]

• Game / AppID: PAYDAY 2 / 218620
• Revision tested: latest
• Mode: Local / 2 players
• Result: partial
• Notes:
  • Multiplayer/co-op works very well. We were able to create/join a lobby and play together without any noticeable networking issues.
  • -steamMM is required. Both clients were launched with it to force PAYDAY 2 to use the Steam matchmaking path instead of Epic matchmaking.
  • The DLC patch did not work in my test.
  • Inventory is not working yet.
  • Gage Courier packages do not appear on the heist maps at all. I haven't investigated yet whether this is caused by DLC ownership not being reported correctly or by another missing Steam API behavior.

Overall, the actual lobby and co-op gameplay flow works very well. The issues observed so far seem to be around DLC/inventory-related functionality rather than the multiplayer session itself.

[micro-chief]

Thanks, that clarifies it. My previous PAYDAY 2 test was relying on UnlockAllDlc only — I did not configure SKYNET/DLC/, app_paths.txt, or installed_app_ids.txt.
I’ll retest against latest master. 🫡

[micro-chief]

I did some deeper testing with the current PAYDAY 2 build and found the actual reason why it refuses to start with SKYNET.
The game is specifically rejecting SKYNET's steam_api64.dll. I traced the startup failure and found a check around PAYDAY2.exe+0x975120: with SKYNET's DLL it returns null, and immediately afterwards the game shows "Installation corrupted".
I also compared it against seven older/original Steam API DLLs, and all of those pass this check. SKYNET's replacement is the one that fails.
So removing -insecure was unrelated, and simply implementing more missing Steamworks interfaces probably won't fix this startup issue either. The game appears to validate some property/fingerprint of steam_api64.dll before it gets far enough for normal Steamworks compatibility to matter.
I haven't identified the exact validation yet — whether it checks the file itself, metadata, signature/hash, exports, or something else...
This also explains why PAYDAY 2 works normally with the official Steam DLL but immediately rejects the SKYNET replacement on the current build.

...may be need a proxy/interposition approach rather than replacing steam_api64.dll outright.

[Hackerprod]

Dug into this today - installed Ghidra 12.1.2 + ghidra-mcp specifically to trace the offset you found, and decompiled the function at +0x975120.

1. Found and fixed a real PE-level bug (already deployed, worth retesting): SKYNET's x64 steam_api64.dll was built with the wrong internal module name baked into its PE export directory - it self-identified as steam_api.dll instead of steam_api64.dll (confirmed via dumpbin /exports; the real Valve DLL and a working third-party emulator DLL both have this matching their filename, SKYNET's didn't). Root cause: a shared AssemblyName across the x86/x64 DllExport builds. Fixed via a build-invocation override for the x64 pass only, deployed to payload/x64/steam_api64.dll.

2. That's probably not the actual blocker, though. Decompiling FUN_140974ef0 (the function at +0x975120) shows it reads core/settings/security_settings and does a content/hash check per entry - but its return value is completely discarded by its only caller (FUN_1409019f0), which just feeds a bit into an unrelated "Application version" label. So that function's pass/fail doesn't appear to gate anything by itself.

I found the literal string "Installation corrupted. Please verify your game files or reinstall." elsewhere in the binary, but it has zero static references anywhere in the image - no direct pointer, no relative-offset table. Whatever displays it is resolved indirectly (likely an ID/hash-driven lookup), which static analysis alone can't pin down. Nailing the real trigger needs a live debugger attached at the moment it happens.

I tried to test this live just now, but the shared copy I have is missing the assets/ data bundle (corrupted/incomplete transfer), so the game can't fully boot regardless of the DLL fix. I'll grab my own complete copy of PAYDAY 2 to verify this properly instead of continuing to guess from statics alone.

[micro-chief]

💀
Just a heads-up: that badge appeared for me after the 15+ GB update.

[micro-chief]

Small PAYDAY 2 update:

I found that the current build does start if I replace the original PAYDAY2.exe with a fixed EXE posted by AR-81 on cs.rin.ru.

With the original EXE, SKYNET's steam_api64.dll still leads to the known "Installation corrupted" startup failure. With the fixed EXE, the game starts successfully.

I have not yet determined exactly what the fixed EXE changes, or which specific check/function it alters. I only know that replacing the EXE changes the startup result.

So at the moment the situation looks roughly like this:

Original PAYDAY2.exe + SKYNET steam_api64.dll
→ "Installation corrupted"

AR-81 fixed PAYDAY2.exe + SKYNET steam_api64.dll
→ game starts

One question though: would replacing or patching the game EXE even be considered in-scope for SKYNET-Steam-Emulator?

I am not sure whether this project is intended to remain strictly on the Steam API / emulator side, with original game executables left untouched, or whether a game-specific compatibility patch would be acceptable when a title performs its own startup validation against the replacement Steam API DLL.

[micro-chief]

• Game / AppID: Bodycam / 2406770
• Revision tested: Current build, September 2026
• Mode: Local
• Result: Broken
• Notes:

Bodycam currently does not start with SKYNET.

With SKYNET's Steam API replacement, the game fails extremely early: even the pre-launch window does not appear.

Bodycam is a slightly unusual case because it uses SteamCorePro and also has an Epic Online Services dependency. Its Steam API DLLs are located inside the SteamCorePro plugin directories.

For comparison, I tested the same game with a Goldberg / gbe_fork Steam API replacement. With Goldberg, the game does start, so there is at least one Steam API replacement that gets past the startup path where SKYNET currently fails.

I also have a separate known-working configuration using Goldberg/gbe_fork together with an EOS replacement. That configuration gets the current Bodycam build all the way into the in-game hub/main room.

So the current comparison is:

SKYNET steam_api64.dll
→ game does not start
→ even the pre-launch window does not appear

Goldberg / gbe_fork steam_api64.dll
→ game starts

Goldberg / gbe_fork + working EOS replacement
→ game starts
→ reaches the in-game hub/main room

I have not yet isolated the exact Steamworks call/interface responsible for the difference between SKYNET and Goldberg, and I have not confirmed two-client multiplayer yet.

This might be a useful compatibility case for comparing SKYNET's Steam API implementation against gbe_fork, since the failure happens very early in Bodycam's startup.

[Hackerprod]

The lack of interface versions required by a specific game is a common flaw in emulation performance; there is a way to monitor behavior that is very useful when detecting issues.
In the configuration file generated by the dll /SKYNET/steam_api.ini, there is an option to save logs:
[Log Settings]
File = true
When enabled, it generates a file named steam_api.log in the same directory with data that could give us clues, such as unimplemented interfaces or specifically the moment when the failure occurred.
Perhaps we can obtain clues to fix it.

[micro-chief]

I initially suspected the SteamGameServer015 = NULL message, but the full trace shows that client callback processing continues afterwards, so I can't currently identify that as the startup blocker. It appears to be a game-server context probe while the GameServer API is not initialized. - https://pastebin.com/p8pNzBmk

[Hackerprod]

Looked at the SteamGameServer015 = NULL line specifically - that one is expected (client-only process, SteamGameServer_Init never called, matches real Steam behavior; the interface itself is fully implemented in SKYNET, not a stub). The pastebin snippet also does not show an actual crash - it ends mid-normal-operation with client callbacks (PersonaStateChange) still firing fine.

Could you paste the full, untruncated log (from process start through the actual point where the pre-launch window fails to appear / the process exits)? The snippet so far cuts off before anything visibly goes wrong, so I cannot tell what actually stops it without the rest.

[micro-chief]

That's the whole point—it's the complete log file. 😁

[killua-zhul]

• Game / AppID: Dimraeth / 2402680

• Revision tested: latest master (2c3afa0) + one local server-side fix (see Notes, not pushed yet)

• Mode: Local / 2 players (2 physical PCs on the same LAN, host runs the SKYNET server)

• Result: works

• Notes:

  Tested 2-player co-op across two separate PCs on a LAN. Both clients authenticated, joined the same lobby and completed the P2P handshake; actual gameplay worked. Both clients were launched with -insecure.

  Lobby flow was fine from the start (both clients eventually saw GetNumLobbyMembers = 2). The real failure was at the P2P stage: after joining the host's lobby, the joining client dropped back to the main menu. ConnectP2P always produced a single 1221 callback and AcceptConnection was never called on either side, i.e. the SocketsOpen frame never turned into an incoming connection on the host.

  Root cause: on the server, CloneEvent (SKYNET server/Services/SteamApiStateService.Helpers.cs, used by PollEvents) did not copy the P2P transport metadata fields. Every p2p_packet event was therefore serialized to clients with the defaults (TransportVersion = 0, Transport = "legacy"), so client-side ApplyP2PPacket reinterpreted all frames as legacy ISteamNetworking packets instead of SteamNetworkingSockets ones. SocketsOpen never created an incoming connection, and nothing was logged, so it looked like a silent drop. This affected sockets_* and messages transports alike (legacy P2P still worked, which is why it wasn't obvious).

  Fix — copy the five missing fields in CloneEvent:

  Protobuf = evt.Protobuf,
  Channel = evt.Channel,
  TransportVersion = evt.TransportVersion,
  Transport = evt.Transport,
  VirtualPort = evt.VirtualPort,
  SourceConnectionId = evt.SourceConnectionId,
  TargetConnectionId = evt.TargetConnectionId,
  RemoteSteamId = evt.RemoteSteamId,

  After rebuilding only the server (no steam_api.dll rebuild needed), the same sockets_open frame is delivered with transport="sockets_open", transportVersion=1 and the virtual port / connection IDs preserved, and the join works.

  Verification: reproduced both at the API level (two sessions, one POST /api/network/p2p/send with a sockets_open frame, polled by the other via /api/events) and with two real in-game clients.