Fixing a problem with languages (like Hungarian) where it's legal to use
a two-letter tile or two single-letter tiles to play the same word. When
words are seen, or searched for, as char-arrays, there are
duplicates. Current code crashes, but there's also risk the user gets
unexpected behavior. Crash is fixed, and foundation laid for better UX,
by doing all searches for tile arrays. If a search string translates to
more than one tile array the user must choose. For that choice to make
sense it's now possible to translate tile[] to char[] with a delimiter
between the tile strings.
I was getting an occasional crash using a stale env to delete a dict's
resources because the dict was cacheing the env that created it. Dumb!
Using the thread->env mapping stuff worked, but that felt risky and so I
tried just passing it in. It's safe, and involves an amount of change I
can tolerate. So likely going that way.
Turns out the host, when inviting a remote device, needs to know how
many players are on it (since more than one is supported and the script
currently generates that case.) So pass to --server devices an array,
one per remote -- but don't bother when all entries are "1";
If slow network traffic has given a guest time to move tiles to the
board while the host decides its last move must be rejected, those tiles
must be removed before the rejected turn can be undone.
With reject-phonies set this will trigger the reject path.
Also init CommonPrefs in jni land since its makePhonyPct, left unitialized,
causes the robot to deliberately reverse every turn, firing an assertion that the
robot's moves are legal.
Currently detects the same as tiles not in a line and calls out to a new
util method that's currently parameter-less. On Android the option only
appears in d variants.
When a guest sends a move to the server it's not the next player's turn
until the server checks the move and rejects or accepts it. It was
possible still to manipulate the board, playing new tiles, and even to
attempt to commit them. And if the move came back rejected, the bogus
committed one would be that was cleared. Bad. So I'm just setting the
turn to -1, which disables board etc., and letting nextTurn() assigne it
after the confirmation comes back.
Yikes. I used to assert, in nextTurn(), that you were in the right
state. On release builds that went away, and you were moved into the
right state regardless. The bug happened when I changed that to exit
nextTurn() without changing the state, meaning that for PHONIES_DISALLOW
the host filled up its message queue trying to communicate that the
latest move was ok, never getting out of the state that required sending
that message. The fix is simply to change the state after sending and,
guest-side, after receiving, that message.
I don't know why, but in my tests the relay seems to be delivering
messages to the wrong device. The linux device detects this. It used to
assert, but now just drops the message. If this is happening on Android
it might be why I'm seeing crashes...
Required redoing how I invoke the NDK. The limititations I had to hack
around before seem fixed, so this is probably better. But there will be
glitches. :-)
Len byte was limited to 255, but would get clipped (masked with 0xFF)
then all the string data would get written. So on receipt, the clipped
length was taken to be that of the string data, with the rest of the
string to be interpreted as something else. An array index, in this
case.
With these changes the test script no longer produces games that don't
finish. I think they are recovering from the problems produced by one
device doing an undo while another is making a move, or other problems
produced by undo being allowed to happen on any device at any time, but
haven't analyzed the games beyond the test script's verifying that they
all finish with a Winner after all tiles are consumed.
There are still some stalls turning up when running the test script,
especially with more than two players in a game, but but it'll be
easier to do the final debugging off my pathetic travel-only
chromebook. And things are already much better. :-)
When something goes wrong with a move (typically because of undo), the
move stack and server's idea of whose turn it is get out of
sync. Since it being my turn means it's up to me to put the next move
on the stack, let the stack own "next turn". (Can probably eventually
get rid of the ServerCtxt variable that tracks it.)
