Allow polygon start boxes

[burnhamrobertp]

Work done

Adds polygon and Catmull-Rom spline startbox rendering to the battle map preview. Maps that ship 3+ vertex polygons in their startboxesSet (via the maps-metadata schema PR) now render their actual region shape as an SVG overlay instead of collapsing to a bounding-box rectangle.

Reworks the previously-closed #570 from master. That earlier attempt loaded polygon configs directly from .sd7 archives via Fengari Lua evaluation.

• New src/renderer/utils/spline-tessellation.ts — TypeScript port of common/lib_spline.lua (game-side), LuaMenu/configs/gameConfig/byar/lib_spline.lua (Chobby), and the in-line tessellator in the Rowy editor. Identical inputs produce vertex-identical output across all four consumers, so the lobby preview, the Chobby preview, and the in-game render of the same startbox can never visually disagree.
• src/main/content/maps/map-metadata.ts — added optional strength?: number to StartBoxPoly for spline anchors. Mirrors the schema in maps-metadata#615.
• src/main/content/maps/box-utils.ts — spadsPointsToLTRBPercent accepts N-point polygons (computes bounding box across all vertices). Removed dead pointsToXYWH helper that had been unused since introduction in 92f0f66.
• src/renderer/utils/start-boxes.ts — spadsBoxToStartBox accepts N-point polygons; the existing min/max math already handled N points correctly, only the length-2 throw blocked it.
• src/renderer/components/maps/MapBattlePreview.vue — SVG polygon overlay with pointer-events: none, viewBox="0 0 200 200" matching the schema's coordinate space. When the active preset has any polygon-shaped startboxes, the rect-div drag handles are suppressed (read-only) — matching the BYAR-Chobby#1184 behaviour AntlerForce approved. Switching to a custom preset re-enables drag/resize.

Setup

Until beyond-all-reason/maps-metadata#615 merges and Rowy starts populating polygon vertex data, the only way to drive this end-to-end through the live data pipeline is via a custom build of maps-metadata that emits a lobby_maps.validated.json with 3+ point polys. Once that PR merges, polygon and spline data will flow through automatically.

For local testing today, manually edit a map's entry in your local lobby_maps.validated.json cache to insert 3+ point polys (with optional strength fields).

Related PRs

• Core Game - Polygon startboxes via mapmetadata modoptions Beyond-All-Reason#7513
• Chobby Lobby - Polygon startbox infrastructure (rendering, encoder, modoption injection) BYAR-Chobby#1184
• Rowy Fork - Add polygon startbox column type p2004a/rowy#1
• Maps-Metadata - Allow polygon and spline startboxes alongside legacy rectangles maps-metadata#615

AI / LLM usage statement

Assisted by GitHub Copilot (Claude Opus 4.7). Used for PR authoring, refactoring, and test scaffolding.

[geekingfrog]

I don't have a lobby_maps.validated.json file on my setup, where is it supposed to be and how do I get it?

Also, do you actually read the PR description when you create it? I find it's largely useless, especially the "summary of changes" file by file, that's what the diffs are for.
There are some useful info after, but it's so easy to glaze over it because of all the slop before.
That also gives off a very strong vibe of "I can't be arsed with summarizing my changes for reviewing, gl hf suckers"

[burnhamrobertp]

I don't have a lobby_maps.validated.json file on my setup, where is it supposed to be and how do I get it?

It should download automatically as part of the preload; the code is in maps.service.ts ; I don't believe it gets downloaded to disk, though, its probably in the IndexedDB

edit: I just double-checked, you won't see it in the network panel because the fetch occurs via the IPC (which runs via node). You can verify that its occurred, however, by checking Application -> Storage -> IndexDB -> BarLobby -> Maps

---

Also, do you actually read the PR description when you create it? I find it's largely useless, especially the "summary of changes" file by file, that's what the diffs are for. There are some useful info after, but it's so easy to glaze over it because of all the slop before. That also gives off a very strong vibe of "I can't be arsed with summarizing my changes for reviewing, gl hf suckers"

So yes, both when I have the agent summarize for me on a PR I'm putting in, but also yes when I look at others' work. Its where I first found I liked the pattern. In this instance the summary of changes is probably a bit too long and I should've trimmed it up, given that the changes are only +222 -23. Generally one of the things I'm doing when reviewing is looking at how all the changes fit together to achieve the stated changed that the PR is for, and that's easier to do up front on the PR description so that the review isn't starting from naught. Sometimes I'll do it by commit, other times by changed file, or (if its simple enough) just via a few sentences (if the description wasn't enough).

I understand the notion you're referring to; certainly I've seen the usage of AI tooling to be along that vein, but its not how I think of it.

[Hectate]

Looks good from this point, but we will have to do a lot of validation once the rest of the pipeline is working properly.