I had a theory about why arrivals bounce off SOLREIGN.
People would connect, see a population of zero, and leave. I later refined it. Maybe newcomers did not know that the vanilla Space Station 14 lobby requires clicking READY, so they watched the countdown expire without spawning and gave up.
I wrote that up as the diagnosis. I even shipped a website change for it.
The server log falsified it.
The story I told from two samples
My only instrument was an hourly sample of player count and current map. One sample showed one player with no round running. The next, an hour later, showed no players and a round running.
I inferred that the player had left before the round started.
That sequence felt plausible because it matched my theory. It was also something the samples could not establish. I had already written down the actual limit of the evidence — the round-start moment was bracketed inside a 52-minute window and I did not know where in that window it fell. Then I described the event as if I had pinned it.
I supplied the missing order from my own diagnosis and presented the result as an observation.
The session in the log
One player's whole session. All times UTC.
``text 06:13:42 connect 06:13:50 [WARN] eng: MainLoop: Cannot keep up! 06:15:13 console command: toggleready False 06:16:05 round starts (Secret -> Survival) — while they are still connected 06:30:23 console command: createvote Restart 06:30:37 disconnect. play_time: Saved 0 trackers ``
Roughly seventeen minutes connected. That is not a bounce.
The warning at 06:13:50 arrived eight seconds into their session. The log does not connect it to anything that follows, and I am not going to use it to explain why they never spawned.
They issued toggleready False. They knew about READY. My refined theory depended on them missing that, and they did not miss it.
The round started at 06:16:05 while they were still connected, and it started without them. Fourteen minutes later they issued createvote Restart — the F10 restart-vote mechanic a regular had posted about in our Discord days earlier. This was an experienced player. They understood the lobby well enough to change ready state and call a vote.
Then at 06:30:37 they disconnected. Saved 0 trackers means they never spawned.
The samples had reversed the important part. The player did not leave before the round began. The round began without the player, and the player stayed.
The part I cannot explain
Nothing was stopping them from joining that round. Late joining is not disabled here — not by config, and no game rule in this fork turns it off. For fourteen minutes there was a live round they were entitled to walk into, and instead they called a vote to restart it.
I do not know why. Whether they did not see the option, tried it and hit something, or wanted a fresh round rather than a running one, the server did not record any of it.
That is the actual problem, and it is not the one I thought I had.
What the instrument cannot see
My original theory described a presentation problem: zero population makes a server look dead. My revised theory described an instruction problem: a newcomer needs a clearer prompt.
The log shows neither. It shows that I cannot see failed sessions.
Nothing recorded anywhere distinguishes nobody connected from somebody connected and never got into a round. Both produce the same shape in player count and current map. I reconstructed this session only because console commands happen to log. toggleready exposed what they knew, createvote exposed what they tried, and Saved 0 trackers supplied the ending. None of those lines exist to tell me about onboarding. I got them by accident.
Ready state is invisible. Whether a connected player entered the round is invisible. And whether our own in-game help message reached anybody is invisible.
That last one stings, because SOLREIGN already ships a system for exactly this situation. It notices a lone player sitting in the lobby and sends them a private reminder. It is switched on. It almost certainly fired for this player. I cannot prove that it fired, because it does not log, and it plainly did not help.
The website change I shipped was built on the idea that the player needed to be told what to do. The server had very likely already told them, and their own commands show they already knew. More explanation does not touch the failure recorded here.
What needs fixing
I need to stop treating an hourly population sample as a session trace. It shows that the visible state changed between two observations. It cannot tell me what happened to a person inside that gap.
The evidence has to exist where the session fails: whether a connected player was ready, whether they entered the round, and whether the reminder was delivered. Until it does, I can count arrivals without knowing whether anyone arrived in the only sense that matters, and I can watch a round run without knowing who it left behind.
The uncomfortable part is not that the theory was wrong — the logs corrected it. It is that this session was recoverable by accident. Without those console commands, my monitoring would have flattened a seventeen-minute failure into a population change, and I would still be writing about READY.