ref: 70cb6cfa7abae854a201532f31bfdb1f19b4a8f4
parent: adc54741f03cf0cc5c639e917afd2442da9e3422
author: Simon Tatham <anakin@pobox.com>
date: Fri Feb 26 01:59:46 EST 2016
Tracks: fix further completion-checking loopholes. A user pointed out that Tracks could sometimes flash for completion when there wasn't even a full path from A to B! And it looks as if that wasn't even a mistake I introduced with the loop-checking revamp this week. Now I _think_ it's complete: we set ret=FALSE in check_completion wherever we also produce an error highlight, and also whenever there is no path connecting A with B. And if there is a path connecting A with B, then any square not on the path becomes an error highlight.
--- a/tracks.c
+++ b/tracks.c
@@ -1551,8 +1551,10 @@
for (i = 0; i < w*h; i++) {
state->sflags[i] &= ~S_ERROR;
if (S_E_COUNT(state, i%w, i/w, E_TRACK) > 0) {
- if (S_E_COUNT(state, i%w, i/w, E_TRACK) > 2)
+ if (S_E_COUNT(state, i%w, i/w, E_TRACK) > 2) {
+ ret = FALSE;
state->sflags[i] |= S_ERROR;
+ }
}
}
}
@@ -1579,6 +1581,7 @@
debug(("col %d error: target %d, track %d, notrack %d",
x, target, ntrack, nnotrack));
state->num_errors[x] = 1;
+ ret = FALSE;
}
}
if (ntrackcomplete != target)
@@ -1601,6 +1604,7 @@
debug(("row %d error: target %d, track %d, notrack %d",
y, target, ntrack, nnotrack));
state->num_errors[w+y] = 1;
+ ret = FALSE;
}
}
if (ntrackcomplete != target)
@@ -1651,6 +1655,12 @@
state->sflags[i] |= S_ERROR;
}
}
+ } else {
+ /* If we _don't_ have such a path, then certainly the game
+ * can't be in a winning state. So even if we're not
+ * highlighting any _errors_, we certainly shouldn't
+ * return true. */
+ ret = FALSE;
}
}