Ask: Switch render_worker_overlay to a stable per-worker identity (name + spawn_tick, or an explicit id) so sprite assignments survive future worker removal or insertion.
Expected files: scripts/main.gd
Problem:
render_worker_overlay keys its TextureRect sprites by the worker's position in the state.workers array (str(i)). The stale-key sweep correctly frees entries that fall off the end of the array, but it does not detect a mid-array insertion or removal: the surviving indices stay in active_indices and their sprites get reassigned to whichever worker now occupies that slot. Today this is latent because recruit_worker only appends, but any future feature that removes a worker (death, dismissal, demotion) would silently swap every other worker's sprite for the rest of the run.
The current code comment ("Keyed by worker array index (stable identity); names are not unique at 11+ workers.") acknowledges the names-are-not-unique problem but solves it with a key that is itself fragile.
Evidence:
scripts/main.gd — render_worker_overlay builds active_indices from range(workers.size()) and looks up worker_overlay_nodes[str(i)].scripts/colony_sim.gd — recruit_worker only appends; the comment in main.gd flags name collisions at 11+ workers.
Acceptance:
- Sprites are keyed by a worker identity that does not change when other workers are added or removed (e.g.
name + ":" + str(spawn_tick), or a synthetic id assigned at recruitment).
- Inserting a worker at the front of
state.workers in a test does not cause any other worker's sprite to be replaced.
- A regression test in
tests/ (or an existing render-worker test) asserts the mapping is stable across worker-list mutations.
Ask: Switch render_worker_overlay to a stable per-worker identity (name + spawn_tick, or an explicit id) so sprite assignments survive future worker removal or insertion.
Expected files: scripts/main.gd
Problem:
render_worker_overlaykeys its TextureRect sprites by the worker's position in thestate.workersarray (str(i)). The stale-key sweep correctly frees entries that fall off the end of the array, but it does not detect a mid-array insertion or removal: the surviving indices stay inactive_indicesand their sprites get reassigned to whichever worker now occupies that slot. Today this is latent becauserecruit_workeronly appends, but any future feature that removes a worker (death, dismissal, demotion) would silently swap every other worker's sprite for the rest of the run.The current code comment ("Keyed by worker array index (stable identity); names are not unique at 11+ workers.") acknowledges the names-are-not-unique problem but solves it with a key that is itself fragile.
Evidence:
scripts/main.gd—render_worker_overlaybuildsactive_indicesfromrange(workers.size())and looks upworker_overlay_nodes[str(i)].scripts/colony_sim.gd—recruit_workeronly appends; the comment inmain.gdflags name collisions at 11+ workers.Acceptance:
name + ":" + str(spawn_tick), or a synthetic id assigned at recruitment).state.workersin a test does not cause any other worker's sprite to be replaced.tests/(or an existing render-worker test) asserts the mapping is stable across worker-list mutations.