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.
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.)
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.
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.
possible to start without specifying comms params, to switch roles
and/or number of players when starting new game; clean up dialogs,
esp. use notebook widget to have tab switch between comms types.
base64-encoded data as the messages. Make necessary changes to comms.
This is the foundation for doing real SMS transport on handhelds.
Currently a full robot game works for two gtk clients provided the
server is launched first.
util_altKeyDown to allow user to choose between scrolling board and
dragging the hint rect when both are possible. add adjustYOffset;
make it and board_setYOffset more tolerant of out-of-bounds inputs and
use that to simplify calling code.
that all connectivity was with relay and over streaming sockets (since
BT is using l2cap's datagram-style sockets.) With this checkin, a full
robot-vs-robot game is possible with palm as host and linux as client.
Linux as host isn't started yet.