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.
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.
Remove it from known set so it can be used to test. Get rid of
filenames having umlaut since that screws up URLs between Android and
nginx (not sure whose fault and not going there now.) Lang name should
be able to have an umlaut, but it gets used for filename for now so
fix later....
Modify language metadata to have possibly different counts of tiles
for different board sizes. Make the necessary changes for loading such
files. Works on linux version at least. Only English will build for
now thanks to changes in info.txt format.
Attempting to stop calling the relay, but to let relay-only games finish
and issue invitations. Big changes are that relay is removed from games
if they have viable mqtt connections, and relay timers fire less often,
then eventually stop getting set if there are no active games. Result is
that a relay-only invitation won't likely be received, but there should
be few or none of those now.
I was determining I need to check the relay for messages if I have open
games using it. But they can also use mqtt, and the goal's go stop using
the relay. So only force the connection if the games can only connect
via relay. Once I've confirmed via a study of relevant databases that
all recent relay games are also connecting via mqtt this can ship, and
should stop nearly all relay traffic .
augmentAddrIntrnl() sets the has-mqtt bit in comms->addr but not the
address data (has none). If that address had been loaded from stream
the address bits will be random, not 0, and so get treated as an
address.
Sending in 32 bits what can probably fit in 8 -- twice -- is dumb. As is
sending the gameID (as connID) when it's already known. In 2016 I added
a fixed marker, so I can count on all current code sending that. If I
fail to find that, I know the sender is new (current release or better.)
In that case, use 12 bits instead of 32 for two fields, drop the marker
and the connID. Result is that an ACK's size, including MQTT headers,
drops from 28 bytes to 21.
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 in the context of a game, and we might want info about the game
when notifying the user. For wasm, though, I just download after failure
to open. User has to try again to open the game. Good enough for now
since missing a wordlist shouldn't happen if you're not me changing
where they're stored.
Replace a couple of load/store actions with new APIs that do so
asynchronously (using indexeddb underneath, via emscripten APIs.)
Required restructuring how app starts. More changes to come. The idea is
to replace wordlist storage: this'll keep 'em smaller and not require
conversion to string.
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.
I'm heading toward being able to know what all the games are by how
they're stored in a xplatform way. This is a start. Adding a second key
to storage, and looking at grouping everything where one key or the
other matches.
There's code on all platforms to force user to have dict prior to
opening a game or responding to an invitation. "Empty" dict play hasn't
made sense in a long time.
We've decided that on upgrade users shouldn't be surprised by a busy
board and unaware of how to fix it. So keep it the way it's been and let
the curious discover the new ability. Also, simplify code.
Create new class that owns the alert. Let it decide whether to post,
remove, etc. Seems to work, but I've removed some of the "reinvite"
options I'm not sure were helpful anyway. To be considered...
It's simpler this way, and I'm tired of stuff not happening because the
OS chooses not to schedule e.g. an invitation send for minutes. Goal's
to be running BluetoothServerSocket.accept() as much as possible when
there are active BT games in play OR when the game's in the foreground.
If that's happening, sent invitations and moves will be received when
users expect. When there's no traffic and app isn't being brought to
foreground, backoff will ensure I don't try to run accept() too often.
FWIW, BTLE seems to offer a better way to do this (to have an app be
responsive to incoming invitations when it hasn't run in the foreground
in a while), but it requires users to accept FINE_LOCATION
permission. I'm hoping I can make this work to avoid asking for that
permission.
The last change meant the test whether to show the words under the
pen-down cell would pass when it shouldn't because a drag to an occupied
location didn't register as movement. Change so movement counts to stop
the timer even if it wouldn't change the drag-target's location.
Rather than have a tile revert to its original location if it's dropped
where it can't be (on an occupied tile or outside the board), put it in
the last place it could have been. Do that by only updating cur when
it's to a legal location, and then relocating to cur when drag ends.
