though annoyingly now I can't reproduce it. Call Heisenberg!
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5712 542714f4-19e9-0310-aa3c-eee0fc999fb1
Have the FrameReader stop listening on the socket when we're done with it.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5707 542714f4-19e9-0310-aa3c-eee0fc999fb1
in the ClientEvent that is sent out with all will/didLogon and will/didLogoff
notifications.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5681 542714f4-19e9-0310-aa3c-eee0fc999fb1
log our boot groups to make it easier to distinguish which "server" we're
logging onto.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5675 542714f4-19e9-0310-aa3c-eee0fc999fb1
This has been wacked-out like this ever since I first wacked it out.
Since the base class is ResultAdapter and it only takes failure, and the
'processed' function for ConfirmAdapter is optional, it seemed to make
sense this way.
But, we have another ResultAdapter (for non-invocation ResultListener)
and it expects success first.
So Mike noticed this today (I swear there was a big brouhaha about this
over the summer) and beat me with my own rubber chicken.
I'm not sure why I had a mental block about reordering, but let's do it!
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5583 542714f4-19e9-0310-aa3c-eee0fc999fb1
* Use _writer != null iff the socket is open and the authrequest has been sent
* Warn when posting messages prior to socket connect
* Clear the outgoing queue prior to sending the auth request, the servers authing connection expects this
* If a logoff is encountered prior to the socket opening, just shut down without sending auth request
* Driveby unused variable removal
This should fix the log warning "AuthingConnection$1: Received non-authreq message during authentication process"
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5548 542714f4-19e9-0310-aa3c-eee0fc999fb1
utility in sending pings before we're authenticated.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5543 542714f4-19e9-0310-aa3c-eee0fc999fb1
frame listener so that it has a chance of working out of the box on Thane.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5432 542714f4-19e9-0310-aa3c-eee0fc999fb1
except the actual throttling part. Need to think about a good way to do this
without blocking the whole client when we hit the throttle.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5428 542714f4-19e9-0310-aa3c-eee0fc999fb1
* socketClosed was issuing a warning, presumably because whirled doesn't normally disconnect flash client. Anyway, seems like overkill since the server can disconnect whenever it choosed
* Accoring to adobe, calling Socket.close after the Socket.close event should throw an IOError. Thane holds to this, while flash apparently does not. Make our code neutral by checking for connected prior to calling close
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5415 542714f4-19e9-0310-aa3c-eee0fc999fb1
you should always listen for the result! Otherwise, you are likely doing
something wrong. Listen for the result, or change the service to not report
a result if it's irrelevant.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5374 542714f4-19e9-0310-aa3c-eee0fc999fb1
and clear out our socket. The DID_LOGOFF notification is sent out to the client
after we've sent our LOGOFF request to the server, so we need to be sure that
no other messages go to the server after the LOGOFF request otherwise we risk
the server generating spurious warnings (like it does currently in the
thousands daily).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5297 542714f4-19e9-0310-aa3c-eee0fc999fb1
services that require the use of an otherwise unreferenced class or symbol take
care of referencing that class or symbol themselves, so that if you use
LocationDirector, say, all the needed classes are properly included.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5120 542714f4-19e9-0310-aa3c-eee0fc999fb1
(I just noticed marshallers are importing themselves but the flash compiler
doesn't seem to mind, so committing now)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5043 542714f4-19e9-0310-aa3c-eee0fc999fb1
and instead my checkin message got mangled.
*clearing throat*
..So our old way of doing things was pointlessly waiting a frame to handle
network events.
We also ran object subscribe/unsubscribe requests through the same queue,
and now those are processed immediately. Everything seems ok, but let's
keep an eye out.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5016 542714f4-19e9-0310-aa3c-eee0fc999fb1
This was residual from the initial conversion from Java, but I don't think
it's very necessary on the flash side, and Zell is working to decouple
the presents layer from flash-player specific classes and events like
ENTER_FRAME.
So now we just process everything immediately.
I did some tests, it seems that the flash player dispatches ENTER_FRAME,
then it dispatches any network events, then the frame is rendered.
So our old way of doing things was pointlessly
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5015 542714f4-19e9-0310-aa3c-eee0fc999fb1
AnimationManager and that I saw in use in Tweener: just
listen for ENTER_FRAME on some random sprite.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4926 542714f4-19e9-0310-aa3c-eee0fc999fb1
did logoff between a real logoff and a server switch.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4894 542714f4-19e9-0310-aa3c-eee0fc999fb1
Putting you at the top level screws up use of another Log class.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4874 542714f4-19e9-0310-aa3c-eee0fc999fb1
that EZGame can batch up state change requests which are all invocation service
requests.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4844 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne