diff options
| author | Simon Tatham <anakin@pobox.com> | 2023-04-23 14:02:39 +0100 |
|---|---|---|
| committer | Simon Tatham <anakin@pobox.com> | 2023-04-23 14:02:39 +0100 |
| commit | 2d91261eb3a37b919f48450888f8f5bfd226c053 (patch) | |
| tree | 16281069fb883c19e80a7a6dce92070d4b5b6ff7 /misc.c | |
| parent | c0bd524848f98e5c4a495c4bc31dd55087a28aaa (diff) | |
| download | puzzles-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