Change the policy for parsing underspecified params strings.

In conversation with a user last week, it emerged that the command
'solo --generate 1 9jk#12345' was giving a different game from the one
it gave when I ran it, and it turns out that this is because I've set
SOLO_DEFAULT=7jxdi in my environment to make GUI Solo automatically
start up in my (current) favourite mode. And the difficulty setting
from that parameter string was being reused to fill in the unspecified
difficulty slot in the '9jk', so that the same params string was being
interpreted differently by our two machines.

This is certainly wrong - the whole point of random seed strings like
that is to be interpreted the same way everywhere. But it's a side
effect of something I did do on purpose, for people switching back and
forth between playing randomly generated games and playing a game id
pasted (or typed) in from elsewhere. So this fix, with a giant comment
explaining it, I _think_ should retain the behaviour I originally
wanted while getting rid of the behaviour I didn't.

diff --git a/midend.c b/midend.c
index 178650b1b1a6c81a101e9a531a16a20ba27c2aae..a17085795129da5002d7ac95e10930a0f7da0255 100644 (file)
--- a/midend.c
+++ b/midend.c
@@ -1179,7 +1179,45 @@ static char *midend_game_id_int(midend *me, char *id, int defmode)
     newcurparams = newparams = oldparams1 = oldparams2 = NULL;
 
     if (par) {
-        newcurparams = me->ourgame->dup_params(me->params);
+        /*
+         * The params string may underspecify the game parameters, so
+         * we must first initialise newcurparams with a full set of
+         * params from somewhere else before we decode_params the
+         * input string over the top.
+         *
+         * But which set? It depends on what other data we have.
+         *
+         * If we've been given a _descriptive_ game id, then that may
+         * well underspecify by design, e.g. Solo game descriptions
+         * often start just '3x3:' without specifying one of Solo's
+         * difficulty settings, because it isn't necessary once a game
+         * has been generated (and you might not even know it, if
+         * you're manually transcribing a game description). In that
+         * situation, I've always felt that the best thing to set the
+         * difficulty to (for use if the user hits 'New Game' after
+         * pasting in that game id) is whatever it was previously set
+         * to. That is, we use whatever is already in me->params as
+         * the basis for our decoding of this input string.
+         *
+         * A random-seed based game id, however, should use the real,
+         * built-in default params, and not even check the
+         * <game>_DEFAULT environment setting, because when people
+         * paste each other random seeds - whether it's two users
+         * arranging to generate the same game at the same time to
+         * race solving them, or a user sending a bug report upstream
+         * - the whole point is for the random game id to always be
+         * interpreted the same way, even if it does underspecify.
+         *
+         * A parameter string typed in on its own, with no seed _or_
+         * description, gets treated the same way as a random seed,
+         * because again I think the most likely reason for doing that
+         * is to have a portable representation of a set of params.
+         */
+        if (desc) {
+            newcurparams = me->ourgame->dup_params(me->params);
+        } else {
+            newcurparams = me->ourgame->default_params();
+        }
         me->ourgame->decode_params(newcurparams, par);
         error = me->ourgame->validate_params(newcurparams, desc == NULL);
         if (error) {