simon-git: puzzles (master): Simon Tatham

[Commits to Tartarus CVS repository.]

TL;DR:
  d60e348 Format Palisade solve-type moves in sensible ASCII.
  13b67b9 Fix loophole in Palisade completion checker.

Repository:     git://git.tartarus.org/simon/puzzles.git
On the web:     http://tartarus.org/~simon-git/gitweb/?p=puzzles.git
Branch updated: master
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2015-11-03 07:08:56

commit d60e348aae16e718e1e7cc2b6e090956eb7e4b52
web diff http://tartarus.org/~simon-git/gitweb/?p=puzzles.git;a=commitdiff;h=d60e348aae16e718e1e7cc2b6e090956eb7e4b52;hp=ffe8639619dbccd838c5b226f84d4cf0eb99b69d
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Nov 3 06:56:47 2015 +0000

    Format Palisade solve-type moves in sensible ASCII.
    
    The solve move stored in 'aux' by new_game_desc consists of printable
    characters in the range '@' to 'O', each representing a 4-bit bitmap
    of edges around a cell. But the one generated on the fly by
    solve_game() was missing out the 0x40 bit and just returning
    characters in the range ^@ to ^O - which would not only have been
    horrible if you found such a string in a save file, but also meant
    that a game with any completely borderless square would have a
    solution move string terminating early due to the ^@, causing
    execute_move() to reject it.
    
    Example: ./palisade --test-solve --generate 1 5x5n5#12345-37 now
    succeeds, where previously it failed an assertion.

 palisade.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

commit 13b67b9d09faf3440c0b96356d16ce841faa677f
web diff http://tartarus.org/~simon-git/gitweb/?p=puzzles.git;a=commitdiff;h=13b67b9d09faf3440c0b96356d16ce841faa677f;hp=d60e348aae16e718e1e7cc2b6e090956eb7e4b52
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Nov 3 06:45:49 2015 +0000

    Fix loophole in Palisade completion checker.
    
    A user pointed out that if you construct a 'solution' in which no clue
    square has too _many_ borders but at least one has too few, and then
    bring those clues up to their count by adding extra stray border lines
    _inside_ a connected component (avoiding actually dividing any
    component completely into two), then the game checker treats that as
    solved for victory-flash purposes, on the grounds that (a) the grid is
    divided into components of the right size and (b) all clues are
    satisfied.
    
    A small example is 4x4n4:22a2b2c33, with the non-solution of dividing
    the grid into four 2x2 square blocks and then adding a spurious extra
    edge between the two 3 clues. The old Palisade completion check would
    flash for victory _at the same time_ as highlighting the spurious edge
    in COL_ERROR.
    
    Fixed by enforcing in is_solved() that every border line must separate
    two distinct connected components.

 palisade.c |   32 +++++++++++++++++++++++++++++++-
 1 file changed, 31 insertions(+), 1 deletion(-)