So broken! The XML class is not specified in the ECMA-262 standard.
Now I know why they needed the guidelines of ECMAscript: when left
to their own devices they design broken-ass shit.
Adobe needs a cork on their fork.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4932 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
This only works in the standalone debug player, if the swf is a trusted
local file.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4925 542714f4-19e9-0310-aa3c-eee0fc999fb1
Follow actionscript convention and create a reasonable name for it.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4919 542714f4-19e9-0310-aa3c-eee0fc999fb1
(Because it just uses a Map of your choosing under the hood.)
There is really no new functionality here, but it is neat, except for the one
stupid thing: keys get converted to Strings when iterating with a 'for' loop.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4916 542714f4-19e9-0310-aa3c-eee0fc999fb1
in an initObject. This is a fairly common practice in flash and let's go ahead
and use it sometimes, even though it's prone to runtime errors.
Our version of this has a defaults Object as well as another Object that can be
specified to mask properties from the initObject.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4908 542714f4-19e9-0310-aa3c-eee0fc999fb1
resulting array. Users requiring strong non-modification guarantees can manually do a deep or
a shallow copy of the array, as appropriate for their task.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4905 542714f4-19e9-0310-aa3c-eee0fc999fb1
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
"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
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
a TypedArray of int work if people fill it with strings like "4" or "9".
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4854 542714f4-19e9-0310-aa3c-eee0fc999fb1
(Dictionary supports null keys, so we merely call null a 'simple' key.)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4848 542714f4-19e9-0310-aa3c-eee0fc999fb1
inserts the element just before--not after--the last element.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4845 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
informative (and clean ><)...
While testing the ability to go straight to someone in a game from My Whirled, I was getting
decoding streaming problems (but only sometimes) when fetching the game data. After many hours
of looking for the problem and swearing up and down that it was nothing but consistent, malicious
bitrot, I've tracked it down to this.
In Underwhirled Drift (which is the game I was testing this on), I have a couple of property arrays
that get set when the game is first started up with this:
_control.set(PLAYER_STATE, new Array(numPlayers));
This allows me to fill in the proper indices at a later time in random order. This was working
fine for multi-player games, and after what I've discovered here, I think I can get away with
something simpler, but that can wait for later.
When this was getting encoded, the expected effect would be to encode a TypedArray with a null
in each spot that is defined in the source array (numPlayers long). In fact, it was creating an
empty, zero length TypedArray. I'm not sure why - but that was confusing the system somewhere
along the line so that when that set of bytes was read back from the server on another client
(for instance, when fetching the EZGameObject when trying to join an in-progress game). Of course,
zero-length TypedArrays should go over the wire just fine, so I'm not entirely convinced that I've
tracked down the entire problem (or if that is in fact the issue, then it needs to be addressed).
The diffs here will cause the encoding and decoding to correctly pull nulls out of the array, and
put them in the TypedArray. The moral of this story is to watch out for this construct:
for each (var obj :Object in arr) {
}
...it may not always be doing what you would rightfully expect...
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4827 542714f4-19e9-0310-aa3c-eee0fc999fb1
Ray Greenwell