fix(bots): roll between the nearest spots so a fleet stops sharing one #246

Merged

sickday merged 2 commits from fix/fisher-spot-spread into main 2026-08-19 11:20:54 +00:00

Conversation 0 Commits 2 Files changed 2 +98 -5

sickday commented 2026-08-19 10:19:18 +00:00

Owner

Copy link

The spot scan ended in Enum.min_by/3 on distance, which is a clone factory:
every fisher at the same water has the same scan, the same candidates and the
same answer, and min_by is first-wins on ties against a stable
MovementAuthority.nearby/3 order, so a tie cannot break the symmetry either.

Measured before touching it. Three fishers at Barbarian Village, sampled every
six seconds over twenty minutes: 47% of the ticks on which all three were
fishing had all three on one tile, 51% on two, and one tick in 161 on
three. Two of them held identical target indices for hundreds of ticks at a
stretch -- 132 both on 17905, 110 both on 17785, 107 both on 18180.

So take the nearest three workable spots and roll, which is the roll
Bot.Sites.choose/2 already makes between grounds and the spread
Bot.Sites.spot/2 already gives a fleet around a booth. The spreading was
written twice; this was the third place that needed it. Re-rolled on every
acquire rather than fixed per body, so a fleet keeps redistributing as spots
relocate under it.

Re-measured the same way: 22% of ticks on one tile, 75% on two. That is
the ceiling rather than a half-fix -- the water there carries exactly two
live spots inside the scan radius, on adjacent tiles, and three bots rolling
uniformly over two spots land on the same one 25% of the time by construction.
The observed 22% is that number. A cluster with one spot in it still shares,
which is what the game looks like anyway.

The test asserts the distribution rather than reading variety off the dice: it
seeds four spots, rolls sixty acquires, and requires both that more than one
index comes back and that the fourth -- the one outside the pool -- never
does. Checked against the old behaviour before keeping it, where it fails with
"every scan chose [32701], which is the argmin this roll replaced".

The spot scan ended in `Enum.min_by/3` on distance, which is a clone factory: every fisher at the same water has the same scan, the same candidates and the same answer, and `min_by` is first-wins on ties against a stable `MovementAuthority.nearby/3` order, so a tie cannot break the symmetry either. Measured before touching it. Three fishers at Barbarian Village, sampled every six seconds over twenty minutes: **47%** of the ticks on which all three were fishing had all three on **one tile**, 51% on two, and one tick in 161 on three. Two of them held identical target indices for hundreds of ticks at a stretch -- 132 both on 17905, 110 both on 17785, 107 both on 18180. So take the nearest three workable spots and roll, which is the roll `Bot.Sites.choose/2` already makes between grounds and the spread `Bot.Sites.spot/2` already gives a fleet around a booth. The spreading was written twice; this was the third place that needed it. Re-rolled on every acquire rather than fixed per body, so a fleet keeps redistributing as spots relocate under it. Re-measured the same way: **22%** of ticks on one tile, 75% on two. That is the ceiling rather than a half-fix -- the water there carries exactly **two** live spots inside the scan radius, on adjacent tiles, and three bots rolling uniformly over two spots land on the same one 25% of the time by construction. The observed 22% is that number. A cluster with one spot in it still shares, which is what the game looks like anyway. The test asserts the distribution rather than reading variety off the dice: it seeds four spots, rolls sixty acquires, and requires both that more than one index comes back and that the fourth -- the one outside the pool -- never does. Checked against the old behaviour before keeping it, where it fails with "every scan chose [32701], which is the argmin this roll replaced".

sickday added 1 commit 2026-08-19 10:19:18 +00:00

fix(bots): roll between the nearest spots so a fleet stops sharing one ... 73aa6cdbd9

The spot scan ended in `Enum.min_by/3` on distance, which is a clone factory:
every fisher at the same water has the same scan, the same candidates and the
same answer, and `min_by` is first-wins on ties against a stable
`MovementAuthority.nearby/3` order, so a tie cannot break the symmetry either.

Measured before touching it. Three fishers at Barbarian Village, sampled every
six seconds over twenty minutes: **47%** of the ticks on which all three were
fishing had all three on **one tile**, 51% on two, and one tick in 161 on
three. Two of them held identical target indices for hundreds of ticks at a
stretch -- 132 both on 17905, 110 both on 17785, 107 both on 18180.

So take the nearest three workable spots and roll, which is the roll
`Bot.Sites.choose/2` already makes between grounds and the spread
`Bot.Sites.spot/2` already gives a fleet around a booth. The spreading was
written twice; this was the third place that needed it. Re-rolled on every
acquire rather than fixed per body, so a fleet keeps redistributing as spots
relocate under it.

Re-measured the same way: **22%** of ticks on one tile, 75% on two. That is
the ceiling rather than a half-fix -- the water there carries exactly **two**
live spots inside the scan radius, on adjacent tiles, and three bots rolling
uniformly over two spots land on the same one 25% of the time by construction.
The observed 22% is that number. A cluster with one spot in it still shares,
which is what the game looks like anyway.

The test asserts the distribution rather than reading variety off the dice: it
seeds four spots, rolls sixty acquires, and requires both that more than one
index comes back and that the fourth -- the one outside the pool -- never
does. Checked against the old behaviour before keeping it, where it fails with
"every scan chose [32701], which is the argmin this roll replaced".

sickday added 1 commit 2026-08-19 11:20:50 +00:00

Merge branch 'main' into fix/fisher-spot-spread 240105fe6a

sickday merged commit 240105fe6a into main 2026-08-19 11:20:54 +00:00

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

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

Revenant/Server!246

No description provided.