diff options
| author | Simon Tatham <anakin@pobox.com> | 2017-10-01 09:15:49 +0100 |
|---|---|---|
| committer | Simon Tatham <anakin@pobox.com> | 2017-10-01 09:51:01 +0100 |
| commit | cdf163953105e37b4c90838227342c4eb2cab670 (patch) | |
| tree | e4753724ac2862b76859db9a77d9347f8b4e1abe /PuzzleApplet.java | |
| parent | aafb1b4983d4cd2eb2d3465b4ed9ad2d67888bf5 (diff) | |
| download | puzzles-cdf163953105e37b4c90838227342c4eb2cab670.zip puzzles-cdf163953105e37b4c90838227342c4eb2cab670.tar.gz puzzles-cdf163953105e37b4c90838227342c4eb2cab670.tar.bz2 puzzles-cdf163953105e37b4c90838227342c4eb2cab670.tar.xz | |
deserialise: use the right one of {,c}params.
The serialised game stores a long-term and a short-term parameter
structure, which correspond to me->params (the thing that gets used by
the next New Game command) and me->curparams (the thing that _was_
used to generate _this_ game). So data relevant to the current game
ought to be validated against the latter, but in fact I was
accidentally passing the former to several validation calls.
I think this probably avoided causing a problem because typically
params and cparams don't differ very much: the usual reason why
they're not the same is that somebody has manually entered a game
description involving an incomplete description of the parameters
(lacking generation-specific details like difficulty level), but by
the very fact that those incomplete descriptions have to contain
_enough_ information to understand a specific game description,
copying just those parts of the description into the long-term params
structure makes the two similar enough that validation won't fail.
However, testing an upcoming patch which calls midend_deserialise at a
more difficult moment (specifically, just after midend_set_params,
meaning that the two params structures can now differ _arbitrarily_)
reveals my error. Fixed to use cparams where that's the right thing.
Diffstat (limited to 'PuzzleApplet.java')
0 files changed, 0 insertions, 0 deletions