Reviewing #179, @nnunley suggested:
Consider adding an obstruction in the middle of the room to validate that objects/mobs on the other side of the obstruction can't see each other via fov.
It arrived with the approval rather than as a change request, and it asks for coverage of existing FOV behavior rather than of what #179 changed (an empty :fov now reads as uncomputed instead of as a real result). So #179 merged as approved, and the suggestion is filed here.
The gap is real. As of 2026-08-07 no file under xsofy/test/ references compute-fov, has-clear-line?, or transparent?. The shadowcasting in xsofy/fov.lg and the Bresenham line-of-sight in terrain/has-clear-line? are both load-bearing for what the player and the AI can perceive, and neither has a test that puts something opaque between two points and checks that it occludes.
What exists today tests the cache seam, not the geometry. percept_test.lg covers which FOV set entity-fov hands back, precomputed vs. computed on demand, player vs. NPC, and every case runs in an open carved room where everything can see everything. A compute-fov that ignored walls entirely would pass the current suite. Occlusion is also the part of FOV a player notices the moment it breaks, and the part most likely to break silently under a refactor of the octant casting.
Suggested shape
percept_test.lg already has a room-world helper (a 10x10 stone room carved to 1 1 8 8, player at [2 2]), and fire_test.lg establishes the mechanism for placing a single blocking tile:
(terrain/tset! (:terrain w) (:width w) x y 8) ;; 8 = wall-stone, not transparent
So: carve the room, tset! a wall segment spanning the middle, put an entity either side of it, and assert neither position appears in the other's entity-fov. Pair it with an unobstructed control in the same room asserting they do see each other, otherwise the test still passes if FOV returns nothing at all.
has-clear-line? needs the same coverage. terrain.lg describes it as the single home for logic that was triplicated across world, ai, and percept, which makes it worth pinning with a test before it drifts.
Reviewing #179, @nnunley suggested:
It arrived with the approval rather than as a change request, and it asks for coverage of existing FOV behavior rather than of what #179 changed (an empty
:fovnow reads as uncomputed instead of as a real result). So #179 merged as approved, and the suggestion is filed here.The gap is real. As of 2026-08-07 no file under
xsofy/test/referencescompute-fov,has-clear-line?, ortransparent?. The shadowcasting inxsofy/fov.lgand the Bresenham line-of-sight interrain/has-clear-line?are both load-bearing for what the player and the AI can perceive, and neither has a test that puts something opaque between two points and checks that it occludes.What exists today tests the cache seam, not the geometry.
percept_test.lgcovers which FOV setentity-fovhands back, precomputed vs. computed on demand, player vs. NPC, and every case runs in an open carved room where everything can see everything. Acompute-fovthat ignored walls entirely would pass the current suite. Occlusion is also the part of FOV a player notices the moment it breaks, and the part most likely to break silently under a refactor of the octant casting.Suggested shape
percept_test.lgalready has aroom-worldhelper (a 10x10 stone room carved to1 1 8 8, player at[2 2]), andfire_test.lgestablishes the mechanism for placing a single blocking tile:So: carve the room,
tset!a wall segment spanning the middle, put an entity either side of it, and assert neither position appears in the other'sentity-fov. Pair it with an unobstructed control in the same room asserting they do see each other, otherwise the test still passes if FOV returns nothing at all.has-clear-line?needs the same coverage.terrain.lgdescribes it as the single home for logic that was triplicated acrossworld,ai, andpercept, which makes it worth pinning with a test before it drifts.