Fix a bug causing premature defeatism in the Bridges solver. Deducing
a better upper bound on the number of bridges leaving a given island
in a given direction was not counted as having 'done something'; so a
solver run could make several such deductions, but then terminate in
the belief that it hadn't achieved anything, when just going back
round the main solver loop would have enabled it to make further
deductions based on those new bounds.


git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9377 cda61777-01e9-0310-a592-d414129be87e
New puzzle! Or rather, new-ish, because this one has been lying around
in the 'unfinished' directory for a while, and has now been finished
up thanks to James Harvey putting in some effort and galvanising me to
put in the rest. This is 'Pearl', an implementation of Nikoli's 'Masyu'.

The code in Loopy that generates a random loop along grid edges to use
as the puzzle solution has been abstracted out into loopgen.[ch] so
that Pearl can use it for its puzzle solutions too. I've also
introduced a new utility module called 'tdq' (for 'to-do queue').


git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9379 cda61777-01e9-0310-a592-d414129be87e
Tweak right-click processing to be less finicky.


git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9381 cda61777-01e9-0310-a592-d414129be87e
It's a new year.
(It was a new year this time last year, too.)


git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9382 cda61777-01e9-0310-a592-d414129be87e
Trivial and silly patch to allow users to configure the Signpost
victory roll so that adjacent arrows rotate in opposite directions,
giving the impression that they're an interlocking field of gears.
Possibly even more brain-twisting than the original version :-)


git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9384 cda61777-01e9-0310-a592-d414129be87e
Fix default parameter assignment in Light Up when validating an
incomplete parameter string: if the user hand-types a game ID along
the lines of '18x10:stuff', we should not assume SYMM_ROT4 in the
resulting game_params, since it'll be failed by validate_params.


git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9386 cda61777-01e9-0310-a592-d414129be87e
The Light Up solver limits its recursion depth, so if it fails to find
a solution then it should not deduce that no solution exists. Change
wording of the error message returned from the Solve user action.


git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9387 cda61777-01e9-0310-a592-d414129be87e
Add comments suggesting some solver upgrades to Light Up (perhaps for
a new sub-recursive difficulty level?), inspired by a user emailing in
the game ID
18x10:gBc1b2g2e2d1b2c2h2e3c2dBd1g1bBb2b1fBbBb1bBgBd2dBi1h1c2b1dBe2bBdBb3cBg
which I was able to solve without backtracking by the use of these
techniques.


git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9388 cda61777-01e9-0310-a592-d414129be87e
Move a debug statement at the end of new_clues from the caller (just
after return) to the callee (just before). Might print something
useful in the soak-test context (where that debug statement will now
be printed and previously wasn't), but the main aim is to remove the
variable 'ngen' at the main call site, which triggered a set-but-not-
used warning if the debug statement that printed it was compiled out.


git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9392 cda61777-01e9-0310-a592-d414129be87e
Sort out a bit of confusion between mouse- and keyboard-driven drags
in Rectangles. Mouse drags now take priority - you can't start a
keyboard drag while the mouse is held down, and starting a mouse drag
instantly cancels an unfinished keyboard drag - and also I've fixed an
assertion failure which would come up if you had the keyboard cursor
visible at the end of a mouse drag (by pressing arrow keys while the
mouse was held down).


git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9393 cda61777-01e9-0310-a592-d414129be87e
Can now take the dual of a grid

Taking the dual of a grid creates a new grid with one vertex
for each face of the original and one face for each vertex. This
allows the easy introduction of a new grid type, the dual of the
octagonal grid, which is a square grid in which each square is split
into four triangles.

Of the grid types currently present, square is its own dual,
honeycomb is the dual of triangles, cairo is the dual of snub-squares,
kites is the dual of great-hexagonal, and the dodecagonal ones would
have vertices with twelve edges, probably not practical. The others
all have duals that would introduce new classes of puzzle.


git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9395 cda61777-01e9-0310-a592-d414129be87e
Added "dual" option to grid generators

It is now possible to produce duals of all grids.


git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9396 cda61777-01e9-0310-a592-d414129be87e
Added dual floret preset


git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9397 cda61777-01e9-0310-a592-d414129be87e
Fixed decoding bug for dual grids


git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9398 cda61777-01e9-0310-a592-d414129be87e
Arrgh! Revert r9395,r9396,r9397,r9398, all of which I just committed
by mistake in one go by running git-svn dcommit on the wrong branch.
Those were patches recently submitted by a user but which are not of
production quality (yet?) and I meant to keep them in my local
experimental repository. Sorry.


git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9399 cda61777-01e9-0310-a592-d414129be87e
David Nickerson reports that it's possible to lay a line over a 'no
line here' cross mark by dragging, and furthermore, that doing so puts
that grid edge into a stuck state that no UI action short of undo can
get it back out of. Fix drags to stop at crosses, and fix execute_move
to fault any move string that nonetheless somehow managed to try to
set a line over a cross without explicitly tagging it 'R'.


git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9400 cda61777-01e9-0310-a592-d414129be87e
Fix a couple of typos in messages.


git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9401 cda61777-01e9-0310-a592-d414129be87e
Don't try to run solver_killer_sums on a Killer cage with only one
square. It isn't equipped for it, and will try to handle it with the
4-square case and get confused. This can come up if the
DIFF_KINTERSECT pass before that split a cage, and will cause the
solver to miss valid solutions; e.g. 3x3kadu#802065940985372 would
generate an ambiguous puzzle before this change.


git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9402 cda61777-01e9-0310-a592-d414129be87e
Correct kdiff setting.


git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9403 cda61777-01e9-0310-a592-d414129be87e
David Nickerson reports odd behaviour involving a drag start point
persisting between separate mouse actions. Revamp all uses of the
ndragcoords field in an attempt to stamp that out: we now distinguish
between active drags (>0), a valid click but no drag yet (0), and a
totally invalid situation in which all mouse activity will be ignored
until the next fresh attempt (-1).


git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9405 cda61777-01e9-0310-a592-d414129be87e