simon-git: puzzles (main): Simon Tatham
Commits to Tartarus hosted VCS
tartarus-commits at lists.tartarus.org
Thu Jun 12 08:31:43 BST 2025
TL;DR:
47bd72c Flood: stop using params->ncolours to set state->ncolours.
Repository: https://git.tartarus.org/simon/puzzles.git
On the web: https://git.tartarus.org/?p=simon/puzzles.git
Branch updated: main
Committer: Simon Tatham <anakin at pobox.com>
Date: 2025-06-12 08:31:43
commit 47bd72ce83ac17ad9b3643b0ad67feb57cafc46f
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=47bd72ce83ac17ad9b3643b0ad67feb57cafc46f;hp=7fa03051562ee81e2a5371f8b3a6d0bb6e646aa0
Author: Simon Tatham <anakin at pobox.com>
Date: Thu Jun 12 08:18:54 2025 +0100
Flood: stop using params->ncolours to set state->ncolours.
In Flood, the number of colours in the grid is a parameter only needed
at generation time: once you have a concrete grid description, the
number of colours can be inferred from that. The number of colours
isn't encoded in the short params string that goes with a descriptive
game id.
Therefore, it's a mistake to validate that game id against
params->colours, because it might be set wrong! A game id such as
3x3:123456789,10 will be rejected by validate_desc on the grounds that
it was given the default params->colours value of 6, and didn't like
the grid containing higher-numbered colours than that.
Worse, passing in a random-seed game id _with_ a number of colours has
a related bug. If you pass in a game id like "5x5c10#123" on the Flood
_command line_, or via a URL fragment id in the web version, then
new_game_desc is called with the correct value params->colours=10, but
the subsequent new_game is given the _persistent_ params structure
from the midend, in which the generation-time parameters haven't been
copied from the ones in the game id. So new_game gets a game
description string generated with 10 colours, but a game_params
claiming 6 colours, and sets state->colours to 6. This means new_game
is given a desc that validate_desc _would_ have rejected, but it
didn't get the chance to! This is bound to cause _some_ trouble. In
fact the specific trouble occurs when game_redraw uses the colour
value state->ncolours (i.e. supposedly just out of range) internally,
to calculate which squares to mark as the auto-solver's next move:
that "out of range" value is also used within the grid, so squares
unexpectedly get marked with the "next move" circle even if you're not
using the auto-solver, and then assertions fail when you try to do
anything.
The solution is simply to ignore params->ncolours for all purposes
_except_ new_game_desc. validate_desc now doesn't care what colour
values you pass in for grid squares except for ensuring they're within
the _global_ limit arising from how many RGB values we've defined. And
new_game sets state->colours by looking for the largest colour id
mentioned in the grid (although I could equally sensibly have just set
it to MAXCOLOURS unconditionally).
flood.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
More information about the tartarus-commits
mailing list