(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
them to a single number becomes inconvenient for values larger than an single int, and tricky
when the value is negative (i.e. in two's complement split into two words, with sign bit only
in the high int).
Instead of splitting a long into two ints, we store it internally as a byte array that corresponds
exactly to Java's serialized version (sequence of eight bytes, high byte first), and we provide
accessors to convert to and from Actionscript numbers. This makes Java Long values readable in
Actionscript, and vice versa.
Unfortunately, Actionscript does not have a native 64-bit integer - the closest equivalent is the
Number class. Since this is a double float with a 52-bit mantissa, very large long values will
suffer precision loss during conversion.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4811 542714f4-19e9-0310-aa3c-eee0fc999fb1
processing. This enables subclasses of ChatDirector to listen for their own
types of chat messages, but call the superclass to process them.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4810 542714f4-19e9-0310-aa3c-eee0fc999fb1
listeners letting them know that we're no longer in a location.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4805 542714f4-19e9-0310-aa3c-eee0fc999fb1
logging on the console so let's not be uninformatively verbose.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4803 542714f4-19e9-0310-aa3c-eee0fc999fb1
be extended to contain the sceneId by Whirled (Vilya's Whirled, though also
Whirled Whirled by extension) so that we don't end up with problems where
BodyObject.location changes but BodyObject.sceneId remains stale. This won't
impact Yohoho because the Yohoho client is always in a scene, it uses a
separate mechanism to track games, whereas Whirled's natural usage is to move
between scenes and non-scenes.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4779 542714f4-19e9-0310-aa3c-eee0fc999fb1
our code generation stuff is not the ultra-sophisticated, but we'll cope.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4764 542714f4-19e9-0310-aa3c-eee0fc999fb1
Ray Greenwell