-- and to detect when an incoming move doesn't make sense. These
latter changes may not be necessary now that hash code is checked
first thing, but can't hurt, and there will be devices without hash
codes for a while.
when a devices sends to self via SMS and client winds up getting a
registration message it just sent. Not perfect yet (and may require a
change in the comms protocol -- that's not versioned :-(.
so that snapshotting made score strings disappear. Also rename
stream_copyFromStream to stream_getFromStream to make it clearer that
the src is modified. And swap params in stream_setPos().
it if any players are missing. Idea's to allow for non-relay devices
the invitation opportunity that comes when a game connects to the
relay and learns that no other games have joined its room.
with 15x15 and 17x17 (and presumably larger) with the old games being
upgraded mid-game: when server's new and wants to use a larger board
but not all clients are capable, shrink the board; and, when new
server is opening state saved by pre-upgrade code, assume a non-0
proto version for clients that registered earlier (as old code didn't
save the client's proto version.)
clients to append their stream version to their inital connect
message. (The format can't change, so detecting additional length was
the only option. comm.c on existing clients won't allow more than one
connect message per channel, so adding a new to be used in addition
didn't work.) New servers detect this; old will ignore. Track the
version (implicit or not) of all clients, and use the lowest any
supports, so that new server and all new clients will use newer proto.
MAX_COLS was larger than 16. In order that old-style messages on
relay be readable by new-style code on device, modified server.c's
protocol to include stream version. But: unless I come up with a
better way of doing this all devices will have to be upgraded at the
same time: old won't be able to read the new format as it's done here.
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.
played that include that tile and pass to new util_cellSquareHeld()
method. In java implementation of that method, use existing lookup
activity code to display list of words. Enabled on the C side by a
compile-time flag in case it has problems. Right now the time spent
saving a game before launching the lookup activity, and reloading it
after, is pretty apparent, but that's in emulator which is slow.
util_userQuery(QUERY_ROBOT_MOVE) with new util_informMove(), into
which the number of words formed and the words themselves are passed.
The process of consing up the score explanation was already passing
over the model, so storing the words is very little effort, and will
save a call back into the model where the user actually wants to do
the lookup.
uses existing stack and undo features to run a WordNotifierInfo over
some number of scoring passes to gather the words seen. Seems to work
as tested from gtk version. Now need to try from android....
one and changing the site that used it to use the other. Not visible
outside of common, but should make it easier to harvest a list of all
words for one move or the entire game.
where games with more than two devices would hang because server.c
code was dropping messages that comms.c code thought were good and so
ACK'd preventing them from being sent again. They were being dropped
because the game was in the wrong state after displaying a move-made
dialog because the state it was to move to after doing that display
had not been saved.
passing a 0-length array of bad words. That in turn suggests a
screwup where a move's rejected for some reason other that a word not
being in the dictionary. This is all supposition, and all stuff
that'd be caught by asserts in a debug build, but: when there are no
bad words don't report them -- even if the move's rejected.
not yet received on device. Meant to be included in summary. I'm not
happy with how much code it took to figure this. I don't know
server.c all that well any more.
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.
implemented (when not smart) as trying to match the human's score to a
per-robot value between 1 and 100 that gives the percentage of best
moves to store before picking randomly from among them. So a 1 means
save only the best move and always pick it; 100 means save all the
best moves (how many are saved is compile-time configurable) and pick
one of them. Because it's settable per-robot a smarter robot can be
played against a dumber one (though I may choose not to make it
settable per-robot on shipping versions.)
into the java world by making it a util_ctxt function. Do same on
linux to test. We'll see how it is -- and can back this commit out if
there's no improvement.
meaning it'll work on any tranport but relay doesn't know about it.
(If relay knew about it I could send a "shutting down for a minute"
message to every connected device, which would be cool. But this is
easier.) Written, BTW, enroute from Seattle with help from beer from
Chris in first class. :-)
game works to completion with both signing up as guests (no -s) with
one local and one remote player (identical commandlines.) Not yet
tested: if any signs up as a host, reconnecting rather than
connecting, etc. This is just a snapshot.
possible moves in either order both within a cached subset and when
building cached subsets. Still a bit buggy (shows the same move twice
when moving backwards and reaches the top-scoring move) and not well
tested.
one from before gameSeconds was being preserved in the stream by
write_gi code. I fixed this on a branch a week ago as well, so look
for a merge glitch. Need now to confirm that I'm sending char lists
in initial connect message in the right (null-separated utf8) format.
