SOLREIGN//DEV BLOG
Dev Blog #06

The Tutorial Nobody Could Reach

·The person building SOLREIGN

STATION DIRECTIVE /// DEVLOG BRIEFCLEARANCE: PERSONNEL
I went looking for onboarding I had not yet built and found it already written — 6,797 lines of it, behind a boolean set to false. Then I wrote a test to find everything else like it, and the test lied to me.
State inspector

Reachability scope

Tutorial CVar
Placement proof scope
Tutorial status
unreachable
Console placement proof
insufficient

A valid map in the repository is insufficient evidence when the map never enters SOLREIGN's seven-station rotation.

A CVar can make the tutorial reachable, but console placement is proof only when it intersects the active rotation.

Players on r/ss14 asked for a better new-player experience. SOLREIGN's Season Ledger remembers money, titles, and deaths across rounds; without context, new players leave. Twenty-two people found us through a post, and none stayed.

I sat down to build a tutorial and found one already built.

It had a first-shift beacon with an ordered duty track, a pairing system, 6,797 lines of C#/prototypes/locale, and 259 authored English strings. The beacon sat in arrivals on all seven rotation stations, invisible to everyone behind one CVar: solreign.first_shift_assignments_enabled, default false.

It was built, tested, and placed; the commit that would turn it on never happened.

It wasn't just the tutorial

The pattern continued. The ledger-backed Corporate Projects console, where crew pool contributions into station-wide works across shifts, was on zero maps. Power diagnostics raised SolreignPowerDisruptionEvent as the grid degraded, but nothing subscribed. Antag rotation correctly read recent Ledger rounds to decide who should sit out; it had zero callers.

Four features were finished and unreachable. Their tests passed because their tests called them directly. If a system's only caller is its test, it can appear healthy until a player tries to find it.

None of this is a compiler-visible failure. The Corporate Projects prototype existed, the event carried correct data, and the rotation arithmetic was tested. Each system answered correctly when invoked; the missing question was whether the game ever invoked it on behalf of a player.

Writing a test that can see it

A reachability gate now walks every entity prototype and asks whether a player can encounter it: placed on a map, purchasable from cargo, printable at a lathe, spawnable by a game rule, or otherwise reachable through a real path. An entity that answers no to all is an orphan and fails the build unless explicitly intentional.

It found the six entities I knew about. I wired them up, the gate went green, and I shipped.

At that point the gate was doing useful work. It could catch an entity that was neither placed nor purchasable nor printable nor spawned. What it could not yet understand was that a map can exist in the repository and still be outside the game players actually enter.

The gate was wrong

Two consoles in that release are still unreachable. SOLREIGN uses a restricted pool of seven purpose-built station chassis in map_pool.yml; game.map_pool directs round selection and map vote to that list. Twelve upstream stock maps remain in the repo but are never selected.

The consoles were on box and saltern. Both are valid maps that parse and load, so a gate asking only whether an entity was on a map returned green. They are never played here. The correct question intersects placement with the rotation, not the filesystem.

That is a false green: a test asks a question that is technically valid but too broad for the fork. Red gets investigated. Green can get shipped, so the scope of a reachability assertion matters as much as the fact that an assertion exists.

I caught this while personally counting each console's maps before a changelog claim. The release did not announce the two consoles, because an unreachable feature is not a feature. The gate is being taught about the active map pool.

The correction is narrow and concrete. It does not discard all map placement as evidence; it intersects it with the seven-map rotation that game.map_pool selects. That is the distinction between a valid upstream map and a map a SOLREIGN player can encounter.

What actually shipped

The tutorial is on. The beacon works; if anyone else is aboard, it tries to pair a new player with them. The Corporate Projects console is on all seven rotation maps. PROVIDENCE now announces grid failures, and antag rotation has a caller capped so it cannot starve a low-population round of its antagonist.

Almost all of this is old code finally introduced to the game.

That is also why this class of work is easy to mislabel as a feature build. The behavior was already there in most cases; the release work was to give it a route from a player to the systems that were otherwise only reachable by a direct test call.

If you find one

The gate has a known blind spot, so there is more to find. If you see a console with no purpose, a job with no equipment, or a machine that never reacts, report it. That is the highest-signal bug report this fork can receive.

The person building SOLREIGN

Station Boarding Advisory

Ready to step onto SOLREIGN?

SOLREIGN is an independent, persistent Space Station 14 server. Every other station forgets you at round end — this one keeps a file. Free to join, airlock open.

← All Dev Blog entriesHow to Join →