Is testing help needed for Dota 2 or SKYNET Server?

[micro-chief]

Hi! Do you currently need any help finding or reproducing problems with Dota 2 support or with the SKYNET Server itself?

I can help test specific flows, collect logs and report reproducible problems.

If that would be useful, could you enable GitHub Issues and add structured templates, at least for:

• Bug reports
• Feature requests

That would make it easier to provide the affected AppID, SKYNET revision, reproduction steps, logs, expected behaviour and actual behaviour without mixing unrelated reports into Discussions.

[Hackerprod]

Thanks, testing help is welcome! Enabling Issues with bug report and feature request templates now so reports (AppID, SKYNET revision, repro steps, logs, expected/actual) can be tracked properly instead of mixing into Discussions.

[micro-chief]

Thanks! The issue templates will help a lot.

Before I start testing AppID 570, could you clarify which flows currently need the most attention?

For example:

• Client startup and connection to SKYNET
• Game Coordinator login/session
• Profile, inventory and matchmaking data
• Party or lobby creation
• Queue and match startup
• Dedicated server connection
• Reconnection after restarting the client or server
• SteamDatagram networking with SecureNetworking = true and false

Please also let me know which branch or revision I should test and whether there are any known failing scenarios I should try to reproduce first.

If specific logs, console commands or debug settings are required, please mention those as well.

[Hackerprod]

Good question. For AppID 570, the flows I would prioritize are the ones I have not been able to validate myself, since they require a second player and I have not had anyone available to test with:

• Joining an existing lobby, both in Local and Dedicated server mode. I have verified lobby creation, slot/team changes, and rename from the leader side, but I have not confirmed that a second client can actually join the lobby and load into the match successfully in either mode.
• Equipped items showing up in-game. The item data is sent to the dedicated server (queue_lobby_items_to_server logs succeed), but I have not been able to confirm whether equipped cosmetics actually render on heroes once the match starts, since that also requires being in a live match with another player to observe.

Everything upstream of that (client startup/connection, GC login/session, profile/inventory/matchmaking data, queue and match startup) has been exercised solo and looks correct from the logs, but the two items above are the actual blind spot right now, so that is where testing help would be most valuable.

Revision-wise, master at HEAD should be fine. If you hit anything, the new issue templates (bug report) are the right place, with AppID, revision, repro steps and logs attached.

[micro-chief]

Thanks, that gives me clear testing targets! Funny enough, I’m currently in a similar situation and cannot test co-op with a second player either. (LoL 🥲)

I may have an opportunity to test it in about a month. If I do, I’ll prioritize:

• joining an existing lobby with a second client in both Local and Dedicated server modes;
• verifying whether equipped items actually appear in-game.

I’ll use the latest master revision and report any findings through the issue templates with the AppID, revision, reproduction steps and logs.

After that, however, I expect to have very limited connectivity for a short period and then no access to a PC for roughly a year, so I unfortunately cannot promise continued testing or repository work during that time. I’ll try to validate and report as much as possible during the window I have.

[micro-chief]

I tested Dota 2 with the updated master revision. SDR relay discovery works correctly with both a single relay and two configured relay servers, and I have not noticed any SDR-related problems so far.

I did notice two unhandled routes/messages: 8209 and 9107. They do not appear to prevent Dota 2 from working

[Svenmax]

https://github.com/Svenmax/gbe_fork
I have implemented most of the features for Dota2GC and conducted multiplayer online tests.Hope this can help you.

[micro-chief]

A slightly Dota 2 question 😁

Do you know which fields/values in the SKYNET database are responsible for:

• Behavior Score / Communication Score
• Dota Plus Shards

I'd like to raise those values for my local test account, but I'm not sure which DB fields the current Dota implementation actually reads.

For example, are these stored directly in dota.db, derived from one of the account/SO records, or populated somewhere else by the Dota GC implementation?

If you know the relevant table/column names (and whether a server restart or cache refresh is needed after changing them), that would save me quite a bit of digging 😁

