SirStone/SirRoboGarage
1
0
Fork 0
Code Issues 28 Pull Requests Actions Projects Releases Wiki Activity

EvoBot weight checkpointing: never lose the best per-enemy weights #88

New Issue
Closed
opened 2026-08-26 06:55:24 +02:00 by SirStone · 1 comment
SirStone commented 2026-08-26 06:55:24 +02:00
Owner
Copy Link
Copy Source

Destination

A locked save-policy for EvoBot: WHEN weights are persisted and WHICH weights win on disk (best-so-far per enemy), such that interrupting a 100–1000+ round training match never loses the best result achieved so far. Output is a decided policy handed off for implementation — no code in this effort.

Notes

Domain: EvoBot GA gun (Nim, Robocode Tank Royale). Consult repo CONTEXT.md and ADR 0001 (load order per-opponent → global → init).
Tracker conventions adopted for this map (gaps in repo docs):

  • No native dependencies → blocking edges written as blocked-by: #N in ticket body.
  • No issue-assignment tool → claiming = post comment claimed by <who>, <date> (latest claim comment wins) BEFORE working a ticket.
  • Child tickets reference this map via part-of: #<this index>.
    Default mode: plan, don't do — tickets resolve decisions, not slices of build.

Decisions so far

  • Which save moments can EvoBot actually act on? — only onRoundEnded fires reliably every round regardless of survival/abort; onGameEnded is clean-end-only bonus flush; no abort event ever reaches bots (server sends game-aborted to observers/controllers only), so Ctrl-C/server-death leaves at best a best-effort client-side onDisconnected hook → periodic round-end saves are mandatory.
  • What does "better" mean for best-so-far weights? — GA internal champion fitness, per generation, single-observation replace, no cold-start case (global bootstraps).
  • Lock the trigger set and write rules — single save point (onRoundEnded); channel-drained snapshot; fitness-header-gated replace (legacy = −inf); atomic rename; weights live beside the running binary; load order unchanged.

Not yet specified

(none — remaining open points folded into "Lock the trigger set and write rules")

Out of scope

  • Checkpoint history/versioning beyond the single current-best file per enemy (+ global) — one best slot, no undo trail.
  • Migrating legacy files (poisoned bot_N.weights, old global.weights).
  • Deploy/build hygiene (stale-binary class of incidents) — separate effort.
  • Evo-thread lifecycle leak across games.
## Destination A locked save-policy for EvoBot: WHEN weights are persisted and WHICH weights win on disk (best-so-far per enemy), such that interrupting a 100–1000+ round training match never loses the best result achieved so far. Output is a decided policy handed off for implementation — no code in this effort. ## Notes Domain: EvoBot GA gun (Nim, Robocode Tank Royale). Consult repo CONTEXT.md and ADR 0001 (load order per-opponent → global → init). Tracker conventions adopted for this map (gaps in repo docs): - No native dependencies → blocking edges written as `blocked-by: #N` in ticket body. - No issue-assignment tool → claiming = post comment `claimed by <who>, <date>` (latest claim comment wins) BEFORE working a ticket. - Child tickets reference this map via `part-of: #<this index>`. Default mode: plan, don't do — tickets resolve decisions, not slices of build. ## Decisions so far - [Which save moments can EvoBot actually act on?](https://git.fossellini.top/SirStone/SirRoboGarage/issues/90) — only `onRoundEnded` fires reliably every round regardless of survival/abort; `onGameEnded` is clean-end-only bonus flush; no abort event ever reaches bots (server sends game-aborted to observers/controllers only), so Ctrl-C/server-death leaves at best a best-effort client-side `onDisconnected` hook → periodic round-end saves are mandatory. - [What does "better" mean for best-so-far weights?](https://git.fossellini.top/SirStone/SirRoboGarage/issues/89) — GA internal champion fitness, per generation, single-observation replace, no cold-start case (global bootstraps). - [Lock the trigger set and write rules](https://git.fossellini.top/SirStone/SirRoboGarage/issues/91) — single save point (onRoundEnded); channel-drained snapshot; fitness-header-gated replace (legacy = −inf); atomic rename; weights live beside the running binary; load order unchanged. ## Not yet specified (none — remaining open points folded into "Lock the trigger set and write rules") ## Out of scope - Checkpoint history/versioning beyond the single current-best file per enemy (+ global) — one best slot, no undo trail. - Migrating legacy files (poisoned `bot_N.weights`, old `global.weights`). - Deploy/build hygiene (stale-binary class of incidents) — separate effort. - Evo-thread lifecycle leak across games.
SirStone added the wayfinder:map label 2026-08-26 06:55:24 +02:00
SirStone commented 2026-08-28 20:50:55 +02:00
Author
Owner
Copy Link
Copy Source

All 3 checkpointing decision tickets closed, no fog remaining. Map complete. Closing.

All 3 checkpointing decision tickets closed, no fog remaining. Map complete. Closing.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
ready-for-agent
wayfinder:grilling
Wayfinder design question to grill
 wayfinder:map
Wayfinder map issue
 wayfinder:prototype
wayfinder:research
Wayfinder research question
 wayfinder:task
Wayfinder implementation task
No Label wayfinder:map
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
SirStone
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: SirStone/SirRoboGarage#88
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?