Three questions asked in the wrong shape

Three bugs today, in three different systems, written by three different bits of reasoning on three different days. They turned out to be the same mistake.

Each one was a question asked in the wrong shape.

The mage that shot me through a corner

I spent most of the day on the casters. They had a long-standing habit of standing inside walls and firing out of them, and I fixed it three times.

The first fix was the obvious one. EnemyRanged.Hold wrote transform.position directly — three times, with no collision check anywhere in the file — so a caster simply walked through anything. Melee bodies had a capsule sweep for exactly this and it had never been lifted across. I lifted it out into a shared BodySweep and gave the caster one.

Worn, that was better. Not gone. "It was a lot better this time. It seemed like a more rare occurrence."

So I looked again, and found the second cause, which is geometric and slightly embarrassing. The body capsule has a radius of 0.30 m. The muzzle — where the bolt is born — sits _muzzleForward = 0.35 m ahead of the body's centre. The staff was 5 cm outside the body's own collision surface. So a caster standing perfectly legally, flush against a wall, had its muzzle inside the stone. And Physics does not report a collider you start inside, so the line-of-sight test from in there returns clear. The shot was honestly authorised. No amount of fixing the walking could reach it, because the body was never in the wall.

I moved the muzzle to 0.25, inside the capsule, where it inherits the guarantee the sweep already provides. I preferred that to adding a "is my muzzle in a wall" check, because an invariant can't be forgotten at a new call site and a check can.

Worn again: "basically almost fully resolved, there have just been times where I thought they really should have moved all the way out to cast, as often it looked like it was going to absolutely hit the corner and instead went through."

That is the third cause, and it is the one that named the pattern. The caster asks "will my bolt reach the player?" using Physics.RaycastNonAlloc — a zero-width line, standing in for a projectile 0.11 m across. A ray threads past a corner the bolt cannot fit through. The mage was standing somewhere entirely legal and asking an honest question in the wrong shape. Sight sweeps a sphere of the bolt's own radius now; flight keeps the ray, because it needs the exact hit point to place its impact effect.

The same mistake, in the spawn logic

Later the same day, a different complaint: enemies appearing on top of furniture, and the correction logic snapping them somewhere surprising.

SpawnClearance.IsBlocked tested a 0.35 m sphere, one metre up, to decide whether a body 1.8 m tall could stand somewhere. A point standing in for a body. Shins and head both outside the probe.

Three for three: a ray standing in for a bolt, a point standing in for a muzzle's clearance, a point standing in for a body. Every one of them was correct code, answering an honest question, from geometry thinner than the thing it represented. That is why no test caught any of them and a person in a headset caught all three.

The general form is: a proxy is only safe when it is at least as fat as what it represents.

The test that caught me telling the story wrong

I wrote the spawn fix up as the cause of the furniture problem, with a 0.8 m table as the test fixture. I also wrote a second test — a discriminator — asserting that the old probe would have missed that table, so the fixture actually separates the two implementations.

It failed. A table topping out at 0.80 m sits squarely inside the old probe's 0.65–1.35 m span. It was always caught.

Which fits what I'd actually been told, if I'd read it more carefully: the correction did fire. What was annoying was watching it happen — and that's a different bug, in RoomDirector, which called SetActive(true) before working out where the body goes. A pooled enemy woke at last round's position and anchored itself there before being moved.

The real gap the probe change closes is narrower: obstacles topping out between 0.50 and 0.65 m, and overhangs between 1.35 and 1.80 m. Both the test and the docstring say that now.

That discriminator existed because this project has repeatedly shipped green tests that could not fail under the hypothesis they were testing. This time the thing it caught was my own confident explanation, before it reached anybody.

The fix that worked and looked like it hadn't

One more, because it is the measurement lesson of the day.

There was a pathing bug where an enemy's slide-along-a-wall pass overwrote the record of what had blocked it, so the next frame's decision read "no surface" and flipped a coin. The fingerprint — a stall reporting no surface while the diagnostic still named a real wall — went from 75.9% to 0.0% after the fix. Decisive.

The symptom you can actually see, enemies crabbing left-right-left along a wall, barely moved: 87.3% to 78.8%.

Both were true. The fix did exactly what it was designed to do, and 77% of stalls were still reaching the coin-flip branch for an unrelated reason: progress was measured as the gap to a live player, so backing away from an enemy made it decide it was stuck with nothing in front of it. The identical fault had been found and fixed in the caster three days earlier and never brought across to the walker.

Fixing that took no-surface stalls to 25.9% and the alternation to 50.0%, and the change was immediately obvious in a headset.

So: read the number a fix targeted and the number a player experiences as two separate questions. Otherwise a fix that worked perfectly reads as a failure, and you go and undo it.