[Hackerprod]

Checked the actual code (DotaStatsStore.cs, GetConduct):

Behavior/Communication Score: there's no dedicated column for it, it's computed fresh from other tables every time it's requested:

• reports count where target_account_id = <you> and report_flags <> 3840 (real reports against you)
• commend count where report_flags = 3840
• match_players rows where account_id = <you> and leaver_status <> 0 (abandons)

Formula: rawScore = clamp(10000 - reports*500 - abandoned*1000 + commends*100, 0, 10000). To raise it for your test account: delete/reduce rows in reports with report_flags <> 3840 targeting your account_id, reduce abandon rows in match_players, and/or insert reports rows with report_flags = 3840 (commends) for your account_id. No restart needed -- it recomputes on the next request that reads conduct, no caching involved.

Dota Plus Shards: not implemented at all server-side. The protobuf fields exist (generated/dota.ts has shardsAwarded, shardWinnings, etc., since they're part of Valve's real schema), but no module under GC/570 reads or writes any of them -- there's no DB column or code path for shards yet, so there's nothing to edit to raise it right now.

[micro-chief]

Bruh 🗿

I was expecting to find some hidden DB field for both of these, but of course one of them is calculated dynamically and the other one doesn't exist yet at all 😭

Thanks for checking the actual code and breaking it down — that explains why I couldn't find anything obvious in the database.

The conduct formula is especially useful to know, and the fact that it recalculates on request makes testing much easier.

And I guess Dota Plus Shards just quietly became another item for the future GC/570 roadmap 🗿

Thanks again!

[Hackerprod]

Started a dedicated thread for compatibility reports: #38. Would be great to have your Dota 2 findings (SDR relays, 8209/9107) logged there too, and any future testing when you get the chance.

[micro-chief]

Just as a heads-up: my fork hasn't been updated with the latest Dota 2 fixes yet. Yesterday I was testing SKYNET with a friend and we managed to fix the lobby flow locally. Both clients could get into the lobby/room, but we hit another problem at the match connection stage: I could enter the match as the host, while my friend's client appeared to ignore -insecure with SDR Certificates enabled, so we stopped there for now.
We also tested Left 4 Dead (AppID 500). It works quite well with two players and we were able to play through several missions, although the game occasionally crashes after a few missions without any obvious warning. I have some local fixes/changes from that testing too, but none of this has been pushed yet.
Most of my available LLM/Work token budget then went into investigating and documenting these compatibility issues and continuing the Dota/GC work, and I ran out before I could properly clean up, verify and push the fixes. I'd rather not push the local changes until I've had a chance to review and retest them.

This message was translated and reformulated with an LLM.

[micro-chief]

One more unrelated question: is it expected for old lobby and registered game-server entries to remain visible permanently in both the web admin panel and the desktop app?
I've noticed that entries from previous tests can stay there long after the corresponding game clients/dedicated servers have been closed. For example, my current state shows old AppID 500/620 lobbies and a large number of previously registered Deadlock dedicated servers.
I'm not sure whether this is intentional persistent registry/history behavior, or whether inactive lobbies/servers are supposed to expire or be removed automatically. If they're expected to be cleaned up, there may still be some stale-state cleanup missing somewhere.

[Hackerprod]

Good catch, this was a real gap, not intended behavior. Root cause: lobbies and game servers only get pruned as a side effect of a matchmaking browse call (QueryLobbies / ListGameServers) - the admin panel never makes either call, so it listed every registration ever made, dead or alive, forever (and it survives restarts via api-state.json).

Fixed in 61d3ffc (master): the admin overview now prunes stale lobbies (owner+members offline) and stale game servers (missing/expired heartbeat lease) before listing, and expired game-server registrations are removed outright now instead of just being hidden from the matchmaking browse result. Old entries already sitting in your api-state.json will get swept the next time you open the admin overview after updating.

