Didn't handle the case where a game included NFC or BT. I should
probably be stripping those on receipt as I think the android side does
when the devices doesn't support 'em. And that in turn should be common/
code. So just fix it for now so testing can continue.
This is meant to replace the relay eventually, but for now it's a new
option, like BT or SMS, to be chosen. Protocol is handled in common/
code for the first time, meaning that linux and android interact without
the need to keep two platforms in sync. Linux uses lib-mosquitto, and
Android uses eclipse's Paho client (the generic java version, not the
one that uses four-year-old Service patterns and so crashes for SDK >=
26.)
Hungarian is unique (so far) in having two-letter tiles that can be
spelled with one-letter tiles AND in allowing words to be spelled both
ways. This crashed search based on strings because there were
duplicates. So now search is done by tile arrays. Strings are first
converted, and then IFF there is more than one tile array result AND the
wordlist has the new flag indicating that duplicates are possible, THEN
the user is asked to choose among the possible tile spellings of the
search string.
Linux and Android duplicated all the code to parse a wordlist file --
and shared a bug that needed fixing. So now most of that is in a common/
function both call, and the bug -- failing to mask out flag bits I don't
care about -- is fixed.
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.
Duplicate games get lots of crashes when mixed with phonies code. Will
need to fix that before enabling duplicate mode. In general there are
lots of assertion failures mixing trades and undos and phonies and
running dozens of games at once. I don't think that's new so will ship
now and fix later.
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";
Bad programmer. And because the raw bytes form was so large it always
caused the fake sms stuff to send immediately rather than waiting for a
timer to expire -- which never happened when run by the test script. So
I'm not allowing any timer for invitation-sends only.
(Another problem is that there's no mechanism in the xplat code to retry
invitation sends. That needs fixing.)
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.
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...
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. :-)
