Lots of changes adding a games-list view to the app from which you
create new games, open and delete existing ones, etc. There's still
plenty that's unimplemented, but it's already more useful for testing
and development. Which is the point.
This fixes on gtk version being able to invite to an SMS game using
relayID. I don't know why not transmitting port is ok; maybe android
doesn't use the port or gets it some other way, e.g. it's hard-coded for
each variant.
I've long wanted common code and state that outlast a single game. The
smsproto stuff is a step in that direction, but this file will be a
place for anything new. Starting, perhaps, with a mapping of deviceID ->
addressInfo (e.g. BT name or SMS number of opponent device) that will
let me stop duplicating that stuff in every game's comms state. We'll
see. It's guarded by a compile-time flag so I can play with in on the
Linux version until ready.
Use low-level NFC, a combination of emulated card and reader mode, to
work around Google's removal of "beaming" support from Android 10. App
emulates a card by declaring support in its AndroidManifest. When a game
is open that has data to send, it goes periodically into read mode. If
two devices are touched while one is in read mode and the other isn't,
they handshake and open a connection that should last until they're
separated. The devices loop, sending messages back and forth with or
without data (as available.)
I think I'm seeing a bug where msg <n> is received, I record that I'm
now looking for msg <n+1>, fail to process <n> (perhaps because some
resource is temporarily unavailable?), and am now in a state where I
won't accept <n> when it's resent. This fixes this by only recording <n>
received after processing code has accepted it.
I suspect that messages are being dropped (in server) after being
recorded (in comms), causing the game to stall forever. So add an
assertion that it's not happening. Haven't seen it yet in a few hundred
games, but it'll be nice to be more confident.
When a stream reader and writer are out of sync it often shows up as
trying to read off the end of the stream (firing an assert.) It's useful
to know where that's coming from on android where there's usually no
stack trace in the jin world. So pass __func__ in using macros, and log
before asserting. Crude but quick and already useful.
Should not show the new you-can-lookup-uncommitted-words hint for
already-played words, so needed to be able to tell difference between
the two. Now you can -- and on the gtk side I draw them differently
because I can.
When a word's been formed as part of the current turn, but not yet
committed, allow long-tap to trigger an offer to look it up online same
as for already-committed words. Allows checking the legality of
potential plays AND figuring WTF the hint feature just suggested.
I'm seeing my simultaneous access assert fail, so might as well break
fix it the foolproof way. It's background threads only that are calling
this stuff on Android so blocking them shouldn't hurt.
Lots of threads call the smsproto code now so the existing check was
failing. Replace it with one that ensures that only one thread at a time
is running the code. Debug-builds only.
It's useful when testing to have the remote device play without human
interaction. So add an option, and UI to trigger it, for the players
created remotely in response to an invitation to be robots. There are
guards in place to catch the feature slipping into a release build.
Darned thing was dropping packets, failing to connect games built in
response to invitations, and otherwise misbehaving. First was due to not
resheduling when exited with outbound packets in queue; second to not
overriding relayNoConnProc() (due to signature change.) Though it still
happens occasionally.... Also added timestamps to track how long it
takes a packet to be sent and ACK'd.
My VSIZE is no longer legal, and apparently there's no workaround (no
way to safely figure the length of an array whose size is known at
compile time.) To avoid the risk of duplicating little constants, added
macros that define length in a way a new VSIZE can pick it up. Couldn't
make that work for struct field arrays, however, so there I'm using
constants.
I'm seeing a rare case where a game connectes to relay specifying a room
and somehow gets both slots, having provided different gameSeeds the two
times. This means an opponent won't connect, the room being full in that
game. I can't reproduce, so am logging seed changes better and switching
linux client to leave seed generation to comms as Android does.
