diff options
| author | Ben Harris <bjh21@bjh21.me.uk> | 2023-02-03 20:52:05 +0000 |
|---|---|---|
| committer | Ben Harris <bjh21@bjh21.me.uk> | 2023-02-03 22:54:46 +0000 |
| commit | 843d4ca17def11671809786f2a5aebd75f230dd9 (patch) | |
| tree | 30cd7d5e0b5aad5c6f00b2681eb3750a37123ad3 /unequal.c | |
| parent | 15f4fa851a5781cf77984a6046405ffa758e7b33 (diff) | |
| download | puzzles-843d4ca17def11671809786f2a5aebd75f230dd9.zip puzzles-843d4ca17def11671809786f2a5aebd75f230dd9.tar.gz puzzles-843d4ca17def11671809786f2a5aebd75f230dd9.tar.bz2 puzzles-843d4ca17def11671809786f2a5aebd75f230dd9.tar.xz | |
Tolerate incorrect solutions in Inertia
The "solve" operation in Inertia generates a proposed solution as a
move string. But if such a move string is loaded from a save file it
might not actually describe a solution. If that happens then it's
possible to reach the end of the "solution" without winning, and doing
so should probably cause a recalculation of the solution rather than
an assertion failure ("execute_move: Assertion `ret->solnpos <
ret->soln->len' failed.").
I am a little concerned by the way that normal solve operations end up
encoded in the save file, but the re-solvings caused by going off
course don't, but I haven't got a good answer to that.
Here's a save file that demonstrates the assertion failure:
SAVEFILE:41:Simon Tatham's Portable Puzzle Collection
GAME :7:Inertia
PARAMS :3:8x8
CPARAMS :3:8x8
DESC :64:sbgwsmswwgggwggmmbwgwbssbwbsbwbbwsSmwbbsbbmggbmssgmgwbmmwmbmmwsw
NSTATES :2:3
STATEPOS:1:1
MOVE 000:2:S0
MOVE 000:2:00
Diffstat (limited to 'unequal.c')
0 files changed, 0 insertions, 0 deletions