Engine shouldn't be so stupid as to play a blank for 0 points. So when
comparing two moves, sort first on score, then use number of blanks
used to break any ties.
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.
Current networking, based on invitations rather than a relay that
plays matchmaker, allows host to know its address when a game is
created, and for guest to know its host's address in
addition. Enforcing this makes inviting and rematching in common
code (coming soon) easier. Big change on Android is I used to create a
new game prior to passing it to GameConfigDelegate, but now I have to
wait for user to configure (including choosing how to communicate)
before I can create it.
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.
