"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
(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
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
Use it in SimpleStreamableObject's toString(), with some new formatting.
Unfortunately, the order of public variables seems random.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4746 542714f4-19e9-0310-aa3c-eee0fc999fb1
which parses a String like " 7pigs" as the value 7.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4723 542714f4-19e9-0310-aa3c-eee0fc999fb1
I'm not sure what I was thinking: we'll never want to auto-recognize
command:// urls in text. In the places where we'll use them we'll
format things ourselves.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4719 542714f4-19e9-0310-aa3c-eee0fc999fb1
Sigh. So not standard.
I suppose I could devise a whole system for registering protocols, and
adding registered protocols to this regexp, but we'll never have another
one of these and this is just easier for now.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4709 542714f4-19e9-0310-aa3c-eee0fc999fb1
- Added getLength().
- Took out crazy null-tolerance in equals(). If your line is malformed,
you may get NPE's trying to test equality with another line. Fix your line.
These are line segments anyway. We should maybe rename this
class to LineSegment.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4702 542714f4-19e9-0310-aa3c-eee0fc999fb1
the controller has located the appropriate function.
- If the arg for a command or callback is an array, assume those are
the parameters for the function. If you desire passing a single array
argument, you've got to wrap it in another array, otherwise single
args will be automatically wrapped for you.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4676 542714f4-19e9-0310-aa3c-eee0fc999fb1
until after the INIT stage. I don't think this particularly matters for
parameters, since if the URL is unknown it almost certainly means that we
will not need to do the custom parameter loading anyway, but let's just
make sure.
This also knocks a "known issue" off my list, and opens up the possibility
of remixed items loading content packs from a relative URL.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4646 542714f4-19e9-0310-aa3c-eee0fc999fb1
instead of a command to CommandEvent. Weirdly, a CommandEvent will never
be generated with the callback way of doing things, but now CommandMenu and
CommandButton will both support the callback syntax.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4629 542714f4-19e9-0310-aa3c-eee0fc999fb1
(to match the com.threerings.flex). Let's still put general-purpose flash
stuff here in com.threerings.util.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4613 542714f4-19e9-0310-aa3c-eee0fc999fb1
I thought maybe this was fixed, because in early betas the "with" statement
didn't work, but it does now.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4612 542714f4-19e9-0310-aa3c-eee0fc999fb1
a ROLL_OUT without having first got a ROLL_OVER?
- Clicks that land on the video control should be stopped there and not
allowed to trickle back up, potentially triggering the furni action that
someone's set on the video.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4611 542714f4-19e9-0310-aa3c-eee0fc999fb1
When you mouse-over it, the controls appear, which are currently only
a pause/play button. When it reaches the end, it autorewinds and pauses.
Things:
- We may want all videos to start paused. However, since we're not using
a streaming media server, there's no way to show the first frame without
loading the video unless we screenshot it on the server and then include
a secondary media ident, which we don't do. So: as long as the user has
to load the FLV, we may as well play it and not make it just look like
an image.
- We'll probably want to adapt this into a standalone video displayer that
can be used to view FLVs using our UI from inside a web page.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4610 542714f4-19e9-0310-aa3c-eee0fc999fb1
There are a few rough edges which'll eventually get ironed out.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4607 542714f4-19e9-0310-aa3c-eee0fc999fb1
Tom Conkling