Back to Blog
Engineering

The Lot Dev Log: Five Builds in Three Days

The first instalment of this log was about what must not ship. It was written from a position of having very little to show, and it argued that the discipline of refusing to publish a thing is most of the work.

This one is the opposite problem. Between 5 and 7 September, five builds went out: 0.51.0, 0.52.0, 0.53.0, 0.54.0 and 0.54.1. Three days. And when you lay their notes side by side, almost every entry turns out to be the same kind of entry.

Five Builds, One Category of Bug

Here is a sample, in the words they shipped in. The roof did not meet the walls — there was an open gap of up to two metres of daylight, so from outside the place read as a white box with a lid hovering over it. Two ceiling lights had been hung at exactly the depth a beam runs at, so they were inside it. Room Zero's concrete floor and the whole ground storey of the house were playing footsteps on soil. The Pal hovered a few centimetres above the floor and cast a shadow that followed the player rather than the sun. Fly was a debug camera that drifted through walls.

None of those is a crash. Every one of them shipped, repeatedly, and every one of them is a thing that existed but was not yet behaving like the thing it was supposed to be. That is the whole category, and it is the one that does not show up in a bug tracker, because nothing is broken. It is just wrong in a way you only notice when you stand in the room.

The rule that came out of it

A crash gets fixed because it stops you. A thing that is merely not an object yet never stops you, so it survives until somebody looks at it deliberately. Three days of shipping were almost entirely that: the same pass, applied to the roof, the floors, the lights, the shadows, the doorway and the way you leave the ground.

The Display That Renumbered Itself

The best bug of the five is in 0.54.0, and it is worth the whole section.

The Lot puts your real applications on the walls. To do that it creates a virtual monitor when it starts and takes it down when it closes, and it draws your windows onto that monitor. This had started failing in a specific way: clicking an app on the wall pulled the real window out onto your desktop instead of seating it in the room, which defeats the entire point of having it on the wall.

The cause was that Windows had quietly renumbered the display. The Lot was holding on to a number, the number moved, and so The Lot no longer recognised its own monitor and gave up on it.

Identify a thing by something that cannot be reassigned

The fix is one sentence: it identifies the display by its driver now, instead of by a number that moves. That is a whole class of bug rather than one bug. An index is a position in somebody else's list, and the owner of that list is under no obligation to keep your entry where you found it. Anything you will need to recognise again has to be found by something intrinsic to it.

The tell that this class is present is usually the symptom, not the code: a feature that works, then works for months, then silently stops for one machine and not another. Nothing changed on your side, which is exactly the point.

The Lights Were Not a Lighting Bug

A second one worth writing down, because the diagnosis was wrong for a while and the wrongness was reasonable.

The ceiling fittings looked like the light inside them was sliding around as you walked toward or away from them, while the pools they cast on the ceiling and floor stayed perfectly still. Everything about that says lighting. Everything about it is not lighting: at a distance a single pixel had to stand in for a whole shade lit from a few centimetres away, and it could not keep up.

So the light was correct and the representation of the lamp was not, and the fix was to stop asking a pixel to be a lamp. The fittings are real objects now — black metal, a tapered shade, a ceiling rose where the flex meets the plaster, and a bulb you can see burning under a lit mouth, instead of a glow with no cause.

The generalisable half

When the symptom appears in one system and the cause is in another, it is almost always because the first system was being asked to stand in for something. The question that unsticks it is not what is wrong with the lighting but what is this pixel currently pretending to be.

Flight, and What Landing Taught Us

0.53.0 turned flight from a debug camera into a body. You lift off the floor, hover with a slow drift, bank into your turns, and lean into the direction you are going, and walls, ceilings and furniture stop you the same way they do on foot.

The part that took the thought was not flying. It was stopping. Switching flight off used to drop you from wherever you were, and the fix is not "add a landing animation" — it is that every route out of a state has to be the same route. Ending flight brings you down under control, and so does anything else that ends a flight, including alt-tabbing away and opening the pause menu.

That is the same shape as the display bug: the ordinary path was handled and the incidental ones were not, and the incidental ones are the ones a real person hits.

Why the Version Numbers Jump

There is now a public patch-notes page for the playtest, and the thing on it we are most pleased with is not a feature. It is the paragraph explaining the numbering.

Versions go up whenever the work does, which is more often than a build gets uploaded. So a download carries everything since the last one, and the notes are grouped by what you could actually install rather than by every number that ever existed. 0.47.0 contains 0.45 and 0.46. 0.44.0 contains everything from 0.40.

Publish the grouping, not just the entries

A changelog that lists every version implies every version was obtainable, which is a small lie that costs you the reader's trust the first time they go looking for one and cannot find it. Saying plainly that the numbers move faster than the builds do costs one paragraph and makes the rest of the page true.

Where It Actually Is

The Lot is a private playtest at 0.54.1. The download is invite-only, and the page says so rather than dressing it up: there is a comment in that file stating the design rule outright, which is that a button that needs a password first is a button that lies about being ready.

We are not going to tell you it is nearly done, because the last three days should tell you what the work currently consists of. It is a build where the roof has only just met the walls.

Updated 10 September 2026: three more builds, the same day this published

0.54.2, 0.54.3 and 0.54.4 all went out on 9 September, and they belong to this article rather than the next one, because they are the same category again. Twenty-three controls could quietly do nothing when the piece behind them had not started, and one of them closed the pause menu and then opened nothing, so it looked like it had worked. The managers that start with a world were built in one long line, so a single one having trouble removed everything after it, including the main menu. And a crash report whose own log could not be read sent the current session's instead and looked complete.

That last one is the sharpest version of the thesis above. A control that fails silently and a report that substitutes the wrong data are the same defect as the display that kept working with a number that had moved: nothing errors, so nothing gets fixed until somebody stands in the room. The current build is 0.54.4.

If you want the other half of this argument, instalment one is about what we refused to ship and why. The same discipline shows up in the product work: a checker that passed for the one input it was given is the display bug in a different costume, and knowing it broke before your users do is about the monitoring that catches the ones nobody stands in the room to see. The rest of what we make is in seven apps and the problem each one was built for.

Brandon Wigley

Founder of Wigley Studios. Building developer tools since 2018.

Previous: AgeProof vs a Theme Age Gate Next: The Tool That Told Fourteen Merchants