An edge case, but: doing "new from" on a game without any connection
types crashed because of an assertion in comms that assumed
addr_setType() was being called on zero-initialized flags, which
shouldn't have been a requirement. Pulled that as well as java code that
added RELAY-type connectivity to any game that had none. If a game has
none, leave it that way.
Grab and store the local device's mac address. Add p2p as a type of
address, represented by the mac address of the recipient. Include the
local device's address in invitations sent when specified by user. Now
the WifiDirectService class is being passed a packet and the address of
the recipient; it will next need to set up sockets with every device it
encounters and map them to their mac addresses so that it can do a send.
commented-out logging of drawCell, with flags; debug-build checks that
static rects passed to java draw code aren't being used by multiple
threads at once.
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.
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.
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.
only) mpool. I'm getting assertions about failure to free now that
multiple threads are accessing open games, but I think they're bogus:
due to multiple threads modifying the leak-detection counters. This
seems to fix the assertions I was seeing in mpool_destroy().
left of tray divider (without moving divider) it may still be included
in hinted moves. Fix is to reset engine whenever the set of tiles left
of divider changes.
treatment of the final 8 bits. I'll need to release a version that
still produces the incorrect hash for compatibility with existing
clients that expect it, but that also looks for the correct hash. When
that's out there I can do a new release that sends the correct hash.
stack, go down the stack looking for a match. If it's found, pop down
to that point then apply the move. This fixes stalls in the test
engine when undo is enabled, and so I assume that undos and turns are
somehow coming in out-of-order. Should be rare that this happens.
can happen when somebody does an undo, since the ordering of undos and
moves is not assured. The result is a temporary (I think) stall, where
a move is rejected because the hash doesn't match, but that will be
accepted later when the undo's been processed and the hash will now
match.
that's real data. This fixes assertions that after popping a move off
the move stack the hash is the same as before it was pushed. It may or
may not be sufficient to fix reported stalls, but it's certainly
necessary.
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.
# 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.
# 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.
where you do "hint", then "prev hint" and get told there are no moves
found only to have the next "prev hint" succeed. This is a hack, but
the right fix is eluding me, and will certainly be riskier.
