Android did so far) by calling server_initClientConnection(). Now
relay games work with both started as hosts. (GTK UI prevents
starting one as a guest; cmdline is required for that, if it still
works.)
ID_TYPE_RELAY id that's not in the devices table (as has happened when
a device switches relay URLs during testing, but might also happen if
I have to delete an entry from the devices table.) In that case,
return ID_TYPE_NONE to the client, which will be its clue to delete
its ID_TYPE_RELAY id and submit the platform-specific id again.
Note: android won't compile this revision thanks to util.h change
which they're communicated to the device. Device is expected to have
a platform-specific notion of ID which the relay stores in a new
devices table and indexes with a 32-bit number which is returned to
the device -- which is encouraged but not required to use it in lieu
of the longer ID in future communications. Modify linux client and
test script to use the relay-supplied id. Some of this is commented
out for now.
players. I don't know what happens when a player's position is
changed when its game is a guest and the hosts rearranges players.
Which is why on Android I'm moving to allowing per-player dicts only
on local-only games.
save what it had ACK'd leaving the game permanently broken. Do that
by adding a new method game_saveSucceeded() called after the client
claims to have committed bytes returned by game_writeToStream() to
disk. In that method comms updates the value it'll use in subseqent
ACKs.
used by server. Clients need to care if e.g. the server's disallowing
phonies based on its dict. Can only be sent if client is of latest
version. In that case, common code calls into new util function. In
future changes, BoardActivity's implemention of the callback will need
to check if the server's choice of dict is available, and if not offer
to download it. Once it's available, will want to install it.
used by server. Clients need to care if e.g. the server's disallowing
phonies based on its dict. Can only be sent if client is of latest
version. In that case, common code calls into new util function. In
future changes, BoardActivity's implemention of the callback will need
to check if the server's choice of dict is available, and if not offer
to download it. Once it's available, will want to install it.
digraph tile when at the end of a prefix so that e.g. GORIL in Catalan
will list GORIL·LA (rather than nothing since GORIL, ending with the L
tile, is not a prefix.)
what percent of the times that timer fires will result in a move being
undone. Will be used to interject random out-of-order undos into
games played for testing. (Currently the tests fail when this is
enabled; I need to fix that.)
it if any players are missing. Idea's to allow for non-relay devices
the invitation opportunity that comes when a game connects to the
relay and learns that no other games have joined its room.
messages they must be handled by the relay in order. So modify linux
client to build a single packet of all messages sent instead of
letting rq sent each on a separate socket. The relay would give the
sockets to different threads and sometimes the wrong one won. Will
need to make sure the android code's doing the same thing (it appears
to be), or perhaps make the coalescing code common so I only debug it
once.
forward only) but disabled at compile time. Idea's to have a dict
browser. There was some simple refactoring in common code Android
uses, and that tests fine.
param gives name of Unix domain socket to be used to accept connection
that passes in messages from relay and receives messages to be sent
back. Works once but needs debugging....
player. Works for gtk client. Compiles for Android but there's no UI
yet to specify more than one dict. Management of dupicate dicts
without duplicating memory -- refcounting -- will be up to the
platforms.
to, instead of putting up UI, blocking on pipe and once it's readable
opening saved game and passing messages into it from pipe then saving
it when done. Works, but requires gtk so far.
game works to completion with both signing up as guests (no -s) with
one local and one remote player (identical commandlines.) Not yet
tested: if any signs up as a host, reconnecting rather than
connecting, etc. This is just a snapshot.
