aboutsummaryrefslogtreecommitdiff
path: root/html
diff options
context:
space:
mode:
authorSimon Tatham <anakin@pobox.com>2016-02-24 19:22:57 +0000
committerSimon Tatham <anakin@pobox.com>2016-02-24 19:22:57 +0000
commit24848706edfdd1db1f97e3681d7ff52bec2fa575 (patch)
treef2b0024fe8604fb0ef4cfd3a9440e776c2d6c691 /html
parent755c3d5277262739e8beb03da3649e7f4d53e915 (diff)
downloadpuzzles-24848706edfdd1db1f97e3681d7ff52bec2fa575.zip
puzzles-24848706edfdd1db1f97e3681d7ff52bec2fa575.tar.gz
puzzles-24848706edfdd1db1f97e3681d7ff52bec2fa575.tar.bz2
puzzles-24848706edfdd1db1f97e3681d7ff52bec2fa575.tar.xz
Loopy: revamp loop detection, but not using findloop.
Loopy differs from the other recently-reworked puzzles in that it doesn't disallow loops completely in the solution - indeed, one is actually required! But not all loops are what you wanted, so you have to be a bit more subtle in what you highlight as an error. And the new findloop system doesn't make that easy, because it only answers the question 'is this edge part of a loop?' and doesn't talk about loops as a whole, or enumerate them. But since I was working in this area anyway, I thought I might as well have a think about it; and I've come up with a strategy that seems quite sensible to me, which I describe in a big comment added in loopy.c. In particular, the new strategy should make a more sensible decision about whether to highlight the loop or the non-loop edges, in cases where the user has managed to enter a loop plus some extra stuff.
Diffstat (limited to 'html')
0 files changed, 0 insertions, 0 deletions