aboutsummaryrefslogtreecommitdiff
path: root/PuzzleApplet.java
diff options
context:
space:
mode:
authorSimon Tatham <anakin@pobox.com>2017-10-01 09:15:49 +0100
committerSimon Tatham <anakin@pobox.com>2017-10-01 09:51:01 +0100
commitcdf163953105e37b4c90838227342c4eb2cab670 (patch)
treee4753724ac2862b76859db9a77d9347f8b4e1abe /PuzzleApplet.java
parentaafb1b4983d4cd2eb2d3465b4ed9ad2d67888bf5 (diff)
downloadpuzzles-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