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