built building should appear on the map #11

New issue

Closed

opened 2026-08-11 12:39:11 +00:00 by metaheavens · 1 comment

metaheavens commented

2026-08-11 12:39:11 +00:00

Owner

No description provided.

metaheavens commented

2026-08-11 13:29:22 +00:00

Author

Owner

Done. Buildings the player has placed now appear on the world map.

Buildings are placed freely in space rather than being tied to a chunk, so they could not ride along with the existing chunk markers and get their own pass in WorldMapContent._draw(). Each type is drawn as its own shape and colour, mirroring Building.gd's own constants so a marker reads as the same building you built:

Mothership - green hexagon (Color(0.45, 0.9, 0.55))
Ship crafter - amber diamond (Color(1.0, 0.72, 0.25))
Command center - lavender square (Color(0.55, 0.6, 1.0))

The positioning step is factored out into building_markers(), which turns GameState.buildings into map-local marker data, so a headless test can check it - --headless has no GPU and draws no pixels, so there is nothing to assert on in _draw() itself.

Test

tests/test_map_building_markers.gd checks that nothing built means no markers (so a passing count is not just "always 3"), that every placed building produces exactly one marker, that markers land at the building's world position scaled into map space, and that the three types are actually told apart by colour.

I mutation-tested the assertions rather than trusting that they pass:

mutation	result
feature absent entirely	FAIL (nonexistent function)
all three types drawn one colour	FAIL (building types are not visually distinct)
marker positions not scaled into map space	FAIL (marker is not where the building is)

Looked at it

Headless renders no pixels, so a test cannot tell whether a marker is visible. tests/_marker_preview.tscn + tests/screenshot.sh render the map for real (Xvfb + Mesa softpipe) - all three markers show up distinctly against the chunk grid, next to the fleet's cyan triangle.

One fix along the way: screenshot.sh now clears a stale /tmp/.X99-lock. A run killed mid-screenshot leaves the lock behind, Xvfb then silently refuses to claim :99, and it resurfaces much later as Godot's misleading X11 Display is not available.

Full suite: 40/40 passing.

Done. Buildings the player has placed now appear on the world map. Buildings are placed freely in space rather than being tied to a chunk, so they could not ride along with the existing chunk markers and get their own pass in `WorldMapContent._draw()`. Each type is drawn as its own shape and colour, mirroring `Building.gd`'s own constants so a marker reads as the same building you built: - **Mothership** - green hexagon (`Color(0.45, 0.9, 0.55)`) - **Ship crafter** - amber diamond (`Color(1.0, 0.72, 0.25)`) - **Command center** - lavender square (`Color(0.55, 0.6, 1.0)`) The positioning step is factored out into `building_markers()`, which turns `GameState.buildings` into map-local marker data, so a headless test can check it - `--headless` has no GPU and draws no pixels, so there is nothing to assert on in `_draw()` itself. ## Test `tests/test_map_building_markers.gd` checks that nothing built means no markers (so a passing count is not just "always 3"), that every placed building produces exactly one marker, that markers land at the building's world position scaled into map space, and that the three types are actually told apart by colour. I mutation-tested the assertions rather than trusting that they pass: | mutation | result | |---|---| | feature absent entirely | FAIL (nonexistent function) | | all three types drawn one colour | FAIL (building types are not visually distinct) | | marker positions not scaled into map space | FAIL (marker is not where the building is) | ## Looked at it Headless renders no pixels, so a test cannot tell whether a marker is *visible*. `tests/_marker_preview.tscn` + `tests/screenshot.sh` render the map for real (Xvfb + Mesa softpipe) - all three markers show up distinctly against the chunk grid, next to the fleet's cyan triangle. One fix along the way: `screenshot.sh` now clears a stale `/tmp/.X99-lock`. A run killed mid-screenshot leaves the lock behind, Xvfb then silently refuses to claim `:99`, and it resurfaces much later as Godot's misleading `X11 Display is not available`. Full suite: **40/40 passing**.