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
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.)
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.
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.
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.
been set up. Fixes assertion firing when SMS messages go to wrong app
(normal vs CrossDbg), though the right fix is to have the two apps
using different ports so they don't get each other's messages.
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.)
partway through a game. Problem was that once a channel was working
with one means we wouldn't fall back to default addressing for the
means for which we didn't have a return address yet. (NOTE: Not yet
fully tested...)
almost unique 16-bit quantity. 1 in 2^16 new games will fail because
its connID will match, but that's ok in part because it can only
happen during the time between when this is released and follow-on
version that assumes all older versions are gone.
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.
server or guest so that sender can tell when it receives a message
from itself (and reject it.) This fixes a lot of confusion in testing
where both participants in a networked game are on the same device,
but might also work around e.g. relay bugs.
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.)
