Now that rematching creates all the invitations and an expectation of
how the invitees will be ordered it'll confuse things if unexpected
players show up. So don't allow players to send additional
invitations.
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.)
Two cases dealt with here. First, if my opponent deletes the game when
I have an un-ack'd message, I'll keep sending it forever. Fix is to
flip a bit in comms in response to a game_gone event so no more
sending will happen. (Better than emptying the queue, as it leaves
open the possibility of resurrecting the game with code changes
later.) Second, if there's a retained message from a dead game I'll
keep receiving it until it's replaced, and if the game's dead it never
will be. Fix is to add a new api endpoint noSuchGame() to the relay2
server and to call it on receiving a message for which I have no game
to deliver it to. The endpoint "unretains" the message so I won't get
it again unless it's resent.
If I get an invitation to a wordlist I can't download, hilarity
ensues. I get asked over and over to download it, and because in the
MQTT case the invitation is persisted it'll happen a lot. First step
is to discourage sending those invitations. This change interacts with
the server to flag not-on-server wordlists, and shows the flag in the
wordlist browser and also shows warnings when invitations are about to
be sent.
Because only the host/inviter knows the addresses of all the devices
in a game it's hard for guests to rematch (unless it's a 2-device
game, as they know the host's address.) So now, as part of telling
guests the game is ready to play, include the addresses of other
guests. It's usually only 9 bytes per device, and only happens when
more than two devices are in a game.
Add ability to copy to clipboard and then to invite by pasting from
clipboard. Makes it much easier to connect two emulator instances
where neither can camera the other's QR code.
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.
Use my set of permissions more than trying for individual ones, as
that's not enough on newer OS versions. Seems to work sometimes at
least, but maybe only after a new install.
