Skip to content

Workers crossing a neighbouring room keep working in their own - #40

Merged
ForkedInTime merged 2 commits into
alphafrom
fix/work-room-step-off
Oct 23, 2026
Merged

ForkedInTime merged 2 commits into
alphafrom
fix/work-room-step-off

Conversation

@ForkedInTime

Copy link
Copy Markdown
Owner

A worker walking between spots in its room sometimes crosses a slab of another room. On the map in the stable 5660 log from 2026-10-19 (map30117) a bridge runs through the middle of the training room, and the workshop touches the training room. The job check looked only at the room under the creature, so it saw a BRIDGE and the worker quit its job: training: Room BRIDGE index 65 is not valid ROOM_ROLE_TRAIN_EXP and manufacturing: Room TRAINING index 16 ..., about a hundred times in that log. Most were imps the player had dropped in to train, who then wandered off. Upstream has the same check. The fix in 1863914 covered stepping off onto bare floor only.

What was happening: a probe build of 5660 logged each quit on a copy of the player's save. Every one had its moveto position inside the room it was enrolled in, one slab away: a trainee walking from one side of the bridge to the other.

The change:

  • get_room_creature_works_on() returns the room the creature works in (work_room_id) while the creature is heading for a spot in it.
  • Otherwise nothing changes. A creature carried or teleported elsewhere, or with no work room (a full room turns workers away, so work_room_id can be 0), is judged by the room under it as before.
  • The training partner checks use the same lookup, so a partner crossing the bridge is not "pretending to be in room" and is not taken to have left.
  • The training-post and workshop-post searches take the room the worker works in. They used to look it up under the creature, and with the worker now allowed to stand on the bridge they would have searched the bridge.
  • The temple's per-turn check is the same case and uses the same lookup.

A second commit turns creature_going_to_safety_for_toking's "Couldn't get a flee position" ERRORLOG (16 in the same log) into SYNCDBG(8), as the combat flee path already logs it. The imp rests where it stands, as before.

Measured:

  • The player's saves: copies of fx1g0004 and fx1g0005, on a 5660 build and on 5660 with this change (plus 1863914, which it builds on), 40000 turns each. Every 2500 turns 12 imps were put into the training room, which is how the player used it.
    • fx1g0005: 9 quits on 5660, 0 with the change.
    • fx1g0004: 37 quits on 5660, 0 with the change.
    • "Received nonexisting room" went 1 and 12 to 0 (that is 1863914's part).
  • A staged room on alpha: a U-shaped training room around a three-slab bridge on keeporig level 1 (qa-harness/stepoff_stage_1019.py), 8 trainees, 240 s.
    • alpha 02dd676: 8 quits. One trainee was still training at 15 s, none after; all stayed at level 1; 117 gold spent on training.
    • this branch: no quits. All 8 were still training at 30 s, all reached level 2; 1710 gold spent.
  • Regression: on the 2026-10-23 alpha candidate (this branch merged with the 10-19 sync): 35/35 level starts in levels_sweep, qa_sync_check 12/12, qa_new all pass, 300 s soaks on levels 10 and 20 alive with no new warning kinds. On its own base the sweep of alpha 02dd676 was 35/35; the branch's own sweep there was cut short and not repeated, since the candidate covers it.
  • Build and tests: a clean distcc build has no warnings, tests/run.sh passes, and the save format is unchanged (sizeof(struct Game) 53384602).

Not tested: prisons, torture rooms, guard posts, libraries and lairs next to another room. They use the same lookup but no log showed them. Multiplayer was not tested either; the change uses only game state, so both sides compute the same thing.

… own

A worker walking between spots in its room sometimes crosses a slab of
another room: a bridge through the middle of a training room, the training
room beside the workshop. get_room_creature_works_on() looked only at the
room under the creature, so the job check saw a BRIDGE and the worker quit:
"training: Room BRIDGE index 65 is not valid ROOM_ROLE_TRAIN_EXP" about a
hundred times in a stable 5660 log, most of them imps the player had dropped
in to train, plus workshop workers stepping onto the training room. A probe
on the player's own save showed every one of them with its moveto position
inside the room it was enrolled in, one slab from it.

The room it works in (work_room_id) now wins while the creature is heading
for a spot in it. Otherwise nothing changes: a creature carried or teleported
elsewhere, or with no work room (a full room turns workers away), is judged
by the room under it as before. The training partner checks use the same
lookup, so a partner crossing the bridge is not "pretending to be in room"
or taken to have left, and the training-post and workshop-post searches take
the room the worker works in instead of looking it up under the creature:
with the worker now allowed to stand on the bridge they would otherwise
search the bridge. The temple's per-turn check is the same case.

Measured on copies of the player's map30117 saves, a 5660 build against 5660
with this change (and 1863914, which it builds on), 40000 turns each with
12 imps put into the training room every 2500 turns: 9 and 37 such quits on
5660, none with the change. A staged U-shaped training room around a bridge
on keeporig level 1 (alpha, 240 s, 8 trainees): 8 quits, every trainee gone
within 30 s at level 1; with the change none, all 8 reached level 2.
creature_going_to_safety_for_toking() logged an ERRORLOG whenever a hurt imp
had no lair and no route to its heart, 16 times in a stable 5660 log. The imp
then rests where it stands, which is the right thing to do; the combat flee
path already logs the same situation at SYNCDBG(8). Now this one does too.
@ForkedInTime
ForkedInTime merged commit 0374bb9 into alpha Oct 23, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant