I'm looking for a test case to reproduce the Andorid situation where
invitations are never deleted from comms' queue and so prevent the
game from being considered over. Doesn't seem to happen in Linux, but
more tests are good.
This should complete sending to multiple topics (for backwards
compatibility) and supporting combined messages in the future (sending
them is hard; receiving not so much.)
I didn't understand MQTT at all. Per the docs anyway it only keeps a
message around if its "persist" flag is set, and then it only keeps
the most recent per topic. I expected that when a device connected,
messages would be waiting for it, but that's apparently not true (some
evidence to the contrary.) But having all games on a device share the
same topic means only one message can be waiting. So switch to
including gameID in the topic, subscribing to a wildcard topic and
sending to a different one per game. For now, for legacy purposes,
we'll keep sending to the old per-device topic.
Duplicate messages early on, which happened only in the test script
but could have anywhere, broke connectivity. So don't kill address
records when a duplicate shows up. Dupes only escape message ID
checking early (before channel is established). I used to remove
address records when a message was rejected, but don't understand why
so removed that, though asserts show it's not mattering except for
those early messages.
Add dutil proc haveGame() and use it to detect duplicate
invitations. I'm passing, but ignoring on android, the channel, which
means that for now you can't invite yourself and on-device testing
requires having CrossWords and CrossDbg or a second user.
There was some confusion around host and self addresses, where they're
created, default values, removing conTypes from defaults that are not
in received host addr, etc. I left in some asserts to help understand
if code that seems wrong but hard to fix is still getting called.
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.
Removed a boolean that seemed unnecessary. Stopped showing
move-explanations for robots in duplicate mode. They were being shown
too early thanks to bad logic, but I don't think there's any call for
them at all. A robot's move is only interesting if it's the one that
wins the turn.
The assertion's clearly blocking testing, but I'm not sure it's not an
error for two move explanations to want to co-exist. For now they're
concatenated.
Got rid of pre-cairo drawing stuff, but that didn't fix drawing not
happening without something like a window resize to force it. Instead
I added a manual gtk_widget_queue_draw() call. It's gross, but I'm
this app's only user. :-)
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.
When I've invited a Known Player, use that player's name in parens in
scoreboard and games list elem/summary until a remote device connects
(usually in response to an invitation) and provides an actual player
name. Makes it much easier to tell one pending game from another. And
doesn't really work (yet) where there's more than one remote player in
a game.
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.
