Support YAML-configurable blue-coin checks and boathouse trades #1

Open
opened 2026-10-14 18:17:14 +00:00 by alaric · 0 comments
Owner

Implemented the original Sunshine APWorld YAML options for all 240 blue-coin checks and configurable boathouse trades. These are optional modes; existing 87-check seeds remain compatible.

Example YAML mode Blue Coin rewards Trades Active checks
Coin checks only full_shuffle 0 0 327
Coin checks and trades full_shuffle 120 12 339
Normal coins and trade checks trade_shines_only physical currency 12 99
Existing profile no_blue_coins 0 0 87

blue_coin_maximum accepts 0-240 and trade_shine_maximum accepts 0-24. The existing APWorld generator normalizes incompatible quantities. Full shuffle always has all 240 physical coin checks, independently of the reward quantity. The three new examples use 70 Shine items and have 247, 139 and 19 1-UP filler items respectively.

Source and candidate

  • Client/templates/tools: #2 (source 3959f9b; evidence ae31bc6).
  • Native game: alaric/sunshine-pc-port#1 (74ff06e).
  • Local portable candidate prepared: Sunshine-Archipelago-Blue-Coins-WIP-Windows-2026-10-14.zip, 57,871,425 bytes, SHA-256 b57a6ec544dc209ed3db834f358aa126ee8a00e32eda28a6e3fc0c799c17c61a.
  • The candidate includes the 327-check sample seed, all four YAML examples and PLAYTESTS.md. The original public wip-2026-10-14 release remains unchanged and does not support the new modes.

Verified

  • 17 Rust tests, formatting, Clippy, GUI build and 14 launcher/package tests passed.
  • All three examples generated with full original-world model reachability.
  • Real AP-server/production-bridge tests passed for all three modes and the legacy seed: all generated checks/rewards, duplicate checks, reconnect, process restart, spent-life persistence and goal reporting.
  • Full native build and eight shipped-method cases passed: all 240 coin mappings, duplicate pickup, currency authority, trade boundaries including 16/17/24, native card serialization/load/restore, vanilla and legacy progression/input/1-UP regression.
  • Exact portable ZIP extraction passed all 815 manifest hashes and embedded-Python first-run/resumed AP authentication. No game assets, player saves or private profiles are included.

Validation ownership and limits

Functional check/reward delivery, currency accounting, trade caps and replay belong in automation. The verified native/server results above cover those boundaries. The former SMS-BC01/02/03 manual cards are retired; no farming, repeated reload or full campaign is required from a person. Ordinary play is voluntary.

Actual native flag/save methods are exercised directly. Ordinary pickup collision, boathouse dialogue/scripts and normal menu save flow are not executed by those fixtures. Agents should investigate concrete technical gaps with targeted automation before requesting the smallest human observation that tools cannot reasonably settle, such as game feel or visible usability.

Current source PLAYTESTS.md supersedes the unchanged candidate ZIP's old cards. Trust the player to choose the matching save; no isolation exercise is required. Shared policy: Peliarch principle #36, validation backlog #14.

Requested by Alaric on 2026-10-14; options rather than a forced mode.

Validation-policy documentation is committed and pushed at 04ada0c in the existing client PR. The tested candidate ZIP is unchanged.

Implemented the original Sunshine APWorld YAML options for all 240 blue-coin checks and configurable boathouse trades. These are optional modes; existing 87-check seeds remain compatible. | Example | YAML mode | Blue Coin rewards | Trades | Active checks | |---|---|---:|---:|---:| | Coin checks only | `full_shuffle` | 0 | 0 | 327 | | Coin checks and trades | `full_shuffle` | 120 | 12 | 339 | | Normal coins and trade checks | `trade_shines_only` | physical currency | 12 | 99 | | Existing profile | `no_blue_coins` | 0 | 0 | 87 | `blue_coin_maximum` accepts 0-240 and `trade_shine_maximum` accepts 0-24. The existing APWorld generator normalizes incompatible quantities. Full shuffle always has all 240 physical coin checks, independently of the reward quantity. The three new examples use 70 Shine items and have 247, 139 and 19 1-UP filler items respectively. ## Source and candidate - Client/templates/tools: https://git.peliarch.ca/alaric/sunshine-archipelago/pulls/2 (source 3959f9b; evidence ae31bc6). - Native game: https://git.peliarch.ca/alaric/sunshine-pc-port/pulls/1 (74ff06e). - Local portable candidate prepared: `Sunshine-Archipelago-Blue-Coins-WIP-Windows-2026-10-14.zip`, 57,871,425 bytes, SHA-256 `b57a6ec544dc209ed3db834f358aa126ee8a00e32eda28a6e3fc0c799c17c61a`. - The candidate includes the 327-check sample seed, all four YAML examples and `PLAYTESTS.md`. The original public `wip-2026-10-14` release remains unchanged and does not support the new modes. ## Verified - 17 Rust tests, formatting, Clippy, GUI build and 14 launcher/package tests passed. - All three examples generated with full original-world model reachability. - Real AP-server/production-bridge tests passed for all three modes and the legacy seed: all generated checks/rewards, duplicate checks, reconnect, process restart, spent-life persistence and goal reporting. - Full native build and eight shipped-method cases passed: all 240 coin mappings, duplicate pickup, currency authority, trade boundaries including 16/17/24, native card serialization/load/restore, vanilla and legacy progression/input/1-UP regression. - Exact portable ZIP extraction passed all 815 manifest hashes and embedded-Python first-run/resumed AP authentication. No game assets, player saves or private profiles are included. ## Validation ownership and limits Functional check/reward delivery, currency accounting, trade caps and replay belong in automation. The verified native/server results above cover those boundaries. The former SMS-BC01/02/03 manual cards are retired; no farming, repeated reload or full campaign is required from a person. Ordinary play is voluntary. Actual native flag/save methods are exercised directly. Ordinary pickup collision, boathouse dialogue/scripts and normal menu save flow are not executed by those fixtures. Agents should investigate concrete technical gaps with targeted automation before requesting the smallest human observation that tools cannot reasonably settle, such as game feel or visible usability. Current source `PLAYTESTS.md` supersedes the unchanged candidate ZIP's old cards. Trust the player to choose the matching save; no isolation exercise is required. Shared policy: [Peliarch principle #36](https://git.peliarch.ca/alaric/peliarch/issues/36), [validation backlog #14](https://git.peliarch.ca/alaric/peliarch/issues/14). Requested by Alaric on 2026-10-14; options rather than a forced mode. Validation-policy documentation is committed and pushed at `04ada0c` in the existing client PR. The tested candidate ZIP is unchanged.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
alaric/sunshine-archipelago#1
No description provided.