Zyraxxis to hork.
Deep within our streaming code, ArrayMask objects were being created with
zero length when streaming non-final arrays with a zero length. This tickled
a "feature" of Adobe's IDataInput code, which reads *all available bytes*
if you pass readBytes() a length of 0.
What's really annoying is that this worked fine if you were notified
of the zero-length array via a PropertySetEvent, because that event
would come in on its own frame and so if the array's length was zero then
there were no more bytes to read. But if you entered a game and had
to receive all the usercode properties at once, it booched.
There are clumps of my pulled-out hair all around my desk from that.
And: this is ultimately my own fault, as my old code didn't handle the
case of the passed-in ByteArray having 0 length.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4900 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
completed, or connecting, disconnecting and reconnceting before client object
resolution completes a little more gracefully.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4889 542714f4-19e9-0310-aa3c-eee0fc999fb1
"Object == null" comparison. Otherwise the user might pass in an
undefined, and expect a strict equality test.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4886 542714f4-19e9-0310-aa3c-eee0fc999fb1
servers for execution. The class in question must exist on the remote server
but all of our servers are all always running the same code, so this follows.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4882 542714f4-19e9-0310-aa3c-eee0fc999fb1
than trying to go to our previous place. If we're no longer in a place (like we
switched servers to get where we're going), then we'll try to go back to our
previous place.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4875 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
outstanding know that their subscription request failed.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4873 542714f4-19e9-0310-aa3c-eee0fc999fb1
politely complain that they're talking a lot but not disconnect them.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4871 542714f4-19e9-0310-aa3c-eee0fc999fb1
(e.g toString(StringBuffer)) we use the properly renamed version
(e.g. toStringBuffer(StringBuffer)) when generating our ActionScript.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4870 542714f4-19e9-0310-aa3c-eee0fc999fb1
manager prior to it being initialized or started up.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4869 542714f4-19e9-0310-aa3c-eee0fc999fb1
rather is configured with it when added to the manager as a delegate.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4868 542714f4-19e9-0310-aa3c-eee0fc999fb1
can't ever be false. (And just above, we've already confirmed that channel != null, so this
check wasn't falling back to protecting us from that)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4867 542714f4-19e9-0310-aa3c-eee0fc999fb1
projects that use Narya and now need google-collect.jar but it had to be done.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4862 542714f4-19e9-0310-aa3c-eee0fc999fb1
Ray Greenwell