add new stream getters that return false if reach EOS and use them to
exit early and safely if incoming SMS msg is misformatted. I'm getting
random garbage meant for other apps perhaps.
Had an assert fire when a message ID was reused with a different count.
It was likely because of messages crossing between two variants, but
still, fix: delete what's been saved so far when a new count shows up.
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.
So now all jni code uses a single dutil context, but also a single
mempool and jniutil instance instead of new instances of the latter two
per game and dict-iteration.
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.
Got a report of crashes due to corrupt move records. Given I rarely see
them I wondered if it's because the hint- and robot-generated moves I
work with have tiles in order. So now on debug builds tiles in moves
from those sources are randomly rearranged (as if the user had formed
the word in random order.) The bug isn't showing up, but I figure the
test's worth keeping.
The fix I made earlier for this relied on a callback that was skipped in
release builds. Now always take the path that involves making the
callback when one is provided. Also remove an optimization that was
trying to eliminate possible moves based on scores prior to doing the
more expensive full check. In 2018 I prefer simplicity, and can make the
remaining code faster if that's required.
I *think* the reason I'm occasionally seeing toasts about not finding a
move is that when the engine's interrupted by there being a UI event in
the queue that error is posted. Instead try posting only when at the end
of the search nothing's been found.
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.)
If I want to move relaycon into common so Android can use it (assuming
the jni code starts including json-c and libcurl so it can handle
networking) I'll need a replacement for GSList. This is a start.
I'm seeing assertions when a game gets into a state I don't fully
understand: host receives messages that need a channelNo assigned but
the game's full. With luck they're duplicates and can be ignored,
because that's all I can do.
New classes implement custom alert and its view, where most of the logic
for putting up one button per tile, hiding and showing buttons based on
what's left, etc. lives. Rough, but works well until rotated, when gets
redrawn without spaces for the buttons that could come back.
Got a crash opening games where tile pick was on and first player was a
robot. Cause: non-robot player's tiles were being assigned before the
robot's, and the move stack didn't like the out-of-order assignments.
Now we assign tiles in order as before, but pause each time we find a
non-robot that needs to pick its own.
