When you drag group elements around, previous dividers are meant to
dissolve whenever the same two elements are no longer on each side of
it. One case in which this didn't happen was that of dragging an
element from the left of a divider to the far right column - the
divider became invisible, but would then startlingly reappear if you
drag that element back to the left of whatever it was left of before.
[originally from svn r10051]
puzzle backend function which ought to have it, and propagate those
consts through to per-puzzle subroutines as needed.
I've recently had to do that to a few specific parameters which were
being misused by particular puzzles (r9657, r9830), which suggests
that it's probably a good idea to do the whole lot pre-emptively
before the next such problem shows up.
[originally from svn r9832]
[r9657 == 3b250baa02a7332510685948bf17576c397b8ceb]
[r9830 == 0b93de904a98f119b1a95d3a53029f1ed4bfb9b3]
new_desc. Oddities in the 'make test' output brought to my attention
that a few puzzles have been modifying their input game_params for
various reasons; they shouldn't do that, because that's the
game_params held permanently by the midend and it will affect
subsequent game generations if they modify it. So now those arguments
are const, and all the games which previously modified their
game_params now take a copy and modify that instead.
[originally from svn r9830]
midend_status(), and given it three return codes for win, (permanent)
loss and game-still-in-play. Depending on what the front end wants to
use it for, it may find any or all of these three states worth
distinguishing from each other.
(I suppose a further enhancement might be to add _non_-permanent loss
as a fourth distinct status, to describe situations in which you can't
play further without pressing Undo but doing so is not completely
pointless. That might reasonably include dead-end situations in Same
Game and Pegs, and blown-self-up situations in Mines and Inertia.
However, I haven't done this at present.)
[originally from svn r9179]
state is in a solved position, and a midend function wrapping it.
(Or, at least, a situation in which further play is pointless. The
point is, given that game state, would it be a good idea for a front
end that does that sort of thing to proactively provide the option to
start a fresh game?)
[originally from svn r9140]
elements to toggle thick lines in the grid. Helps to delineate
subgroups and cosets, so it's easier to remember what you can
legitimately fill in by associativity.
(I should really stop fiddling with this game's UI; it's far too silly.)
[originally from svn r9084]
much easier to keep track of things if, once you've identified a
cyclic subgroup, you can move it into a contiguous correctly ordered
block.
[originally from svn r9075]
immediately obvious which element of the group is the identity - at
least two elements including the identity have their rows and
columns completely blanked.
[originally from svn r8810]
you are given a partially specified Cayley table of a small finite
group, and must fill in all the missing entries using both Sudoku-
style deductions (minus the square block constraint) and the group
axioms. I've just thrown it together in about five hours by cloning-
and-hacking from Keen, as much as anything else to demonstrate that
the new latin.c interface really does make it extremely easy to
write new Latin square puzzles.
It's not really _unfinished_, as such, but it is just too esoteric
(not to mention difficult) for me to feel entirely comfortable with
adding it to the main puzzle collection. I can't bring myself to
throw it away, though, and who knows - perhaps a university maths
department might find it a useful teaching tool :-)
[originally from svn r8800]
