aboutsummaryrefslogtreecommitdiff
path: root/misc.c
diff options
context:
space:
mode:
authorSimon Tatham <anakin@pobox.com>2023-04-23 14:02:39 +0100
committerSimon Tatham <anakin@pobox.com>2023-04-23 14:02:39 +0100
commit2d91261eb3a37b919f48450888f8f5bfd226c053 (patch)
tree16281069fb883c19e80a7a6dce92070d4b5b6ff7 /misc.c
parentc0bd524848f98e5c4a495c4bc31dd55087a28aaa (diff)
downloadpuzzles-2d91261eb3a37b919f48450888f8f5bfd226c053.zip
puzzles-2d91261eb3a37b919f48450888f8f5bfd226c053.tar.gz
puzzles-2d91261eb3a37b919f48450888f8f5bfd226c053.tar.bz2
puzzles-2d91261eb3a37b919f48450888f8f5bfd226c053.tar.xz
Net: preference for how loop highlighting interacts with locking.
Net's loop highlighting detects any loop in the current state of the grid. I've occasionally found that to be a bit of a spoiler, since sometimes it can point out a deduction I should make before I've figured it out for myself - e.g. when I've just locked all but two of the squares involved in the loop, and the last two _just happen_ to be oriented so as to complete the loop. In that situation I'd prefer if the loop _didn't_ immediately light up and point out to me that I need to arrange that those squares aren't connected to each other. The simple answer is to only count edges connecting two _locked_ squares, for the purposes of loop detection. But this is obviously unacceptable to some players - in particular, those who play without the locking feature at all. So it should be a user preference.
Diffstat (limited to 'misc.c')
0 files changed, 0 insertions, 0 deletions