Sixteen panes, after a restart.
Two players, a saved world, and the small accounting details that make building together dependable.
A pane in a window has a surprisingly long journey. Someone pays for it, another player sees it, the world saves, the server restarts, and someone else might remove it. The appearance and the material need to survive that whole journey together.
The development candidate has now passed that sequence on a dedicated server with two actual game clients. Both ran on this PC, connected over local TCP. This adds a useful kind of evidence to the full-pack tests: one player can change something while the other independently observes it.
Keep count
Each player began with eight blue glass panes. The first player fitted one into a brick arch and one into a glazed door, clicking the door's upper half. That left six in the first inventory, eight in the second, and two in the buildings.
The door has two blocks, but only its lower half owns the material. Clicking the upper half must reach that same owner. Two halves must never become two refunds.
Both clients disconnected. The server saved, and all three processes shut down normally. I then started fresh server and client processes against the same saved world. No rebuilding the test pieces; no refilling either inventory.
The saved panes, their item data and both inventories were intact. Here is the second player's view before recovery, still holding the original eight panes.
The second player then used the Create wrench to recover both inserts, including the door's pane through its upper half. Their inventory rose to ten. The first player still had six, and both clients saw the empty openings.
Six plus ten. The same sixteen panes we started with.
The cannon found a different problem
Earlier in this session, testing a stocked schematicannon exposed a door placement bug. Printing the upper half could create an extra block above the door. At an already powered destination, the two halves could also disagree about whether they were open. Both placement defects are corrected and checked with the actual cannon in the isolated full pack.
Pane refunds from cannon-built architecture are still unresolved. The cannon consumes the supplied pane and prints its appearance, but removing that insert does not yet return it. Refund support needs a transaction design that can follow the actual supplied material through partial and interrupted construction. Manually inserted paid panes have the separate, successful recovery path demonstrated above.
What this earns us
I like this milestone because it makes a quiet promise more credible: another person should be able to join your town, see your changes, and work on the same buildings without losing track of materials.
The restart test passed seven checks comparing the server and both clients, with eight inspected native captures and normal shutdown of both process generations. It covers an orderly restart on a small development server. Full-pack multiplayer, distant connections, abrupt crashes and heavy concurrent building still need their own evidence.
The installed local release remains 0.12.0 while this larger candidate develops. Next I am taking the workshop and terrace through their complete walking routes. A good-looking stair still needs a usable approach; the workshop's first route test has already caught one railing extension in the way.