Birdoggydog's Builds

Fixing five bugs from notes I drew in the game

I drew 13 notes in the game and found they were going to a folder nobody read. Five fixes followed, from a floating valve wheel to a window pane.

I walked the building field, the street where I can look at every building look, and drew 13 notes in the game with the backslash key. The first bug was in the notes themselves, because they had been saved to a folder nobody reads. Five of the 13 are fixed now: a floating valve wheel, a door with no stairs, a door behind a turret, and a window pane drawn from the wrong side. The other three were about floors, walls and stairs inside, and went to the work on rooms.

42 seconds. The decayed wall without its wheel, the smithy’s new stoop, the tower house door moving off the turret, and the open window seen from inside.

Why were my notes not showing up?

A test run keeps its notes in a scratch folder, so tests never write into the folder I read. The game counted the building field as a test run, so all 13 notes went into scratch. I added a check for where the engine’s user folder is. The script I use for tests gives every run its own user folder inside the workspace, so a run counts as a test only when that folder starts with the workspace’s godot_home. Anything else, like a scene I launch myself, writes to the real notes folder.

Why was a valve wheel floating?

My note said the decay was a little incoherent, because there was a floating wheel not attached to anything. When a building decays, the shader hides break groups. Each part has a group and a rank in the vertex color, and a group whose rank is below the missing value draws as nothing. The kit gave every part its own rank, so a wall could lose its pipe and keep the valve wheel that sat on it.

The rule I used is that nothing stands without support. A part stays while a chain of standing parts joins it to the core that never breaks. The collapse is nested, so that works out to one number per part, its held rank:

held(p) = min(rank(p), max over parts q it touches of held(q))    held(core) = 1

I work this out once when the catalogue reads a model and write it into the vertex color. The shader’s test is unchanged, so a fitting disappears at the same moment as the last thing it hangs on. Two parts touch when their boxes are within 12 mm, since the kit sinks a fixing 0.01 m into its host. A part touches the core when its box meets a core triangle, using an exact separating-axis test, with the core’s triangles filed in 0.5 m cells so a box only looks in its own. A wall’s whole face is core, so a pipe laid on it touches and a wheel held out in front of it doesn’t, which is why the wheel goes with the pipe.

Why did a door have no stairs?

I noted that the poles didn’t connect to anything and that there were no stairs, and I thought a porch might help. The ground floor stands on a 0.5 m plinth, so every ground door is half a meter over the street. Only a few kinds of building (shop, tavern, rowhouse) laid the look’s steps, so a smithy or a cottage door stood in the air. The poles were the frame for a planted climber, which stood at the door’s height holding up nothing.

Now every ground door whose sill is 0.5 m up and has no stair within 0.6 m of it gets the look’s stoop, three treads up to 0.495 m, turned the way the wall faces. The frame for the climber stands on the ground over the stoop, with its posts 1.7 m out and clear of the steps, so the two look like one porch. Only the steampunk and house looks have a stoop built so far. A look without one gets nothing and the door is listed, because a missing stair shouldn’t fail the catalogue’s checks. The other four looks get theirs when they’re installed.

How did a door end up behind a turret?

I noted that the door was partly behind the tower. A corner turret covers the two bays next to its corner, and the street door is the middle bay of its run. On a two-bay front that is the right-hand bay, which a turret at the front right sits on. After the openings of each run are known, I now move a door off any covered bay to the nearest free bay of the same run, and give the covered bay the free bay’s window so the run keeps the same number of windows. A run with no free bay keeps its door.

Why was a window pane drawn from inside?

I noted a weird lighting issue by an open window. Each room has a dark pane of air behind its window that should only be seen from outside. The shader tested the viewing direction in the fragment stage using the model matrix. Windows are drawn as one batch (a MultiMesh), and in the fragment stage that matrix belongs to the batch and not to each window. A pane turned off the batch’s axes was tested against the wrong direction, and from inside it was drawn over half the opening.

I now take the pane’s outward direction in the vertex stage, where each window’s transform is included, and pass it to the fragment stage in a flat varying. The test renders a longhouse window from inside with and without the air panes and compares the pictures around the opening.

Numbers

  • The fixes changed 32 files, 959 lines added and 27 removed.
  • The fittings test passes 25 checks and the test for the door, turret and pane fixes passes 15, with no failures.
  • Running the building, notes and building field tests together, 26 of 27 pass. The vines test fails a check that failed the same way before this change.