implemented (when not smart) as trying to match the human's score to a
per-robot value between 1 and 100 that gives the percentage of best
moves to store before picking randomly from among them. So a 1 means
save only the best move and always pick it; 100 means save all the
best moves (how many are saved is compile-time configurable) and pick
one of them. Because it's settable per-robot a smarter robot can be
played against a dumber one (though I may choose not to make it
settable per-robot on shipping versions.)
into the java world by making it a util_ctxt function. Do same on
linux to test. We'll see how it is -- and can back this commit out if
there's no improvement.
comms config dialogs on changes to host type (which often involved
platform-specific hackery to trigger the dialog when user doesn't want
to change role)
host or standalone where all are shown, change the number shown
appropriately. The goal is to make the experience natural,
particularly for the common case where the players aren't changing.
Give up once user manually changes number shown.
info: when the device is a client and is starting a new game, we want
to start presenting only the local players. So load them first, and
reduce nPlayers down to the count of current local players. Works
well, but can probably be simplified.
deal with the output by removing params where possible and elsewhere
by adding XP_UNUSED macro wrapping __attribute__((unused)). There
should be NO change in function in spite of the large number of files.
again until it is. newgame calls once: it's possible that juggling won't
do anything. Still pending: do we tell users when nothing changed, or
leave them to figure out that it's not a bug?
