When rematching, some users have a convention that e.g. lowest scoring
player in the "parent" game goes first. So allow that, providing the
choice on each rematch until a default has been chosen. Support
changing that default in a new prefs setting.
The place I chose to enforce the order was on the host as invitees are
registering and being assigned slots. But by then there's no longer
any connection to the game that was rematched, e.g. to use its
scores. So during the rematched game creation process I create and
store with the new game the necessary ordering information. For the
3-and-4 device case, it was also necessary to tweak the information
about other guests that the host sends guests (added during earlier
work on rematching.)
Android has lots of games on a single device. My current test has one
device per game. I'm hoping to fix that, and am starting with figuring
out how the script and "device" instances will communicate.
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.
