The solve move stored in 'aux' by new_game_desc consists of printable
characters in the range '@' to 'O', each representing a 4-bit bitmap
of edges around a cell. But the one generated on the fly by
solve_game() was missing out the 0x40 bit and just returning
characters in the range ^@ to ^O - which would not only have been
horrible if you found such a string in a save file, but also meant
that a game with any completely borderless square would have a
solution move string terminating early due to the ^@, causing
execute_move() to reject it.
Example: ./palisade --test-solve --generate 1 5x5n5#12345-37 now
succeeds, where previously it failed an assertion.
init_borders(w, h, move + 1);
move[wh + 1] = '\0';
- if (solver(&state->shared->params, state->shared->clues, move + 1))
+ if (solver(&state->shared->params, state->shared->clues, move + 1)) {
+ int i;
+ for (i = 0; i < wh; i++)
+ move[i+1] |= '@'; /* turn into sensible ASCII */
return (char *) move;
+ }
*error = "Sorry, I can't solve this puzzle";
sfree(move);