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.
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.
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.
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.
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.
Conflicts:
xwords4/android/XWords4/src/org/eehouse/android/xw4/DlgDelegate.java
xwords4/common/comms.c
xwords4/linux/cursesmain.c
xwords4/linux/cursesmain.h
xwords4/linux/gtkmain.c
xwords4/linux/gtkmain.h
xwords4/linux/linuxmain.c
xwords4/linux/main.h
xwords4/linux/scripts/discon_ok2.sh
xwords4/relay/xwrelay.cpp
(Note: The curses app crashes on exit with mempool assertions, but that's a problem before the merge.)
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.)
message over and over when getting updated by GCM. The problem
occurred when one device had an un-ACKable initial message still in
its queue. I call resendAll a lot, which caused that message to get
resent to the other game which then replied without being able to ACK
it so it remained to be sent again. This would continue until users
moved forward in the game. The fix is to add a backoff timer to
resendAll() so that it can't loop. The timer is reset when an ackable
and new message is received, meaning there's been a change in what's
available to resend. And since users calling resendAll manually
expect it to do something, add a force param that ignores the backoff.
seems to fix the problem (but needs a lot of testing.)
dict, give chance to switch, and to download if required. Because of
the way the JNI thread works, and JNI's requirement in general that
env instances match up (e.g. dicts must be destroyed in the same
thread that creates them), substituting into a live game is too hard.
So the game's saved with its new dict and then reloaded.
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.
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.
to query model for values. Now everybody else queries new model API
rather than client via util_getSquareBonus(), model uses its internal
values if present otherwise falls back to util_getSquareBonus(), and
internalizes the array as part of the game. Now it should be easier
to have different bonus patterns and to have them exchanged as part of
network game init.
to enable it for a game yet). In common code, break pick tile utils
method in two, one for blank and the other for tray tiles. In java,
implement dialog for picking the tiles. Works, though is a bit clumsy
to have the dialog come and go after every pick. Better would be a
dialog that stays up and accumulates picks -- but it'd have to know to
reduce the set of tile choices as letters are chosen. This'll do for
now.
