The buggy code assumed two arrays were in sync that weren't guaranteed
to be so. So now I'm leveraging rematch code that already put
addresses in player order.
Present to user option to remember "phonies", words played but not
in the current wordlist. They're stored by language (not by wordlist)
and not available for hints or the robot to use (as that would require
incorporating them into a wordlist, a much larger change.)
It's bad to display a name based on a player order in the same place
as where you're letting people change that order and not have the
name change. So re-juggle the rematch process to allow the name to
be changed -- but don't change once the user has edited the name.
A rare stall resulted when the invitee on channel 2 responded
first. It would get assigned channel 1 and so the invitation on that
channel would get deleted. If it hadn't already reached the mqtt
server it would never be delivered. My fix is to use an invitation's
channel instead IFF its address matches the return address of the
incoming message. I'm not sure what happens if there's somehow a mix
of invited (via rematch) and invited-some-other-way players. None of
this matters for two-device games anyway.
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.)
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.