Also opened #38 for general compatibility feedback (any game, not just Dota) - would be great to have your Left 4 Dead and Dota lobby-fix results logged there when you get a chance. On the L4D crash and the SDR/-insecure issue on your friends client, feel free to open bug report issues with logs when you can - useful to track separately from this thread.

[micro-chief]

Thanks! I do have steam_api logs from the Dota/L4D testing, although they tend to get very large. Rather than uploading the entire logs immediately, I'll try to reproduce the Dota connection problem again with both clients and collect a cleaner window around the failure. If needed, I can also provide the full logs.

[micro-chief]

There is another compatibility issue I've noticed with the current Valve/Source 2 games.

So far we've been unable to get the -insecure path working reliably in Dota 2, Counter-Strike 2, and Deadlock.

The exact behavior varies a little between tests:

• sometimes the client simply cannot connect to the host/server;
• sometimes the game explicitly reports an -insecure / secure-host mismatch;
• in some tests both the host and the joining client appear to end up affected by the insecure state.

The interesting part is that we've now seen essentially the same class of problem across all three Source 2 games, so I'm starting to suspect this may be a shared Source 2 / Steam networking or authentication behavior rather than three unrelated game-specific problems.

I initially thought NetHook captures might help us understand it, especially by comparing a normal Steam connection against the same flow through SKYNET. However, I'm not sure the relevant part is actually GC traffic. There may be a separate connection/authentication handshake between the client and game server that determines whether the peer is considered secure/insecure.

So at the moment I don't really understand where that state is established or how the two sides agree on it.

A useful comparison might eventually be:

Official Steam
client
  ↓
GC / lobby / server assignment
  ↓
SteamNetworkingSockets / connection handshake
  ↓
S2C_CHALLENGE / authentication
  ↓
game server
  ↓
accepted


SKYNET
client
  ↓
GC / lobby / server assignment
  ↓
SteamNetworkingSockets / connection handshake
  ↓
?
  ↓
secure/insecure mismatch or connection failure

This is not a request to implement a workaround yet. I mainly wanted to document that the same issue appears in Dota 2, CS2, and Deadlock, and ask whether you already know which part of SKYNET / steam_api would be responsible for this state.

If not, I think the next useful step on my side would be capturing one known-good connection and one failing connection and comparing where their authentication/connection state starts to diverge.

[Hackerprod]

Found a concrete root cause for this, and it explains why it's the same across Dota 2, CS2 and Deadlock - they all go through the same launcher/gameserver code, so this isn't a per-game GC issue.

SteamGameServer.ShouldReportSecure() is hardcoded to false server-side (steam_api can never produce a valid VAC session, so the game server always self-reports insecure - by design, same as the dedicated server, which already always launches with -insecure).

The bug: the client's own launcher only appended -insecure to the game's own process based on the SecureNetworking game setting, which defaults to true. That setting actually only gates the SDR CA certificate patch inside steam_api - unrelated to VAC. So out of the box, the game launches expecting a secure host, while the game server it connects to (including a listen-server host's own game acting as server) always reports insecure - exactly the mismatch you were seeing, and consistent whether you were host or joiner since both go through the same launcher.

Fixed in f897b52 (master): -insecure is now appended unconditionally to the game's own launch arguments, decoupled from SecureNetworking (which still only controls the SDR CA patch, nothing else).

Could you pull latest and retest Dota 2/CS2/Deadlock when you get a chance? Would help a lot to know whether this actually clears it up, or if there are new/different symptoms once this mismatch is out of the way.

[micro-chief]

Great find — that explains the behavior across all three games much better than a per-game GC issue.

I also didn't realize SecureNetworking was only controlling the SDR CA certificate patch and was unrelated to the VAC/secure state. That coupling explains why the symptoms were so confusing.

I'll pull the latest revision and retest the same paths in Dota 2, CS2, and Deadlock with the new unconditional -insecure launch behavior.

I'll report the results separately so we can see whether the mismatch is completely gone or whether any game still has an additional connection issue.