Server needs to not rematch if any device has more than one
player (for now, as I'm too lazy to fix this rare condition.) I'm
moving toward having the linux client write status to a unix socket on
exit rather than having the test script parse the log file for
status. GameOver is there now. Tile counts should follow.
Add new script param setting a timeout before which games will be
rematched on finishing. Add new param to ncurses version telling it to
try to rematch when finishing. This introduces a new problem because
now there are multiple games per "device", and various log-grepping
stuff like listing the number of tiles in play or determing whether
device is finished all assumed one game. I addressed the latter by
adding a way to query the DB to see if all games are done, but that's
not quite right because the number of pending messages is increasing
after a game completes. Still, the testing is useful so I'm pushing
this.
No point in sending the old-topic-format MQTT messages to clients that
know about the new one, and in fact it's harmful. Devices in a game
already agree on the stream version to use and communicate it, so pass
that into comms once it's known and from there on to the device code
that builds mqtt messages.
Remove legacy relay-inspired logic around comms addressing. Now when a
device creates a game it's required to provide its "self address," and
if it's a client, the address of the host (which it presumably got
through the invitation in response to which the game is being
created.) Then as registration messages come in from clients, the host
gathers their addresses as always.
I want receiver to know when message was originally created. This adds
timestamp to messages and passes it via send proc. Client needs to
send it where possible. So far, MQTT format can't include it without
change, so I'm adding a new proto version. This change can read the
new version. Once that's well-enough distributed I can start sending
using it. Other transmission types than MQTT are for later.
In curses version there's no new-game dialog, so if the params passed in
don't give enough information NewGame menu can't be handled. Rather than
asserting later, refuse after posting an explanation.
It's awkward for platform code to create a dictionary prior to opening a
game whose data contains the information about what dict to open. So add
a dutil method to fetch a dict, and call it from inside game opening
code. Makes linux code better at least.
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.
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.
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.
