The world that loaded last week’s weather
Here is a bug that only appears if you do the one thing almost no test bothers to do: load a saved world, then load a genuinely different one right after. Do that, and for a while The Long Watch would hand you back the second world wearing the first world’s weather — a freshly opened place reporting conditions it never had.
The cause turned out to be a quiet habit of the engine underneath us, and the reason we hadn’t caught it was more interesting than the bug itself: a test had been passing for ages, and it had only ever loaded the same world twice.
What “last week’s weather” actually means
A saved world in The Long Watch is deliberately tiny. It records which world this is — its seed — and how far in-game time has advanced, and not much else. Weather isn’t written down at all; it’s re-derived on load from the seed plus the elapsed time, so the same place at the same moment always answers the same way. That player-facing side — rain you can ask the world about — has its own story. What matters here is the consequence: if a load returns the wrong elapsed time, or the wrong seed, the weather that re-derives from it will be wrong too. The weather is just the visible tip of a load that quietly returned a previous world’s state.
So when a second world came up showing weather that belonged to the first, the weather wasn’t the bug. It was the symptom that made the bug impossible to ignore.
Two engine habits that lined up against us
The load path was built on the engine’s default way of reading a saved file off disk. That default has a habit we hadn’t accounted for: to be fast, it keeps a cache of files it has already loaded, and if you ask for the same path a second time, it hands back the same in-memory object it built the first time — not a fresh read. For most uses that’s exactly what you want. For loading a saved game, it’s a trap, because two different saves can live at the same path one after another, and the second load would return the object the first one left behind.
On its own that might have stayed hidden. It took a second habit to make it visible. To keep files small, the engine omits any value that happens to equal its default when it writes a save — if a setting is at its default, the file simply stays silent about it. That’s a reasonable space saving. But pair it with a reused object, and you get a gap: a freshly written file could be silent about a field, while the reused object from the earlier load still held the old, non-default value for it. The new file never overwrote the stale value, because the new file never mentioned it.
The file said nothing about that field. The cached world still remembered. So the world loaded last week’s weather.
That is the whole mechanism. Neither habit is wrong by itself. The cache is a sensible default; the default-omission is a sensible space saving. They only became a bug where they met — in the one operation, loading a saved game, where you genuinely need a clean read every single time. A different load-path bug bit us on the same path around the same time — a save that came back wearing the wrong fingerprint — and that one earned its own story.
How we finally saw it
The way we caught it in the end was almost embarrassingly direct. We loaded a world carrying one marker value, then saved and loaded a fresh world carrying a different marker value — and the second load returned the first world’s marker. Two genuinely different worlds, back to back, was the minimum it took. No same-world test could ever have shown it, for a reason we’ll come back to.
Once the symptom was reproducible, finding the cause took roughly five minutes of probing. And the fix was a single line: switch the production load path off the caching default and onto the mode that bypasses the cache entirely, rebuilding a fresh world from disk on every load. That mode reads the file each time and returns a brand-new object with no aliasing — which is simply the correct behavior for actually loading a saved game, as opposed to referencing a file you’ve already got open. A one-line change, once we understood what we were changing and why.
We hardened the load routine while we were in there. Loading is exactly where a player’s one and only copy of a world is at stake, so we gave it a defensive ladder: instead of crashing, it now refuses cleanly with a named reason when the file is missing, empty, the wrong type, a format it doesn’t recognize, or carries a seed it can’t parse. The broader story of keeping an aging save loadable across every version of the game it might outlive belongs to a companion post; here, the ladder is just the seatbelt we added to the path we’d just fixed. And we added one assertion to the round-trip test that locks the fix in place: two loads of the same file must return distinct objects. If the cache ever creeps back in, that line goes red.
Why the test had been green the whole time
This is the part worth keeping. An earlier check of this exact machinery had been passing cleanly for a long time. It exercised the round-trip honestly — save a world, load it back, confirm it came home intact — and it was right about everything it checked. But it always loaded the same canonical world content, over and over.
Think about what that hides. The bug is “the cache hands back the same object.” When the object you wanted was identical to the one already in the cache, the cache returning it is invisible — you got the right world either way, by accident. The default-omission interaction can’t bite, because there was never a second, different file to be silent about a field the first one had set. Identical inputs didn’t just fail to catch the bug; they made it structurally impossible to catch. The only way the bug could surface was the realistic case the test never ran: two different worlds, one after the other.
We wrote the gotcha down in our shared reference for the engine, in plain terms, so the next person who reaches for the default loader knows it caches and knows the trap before they fall into it. The same surprise shouldn’t cost a second debugging session. And the deeper version of this lesson — that a passing check can verify nothing at all if you aim it wrong — earned a post of its own; this was simply the gentler cousin, a real test that was honest about a narrower question than we’d been reading it to answer.
Why a small bug was worth the words
The Long Watch is a game about tending one place over a very long time. That only works if the place is exactly where you left it when you come back — in-game time doesn’t advance while a world is closed, so reopening should be stepping back into the same paused evening, not catching up on a week that ran without you. A load that quietly returns a previous world’s state breaks that promise in the most disorienting way possible: the world is subtly not the one you saved, and the first thing you’d notice is the weather being wrong.
So the one-line fix was the easy part. The thing we actually took away was a way of reading our own green checkmarks — with the quiet question, but did it ever run the case that would break it? Two worlds, back to back. That’s all it took, and for a long time nothing had asked.
