lab/m3te
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

P2.1: holes never match in find_matches

Browse Source 
find_matches walked maximal same-type spans without excluding `.empty`, so a
line of 3+ holes (left by a prior clear) was reported as a match. After any
vertical 3-clear or L/T clear the board carries such a line, so find_matches /
clear_matches returned non-zero on a board with no real gem match — which would
prevent the P2.4 cascade from ever stabilising.

Fix at the source: a run is only a match if its gem type is not `.empty`. Holes
already break runs of real gems (a hole differs from every gem), so this is the
only change needed and every caller (P1.3 legality, P2.4 cascade) is now correct.

Regression in tests/clear.sx: a holes-only board yields zero matches and
clear_matches 0, and re-clearing a holed board returns 0. Other goldens are
unchanged (no board without holes is affected).
This commit is contained in:
swipelab
2026-06-04 20:08:26 +03:00
parent 2713a67b2b
commit 6e2a57f3a2
3 changed files with 78 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
tests/expected/clear.stdout
View File

@@ -94,4 +94,23 @@ OGOGOGOG
GOGOGOGO
OGOGOGOG
GOGOGOGO
== holes-no-match ==
before:
OGOGOGOG
GOGOGOGO
OGOGOGOG
GO...OGO
OGOGOGOG
G.GOGOGO
O.OGOGOG
G.GOGOGO
after:
OGOGOGOG
GOGOGOGO
OGOGOGOG
GO...OGO
OGOGOGOG
G.GOGOGO
O.OGOGOG
G.GOGOGO
ok: clear over hand-crafted boards