Polygon startbox infrastructure (rendering, encoder, modoption injection)

[burnhamrobertp]

The Chobby side of polygon startboxes, to go with the game PR #7513.

It renders polygon-shaped startboxes on the minimap (skirmish and multiplayer), and for skirmish it also encodes the polygon into the mapmetadata_startboxes_set modoption the game reads, so the launched game enforces the real shape rather than just a bounding rectangle. A small Catmull-Rom spline helper is ported from the game so the curves Chobby draws match the ones the game draws. It also drops the old map-archive startbox loading (the ZK-style shim), matching the game PR.

Most of the polygon rendering stays dormant for now - the polygon data doesn't flow until maps-metadata#615 ships, which puts the encoded set in each map's mapDetails.lua entry as a StartboxesSet field for Chobby to decode. Until then rectangles render and edit as before. It's also fine with the game PR landing first - an older game ignores the unknown modoptions, and a polygon-aware game with no polygon data falls back to the rectangle.

Multiplayer uses the same mapmetadata_startboxes_set, set per map by the server (SPADS/teiserver) rather than the client. Custom boxes stay rectangles - the drag-edit interface is untouched and there's deliberately no polygon-drawing tool (per @AntlerForce) - but they're now also sent to the game as a mapmetadata_startbox_override modoption, so the game enforces a player's manual boxes over the map's default set instead of replacing them with it. It's emitted as the boxes change and cleared when switching back to default boxes; !addbox/!split still drive the engine rectangles and the override just rides alongside as an opaque base64 value, its !bSet hidden from chat so it stays as quiet as !addbox. Before the server actually sets the set in MP (also maps-metadata#615) manual boxes already work via the engine rectangles and the override just mirrors them; once the set is live it's what keeps them winning. Needs SPADS to allow the modoption, which is spads_config_bar#224 (merged). This is the "why not both" resolution from the maps-metadata#605 discussion.

Related:

• Game: Polygon startboxes via mapmetadata modoptions Beyond-All-Reason#7513
• New lobby: Allow polygon start boxes bar-lobby#574 (merged) and Send polygon startboxes to the game bar-lobby#601 (follow-up)
• SPADS config: Allow the lobby to set the startbox override modoption spads_config_bar#224 (merged)
• Maps-metadata: Allow polygon and spline startboxes alongside legacy rectangles maps-metadata#615
• Rowy: Add polygon startbox column type p2004a/rowy#1
• Design discussion: Support polygon startboxes through the Rowy pipeline maps-metadata#605

Assisted by Claude Code (Opus 4.8); all code reviewed.

[burnhamrobertp]

[burnhamrobertp]

There may be a better map to test with than Cirolata, as BAR's version (1.02) has bad polygon startboxes defined; and uploading the 1.03 version that I downloaded from Zero-K and modified isn't an option due to archive size.

[burnhamrobertp]

On the assumption that this (related) PR beyond-all-reason/Beyond-All-Reason#7516 is approved (I can't see a reason why it shouldn't; these are codepaths that have been dead for years), I'm going to modify this pull request to remove the modconfig support.

[AntlerForce]

Is this ready to be merged?

[burnhamrobertp]

The only thing I wasn't sure about @AntlerForce is that because Chobby (nor new-lobby for that matter) has a UX that even comes close to editing polygon start boxes (let alone the polygon splines I added support for in d3d3f07), if there are polygon start boxes the ability to resize them is disabled. You would need to change the dropdown off of "Default Startboxes". I didn't know if this would be a problem, once we add support end-to-end and the polygon start boxes start (in theory) showing in multiplayer lobbies (provided I understand the infrastructure correctly)

[AntlerForce]

I don't have any desire to add polygonal editing support to chobby. I'm fine with this as long as it doesn't break the current interface for user-setting startboxes.

[burnhamrobertp]

Then no I don't believe there was anything left incomplete on this branch. It can be merged in whenever; until the rowy changes, this will only effect change in skirmish mode and even then only for maps with polygon start boxes already defined in them

[burnhamrobertp]

Fixed support for multiplayer lobbies as well as the "Add startbox" button when the default startboxes are polygon-based (previously it would do nothing, now it converts all polygon startboxes to rectangular and allows you to edit them as you can normally)

[burnhamrobertp]

@p2004a much about this PR was out of date, based on the progress of the bar-game repo, but I've been bringing it in-line with the above commits. One thing that still wasn't clear, how would we want to get the start box data into chobby after these changes and the support for poly start boxes is in?

Do we stick with the derived file format (savedBoxes.dat)? Or switch to using lobby_maps.validated.json (same as bar-lobby)? Or some other option?

lobby_maps.validated.json from maps-metadta seems the right approach to me, but I'm not certain; largely this is because I'm not sure which path will have the fewest complications. i.e. I'm not sure if sticking with the derived file format is then going to be problematic somewhere in the intersection with SPADS or whatnot, since the current version of savedBoxes.dat is in a SPADS-format

[burnhamrobertp]

Flagging for posterity: not producing the mapmetadata_startbox_override modoption from Chobby is intentional, not an oversight.

Custom startboxes here stay the normal rectangles you set through the existing interface (including the polygon -> rectangle conversion when you edit a polygon preset), which is the behavior we wanted to keep working. The override is how the new lobby hands custom areas to the game; doing the same from Chobby would mean reworking the !addbox / !split flow to push an encoded value through SPADS instead of the usual start rectangles. That doesn't seem worth it, and it lines up with the game-PR discussion that extending SPADS for this doesn't make much sense.

If a server-provided set modoption (mapmetadata_startboxes_set) ever clashes with manually-set boxes, the cleaner fix seems to live on the SPADS side - clear the set when boxes are set manually - rather than having the client generate an override.

So Chobby's scope stays: render the polygon presets (the set) and rect-convert for custom edits. The override is a new-lobby concern.

[p2004a]

If a server-provided set modoption (mapmetadata_startboxes_set) ever clashes with manually-set boxes, the cleaner fix seems to live on the SPADS side - clear the set when boxes are set manually - rather than having the client generate an override.

This PR is not mergable without resolution of this. I do not know at all from top of my head if doing what you want to do SPADS side is cleanly/easily achievable, you need to figure this our or change design in this PR. Maybe it's indeed trivial. One of the points of design was that SPADS doesn't care.

[burnhamrobertp]

@p2004a the spads config change (already merged) and the 43f8aa6 changes should address the override codepath. This keeps the established desire that SPADS doesn't care.

[AntlerForce]

I'm content to merge this if @p2004a is satisfied with the addressing of the issue mentioned above.