I believe the flow in the diagram is what Steam calls Session Tickets and is a bit more nuanced. The game client requests session tickets from Steam's server, then it provides the game server with a ticket proving they are a given Steam ID. The game server then has to go online to Steam's web API and verify it to ensure it has not been used multiple times or tampered with. It sounds like the CS2 client is not handling a delayed response for obtaining a session ticket.
The flow is detailed here[0]. The flow the article diagram suggests would be a bit concerning since an attacker could race a victim Steam ID to join a server, etc.
Yes, it's most likely a session ticket which is not clearly expressed in the article, but the issue seems to be that the game sometimes gets interrupted before it will actually create a session ticket (or rather while waiting for the response from the slow steam servers), and then join the gameserver without having one.
Thank you very much. Indeed this is the technically correct flow, which was not so important for the explanation of the issue. I understand I should have mentioned it though to make it more clear. Much appreciated!
My only comment here is that the trail in the article and the conclusion don't quite make sense (well, they do, but you've kind of glossed over it slightly):
> The way Counter-Strike is started: the blame factor is 90%
But also:
> We could confirm that players world wide are facing the issue outside of Esportal and thought it indeed is caused by some maintenance in the middle of the night in Washington.
Those can't both be true.
If the blame is 90% about the way counter strike is started, then the issue wouldn't be distributed over the maint window.
Rather, it seems like this is the key part that should be highlighted in the summary:
> So the last thing that happens before the game loop is started is that the Steam ID validation is initiated.
> When the initialization of levelload is incomplete (speak: CS2 has not been fully loaded/initialized), the Steam3 validation is never initiated because it is the last thing that loop wants to do.
Which is to say, that when the `steam3` server is as slow as balls during a maint window, it makes this take longer, which means you're more likely to interrupt the loop by starting a game.
So when you say:
> The way Counter-Strike is started: the blame factor is 90%
It's true.... but maybe it's also true to say:
> State of the moon: blame factor is 3% <--- isn't quite right, since this is basically the maint window?
Maybe the advice should also be: 'and give is an extra couple of minutes during 13-17 PM CET, because Value does maint in that window'
...if I understood that correctly. :)
Either way, this has happened to me, but this 'just wait a while and let it finish loading' solution is by far the most useful sensible advice about it I've ever heard. Fantastic stuff.
Thank you for your comment. I agree there is some hole in the details of my explanation/conclusion attempt, but I am not sure if your attempt to explain it is correct either. I am not saying yours wrong or something, but players have had this issue in CS:GO unrelated to the maintenance window. In CS2 however we only observed it in the maintenance windows.
So maybe in the end the bugs in CS:GO and CS2 are of different nature, but I will not be able to ever proof this as CS:GO has been replaced by CS2.
Back in the day, I wrote a tool which used to display server list with active players and their scores so you could hop on a server when you see a friend is on. This was before steam existed (no such feature was available at the time).
While writing this tool, I sent a bad packet to a server I was testing with, and the server went down. I still have the source code (wrote it in delphi), I wonder if this thing can still crash servers, given that decade-old bugs exist :D
Or that the session ticket verification flow needs connectivity between the game server and Valve's (apparently very slow at times) auth server.
Presumably a faster and more robust solution would be for the Steam client to obtain (and hang onto) a signed token (from Valve) with a lifetime of a few hours, and whenever you connect to a game server that token is sent over where it can be validated locally against a public cert issued by Valve (that comes distributed with the game server contents).
This exact thing happened about a decade ago, when someone released a tool called Serenity that allowed you to spoof your SteamID using recorded tickets. It was especially chaotic for the Garry's Mod community, since most servers have admin tools gated behind SteamID checks.
To protect against replay of the token associated with the certificate, simply challenge the client to sign the value specified by the server eg. random value+server ID.
In some paragraphs you put “a hat on a hat”. That is, you pile on the snark on top of an already meme-y paragraph and it feels like “too much” of something that works better subtly.
This was a great read. I wonder if the reason for the game client surprise crashing could be investigated the same way? Do the executable integrity checks run during runtime? What if one of those fails while it’s running, do you get a different disconnection message?
What surprise crashing are you referencing to? Crashes can be investigated in theory but Valve sends crash reports to their servers instead of storing them on disk. It's harder to analysis if you didn't catch a crash live with a debugger attached. And that is hard because of their Anti-Cheat (VAC) though not impossible (disable VAC).
I think this was the result of me putting so much effort into my first article and at the moment of release I didn't want to "throw it away" with a single sentence solution. In hindsight this way of thinking was wrong and that I could have done better and I agree it's like a bad joke. Fixed!
Good post. I have a particular style from having Strunk and White shoved into my brain, that I prefer, so you can throw this comment away if you want.
But if you'd like feedback, I'd suggest brutally editing down the text to be more direct and concise. You can certainly write long form, but after a few minutes it started to pile on ancillary and anecdotal paragraphs and I lost the main thread pretty quick. Add to that a random picture with an inception reference and it's starting to feel less like an informative piece and was collecting random unrelated content.
Think about what you're trying to say, say it, then go back and make sure you said it and only that. Everything else is just practice typing, not writing.
Maybe you have 3 or 4 things to say, but just say them.
Great write up, but it left me with a few questions:
* Is levelloadloop only executed when the game launches, not when joining a server and loading the map?
* If the issues is that the loop is shut down before the steam auth process is started, why would the maintenance-related slowness matter?
1. Yes, only when the game launches. I think the naming of the loop is related to single player games like Portal, where this way of naming makes much more sense because you have frictionless changing of levels there.
2. You are right that is a hole in the explanation and I do not know the answer, but it is definitely a fix for the problem. Likely the details of my conclusion are incomplete but at this point I don't feel like digging deeper because it's not necessary at the moment.
> This program covers the Steam platform and current games developed and published by Valve. Please review the reward tables and scope descriptions below.
[...]
> Effective 6/14/2023 10 AM PDT, CS:GO is out-of-scope for new reports. Reports for CS2 Limited Test are currently out-of-scope.
Valve suck at security, sure, but with the reading of the wider HOne description, I'd peronally read it as in scope. They haven't updated the "Scope" tab to exclude "csgo.exe", so clearly that isn't reliable.
(That being said: please Valve, update the damn thing.)
Given that Valve doesn't reply to simple requests like this to ask if it is in-scope, I can't know that. Though I agree with your conclusion. Makes sense!
I feel that drawing weapons has gotten slower in CS2. I wish they dropped the 'pull back on the charging handle' every time you draw the gun. (and I miss my custom sprays from CS: Source).
But apart from that, even though I've played CS since 1.4 I have never ever had the bug mentioned above.
If we’re nitpicking the gunplay (which I am perfectly okay with doing), how about adding in the fact that reloading with one in the chamber doesn’t give you a +1 round either? It’s like the concept of a chamber is completely ignored.
Try Insurgency: Sandstorm. It's a completely different style of gameplay, but in addition to properly simulating a chamber, it also properly simulates magazines. Reloading retains a used magazine rather than dumping the ammo back into a fungible pool. Double tapping the reload key allows for dropping the mag for a slightly faster reload. Once you've cycled through your supply of fresh mags, loading a used mag leaves you with the same number of rounds as when you discarded it.
It sounds like the solution is to keep the game open for awhile before going into multiplayer? You say "until you see the game console or wait 5-10 seconds after you saw the intro video." How long is that specifically?
I don't play CS:GO but I've seen the "No user logon" error when playing other games online, specifically Portal 2 and It Takes Two.
> I'd love to get feedback
Please put the solution in the tl;dr. The write-up is interesting for some folk, including many on HN (and myself) but the average person looking up this error could not care less about the intricacies of the code or network calls that cause the error, they just want to fix it.
(added in edit) The "You can skip to No user logon if you don’t care about the history." link that doesn't jump to the answer would be extra frustrating for someone who is just looking for the solution. From a pc there is a table of contents and the fact that there is a "Solution" section is great, but a phone user does not see that.
I do not know the exact answer of how long it takes to get into the `game` loop and it is depending on your system also. To know for sure, you can type
status
into the CS2 ingame console. If it shows this, you know you are ready to go:
I wish Valve improved their Steam app on macOS. On my MacBook with M1 Pro and 32GB of RAM it doesn't feel smooth. It runs like a poorly optimized Electron app.
Not sure how Steam is developed but it is basically the OG Electron app. They’ve been bundling the entirety Chromium since they launched on macOS in 2010, predating actual Electron by at least 3 years.
I wouldn't be looking forward to this happening. Valve will not support CS2 _at all_ for macOS [0] because there are not enough players for CS2 on macOS. While it likely doesn't translate to the whole of Steam userbase for other games, I guess it is their general conclusion that macOS is not a first-class citizen for Steam.
it does so on windows 11 with a brand new Radeon 7000whatever and 32G RAM and SSD and ... you know, hardware, that they know about, due to the hardware survey they conduct yearly.
I have no idea how they even develop it. Are they all sedated?
Maybe it's just one more of the unforseen consequences of Valve time.
The flow is detailed here[0]. The flow the article diagram suggests would be a bit concerning since an attacker could race a victim Steam ID to join a server, etc.
[0] https://partner.steamgames.com/doc/features/auth#3