Add a third processor type to the .so, and fix first compile-time
warnings and then a few dumb bugs based on assumptions about ptr sizes.
Works to play networked games and browse wordlists, but is not
extensively tested and needs to be before release.
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.
Seeing the occasional crash and trying to plug leaks that might be
contributing. I think I fixed the Gameptr.finalize() assertions I've
been seeing forever but the thread match assertion remains. Logs will
help catch that.
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.
So far uses curl and json-c to send b64-encoded data to new script
which is able to echo the data. Next that script will need to open a
UDP socket to the relay and return results that appear before timeout.
Make face-up tile picker util method return void and add mechanism for
passing in selected tiles asynchronously, as has been done recently with
the rest of the once-blocking util callbacks. Works perfectly in the gtk
case. Likely crashes in curses (if picking face-up option is on.) In
java all the callbacks are there but rather than put up a UI we pretend
the user says "pick 'em for me" each time. Putting up a UI is next.
Continue conversion of alerts that required blocking the JNI thread. Now
board_commitTurn() takes a second boolean indicating whether phonies
found have been approved by user. Common code informs user, and if he
approves client code calls board_commitTurn() again. In case where
turn's lost there's no call to make back, but there's the undesirable
change that if a robot moves next its move will be reported on top of
the turn-lost alert. Ideally new alerts would appear under, not on top
of, those that have not yet been dismissed.
Next step in converting util_ methods that required blocking: blank tile
assignment. Now post a query and add a method that the client code can
call when the user's decided. Include enough state (col, row, and
playerNum) so that it's probably pretty safe.
Probably breaks curses build, but for gtk and Android
turn move and trade confirmation into a two-step process, making
board_commitTurn() non-interactive when called with a second
parameter. The old blocking util methods now return void and it's up to
the client code to interact (on the main thread) then re-call
board_commitTurn() if appropriate.
First attempt to stop blocking the jni thread: instead of returning a
password from a util_ method, have it include enough state that the UI
can return, put up a dialog, and then pass that state and the password
back and have them matched up again. I think this will work for the
remaining blocking Alerts too.
I think this was related to changing the order in which save operations
happen and that it's no longer valid to insist that there already be a
rowid at this point, but could be wrong....
Fixes problem with list view always being a move behind, since it's
saving not summarizing that was triggering the refresh, but summarizing
that added the data from which refresh/list view drew.
Idea is to have the games list stay in sync, but in fact it stays one
move behind, at least in a typical standalone human-vs-robot game. So
this is incomplete.
There are some screen dimensions, especially with dual-pane mode, where
the board is just bit narrower than the screen. Rather than have narrow
white borders, allow the cells to take up the slack. The API takes an
upper bound on the ratio of width to height so things shouldn't get too
odd looking.
Mistaken option to gtk_box_pack_start() meant the scrollbar got
allocated space along with the board when the container expands, not
what you want with a scrollbar.
Trying and failing to get just the content area of the tree view to
scroll, whether by putting it in its own container or hooking into the
scrollable interface tree view allegedly supports.
Toward something that should work with android: pass a potentially
unique draw context into new method that creates a new board just for
the draw and makes its scoreboard and tray disappear.
Done in a way that won't work for Android just to try out the gtk
way. Tweaks and reuses the existing draw context and board, which is
precisely what the android version can't easily do.
Add new "snap" blob to db and pixbuf column to games display table, and
add code to store and retrieve from db. What's stored now is a
hard-coded file, so next up is generating an actual snapshot from the
game.
When a gtk3 window's shutting down it appears we can't get a cairo_t*
for it. This change makes it possible to turn that fact into aborting
the whole draw operation.
Whenver we get the draw signal, invalidate the whole board and draw
it. This is resulting in a lot of wasted effort that might be mitigated
if I figured out how to get the invalid region out of the cairo_t*
that's passed in, but this is a test app and my machine's pleny fast. So
go with it for now.
Board renders, but only when touched. Tray and scoreboard skipped for
now. Lots of changed still to go, and some asserts added where I didn't
want to stop to solve a compile problem.
stack. That *seems* to fix it always returning 0, something that
changed with newer version of linux or libbluetooth or who knows
what. BT still doesn't work from linux, but this is a necessary start.
count them, and do so based on new msgNo passed from comms that's
concatenation of channelNo and msgID so that duplicates (over multiple
transports) aren't counted twice.
# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
#
# Lines starting with '#' will be ignored, and an empty message aborts
# the commit.
side translate that into showing the sender's name in
notification. Not yet done: replacing silly "not me" in chat listing
with same, but now it should be easy.
Conflicts:
xwords4/android/XWords4/archive/R.java
side translate that into showing the sender's name in
notification. Not yet done: replacing silly "not me" in chat listing
with same, but now it should be easy.
works between linux and Android clients. Required renaming so struct
names and names of fields within match in c and java code. The point
is to test this as the foundation of rematch: now you have to type in
a deviceID in order to invite, which clearly sucks for users. Either
that goes away, or it's replaced with something that scans existing
games and lists past opponents as possible invitees.
the case where one of several guests wants to rematch is a hard
problem for later.) Requires passing old-style relayIDs (connname plus
device index) when devIDs aren't available, which they may not always
be.
for Rematch): works for linux version, provided you know the relayID
of the device you're inviting. Added to common/ a stream-saving
version of java's NetLaunchInfo I'll probably want to use there too
for cross-platform compatibility (there being no jni support for
json.)
Note: because the substitution is done in common code I can't use the
positional specifiers (%1$s vs %s) and so this breaks the generated
"translations". The scripts that do the generation need to be fixed to
understand the formatted="false" attribute.
here's a command that works, providing the game's wordlist and rowid:
run --game-db-file /tmp/xwdb --game-db-id 799809255 --dict-dir \
/var/www/and_wordlists/English --dict-name TWL06_2to15.xwd
quantity through to java world, use it, convert English <string>
resources to <plurals> (using python script) based on parallel changes
in French, and modify callsites to call getQuantityString() where
R.string.xxx became R.plurals.xxx.
# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
#
# Lines starting with '#' will be ignored, and an empty message aborts
# the commit.
what's going on when multiple participants in a single game are on the
same device. But for a couple of strings passed into the jni the
changes are only in DEBUG code.
needs to save it there on receipt of an invitation (doesn't create
full game with comms until later.) Passes discon2 tests and seems to
work on a single Android device. (Haven't tested inviting on Android
yet.)
An invitation works with relay and (fake) SMS on, and the invited
client connects successfully using both (the second to arrive being
correctly identified as a dupe.) While the game can be played after,
only SMS messages are being received. And opening a saved game
crashes.
Works for large numbers of relay games in test, but will not yet
actually hold more than one value. Should be safe to merge to main
branch once stream upgrade is verified.
devid you tossed your relayID and reregistered. Which meant any
existing messages meant for your relayID were orphaned, and any open
games didn't know who they belonged to until you reconnected to them
with your new relayID. So: modify the UDP protocol (though not on
Android yet) to include both relayID and devid with registration, with
one or the other an empty string if not present or not changed from
earlier. I can't fix existing clients that are dropping their
relayIDs, but when one does a re-connect without a relayID I can look
it up from the existing game record, then reuse it rather than issue a
new one. Better than nothing -- and that protocol will be obsolete
soon anyway.
