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.
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.
Put up an error message if too many tiles selected for trade
(a condition that couldn't exist when the pool was guaranteed to
have at least 7 in it.) (It's a hack: there's not even an enum
giving Spanish's code, and the lang_locale stuff in info.txt isn't
making it into the .xwd format.)
Handles case where the app receives only a subset of the SMS messages
into which a larger game-level message has been broken. Now when it
restarts and the remaining parts come in the whole can be reassembled.
And use in linux client. Goal here is to reproduce then improve the
Android SMS pre- and post-processing stuff with a common/ implementation
that can be tested on linux and used wherever.
My linux sms hack used inotify and didn't check for messages that were
there when the app launched. Replace inotify with a simple glib periodic
timer. A bit of latency mimics SMS better anyway. Update test script to
support SMS, and add params to and otherwise fix linux client so
everything works.
Trying to separate what's game-specific from what can be app/device
specific (i.e. with a long lifespan, and available when a game isn't
open.)
Android will be broken after this commit and fixed after the next
Once the pool count drops to 0, start showing the number of tiles left
in the user's tray. This prevents there being a long time when nothing
seems to be changing *and* the script from exiting early because it
thinks all games are hung.
translate the most-used features of my too-big-for-bash script into python3,
which is clearly much better suited. Tried to keep the structure and variable
names intact so that diff has a chance of showing something, but when a class
replaces a bunch of arrays that were being kept in sync there's only so much
you can to. Currently doesn't support stuff like app upgrades and switching
from tcp to udp, but those should be relatively easy to bring over from the
.sh when/if I need them.
translate the most-used features of my too-big-for-bash script into python3,
which is clearly much better suited. Tried to keep the structure and variable
names intact so that diff has a chance of showing something, but when a class
replaces a bunch of arrays that were being kept in sync there's only so much
you can to. Currently doesn't support stuff like app upgrades and switching
from tcp to udp, but those should be relatively easy to bring over from the
.sh when/if I need them.
It breaks rematch that "dict" is being passed to the Android client from
the linux side, and this is easier than figuring out how and when to
dereference the link.
Ideally the comms module wouldn't go through its connecting routine in
order to join a game. To that end I added a join() method to relay.py
and code to call it. Joins happen (pairing games, starting new ones,
etc.), but after that communication doesn't. First part of fixing that
would be to make cookieID persistent and transmit it back with the rest
of what join sends (since it's used by all the messages currently sent
in a connected state), but I suspect there's more to be done, and even
that requires a fair number of changes on the relay side. So all that's
wrapped in #ifdef RELAY_VIA_HTTP (and turned off.)
With the new http stuff, at least for now, it takes longer to get things
communicated and so killing games after 2 seconds of runtime meant no
moves ever got made. Making it configurable, and passing 10 (seconds)
means nearly all games in a large test run complete reasonably quickly.
ACK doesn't need to wait 2 seconds for a reply, and when it does so the
next send waits too. Eventually we'll want to combine messages already
in the queue into a single send. For now, this makes things better.
using g_add_idle() for each piece of data received on the (background)
curl-query thread wasn't working. They were getting starved, and I think
some were considered duplicates and never scheduled. So add a single
timer proc called every 50 ms and a queue that it checks and into which
the network thread can put stuff.
