I'm fixing android client not showing stats for or allowing to disable
mqtt after it's added automatically to a game that connects
otherwise. Problem was that only the channel got the mqtt address
flag. So now add the flag for any type that's added.
Supid bug generating keys from __FILE__ meant each release
build (usually done in /tmp/$$, or on a travis server) had a new key and
generated a new MQTT devID (and other stuff less frequently used.)
Replace the keys with something that won't change, and as a temporary
fix so the upgrade including this fix doesn't generate new keys use the
most recent stored key matching the suffix the old keys will have had in
common.
If a configured-as-host game joined an existing game the relay would
make it a guest. The android util_ callback for that change was only
implemented in BoardDelegate and so the change was dropped unless the
game was open/visible. Because comms recorded the change, though, the
callback would never be called again and so the game never learned to
behave as a guest and never registered: permanent failure to join game!
Implemented with a new server state so initClientConnection can be
called from server_do() instead of inside comms while processing an
incoming packet.
To avoid inviteless relay games not having an mqtt channel (and so
yielding a crappy experience) pass the mqtt devid when device registers
and when server replies with all-here.
Some relay bug (I think) misroutes or duplicates packets. Don't assert
as that means test scripts fail to finish. Instead drop the
message. Scripts seem to recover ok with this change and I've never seen
the assert on a device so suspect it's test-world only
Add a basic regular expression engine to the dictiter, and to the UI add
the ability to filter for "starts with", "contains" and "ends with",
which translate into ANDed RE_*, _*RE_* and _*RE, respectively (with
_ standing for blank/wildcard). The engine's tightly integrated with the
next/prevWord() functions for greatest possible speed, but unless
there's no pattern does slow things down a bit (especially when "ENDS
WITH" is used.) The full engine is not exposed (users can't provide raw
REs), and while the parser will accept nesting (e.g. ([AB]_*[CD]){2,5}
to mean words from 2-5 tiles long starting with A or B and ending with C
or D) the engine can't handle it. Which is why filtering for word length
is handled separately from REs (but also tightly integrated.)
Users can enter strings that don't map to tiles. They now get an
error. It made sense for the error alert to have a "Show tiles"
button, so there's now a dialog listing all the tiles in a wordlist,
something the browser has needed all along.
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.
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";
