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
everything in two languages. Especially when one doesn't support inner classes
and has non-C syntax just to make life easier for parser writers.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4762 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
because the oldValue variable didn't contain UNSET_OLD_VALUE, but
rather null because it was set that way in the constructor.
Additionally, some of the constructors would only set the old value
if it wasn't null, which is also wrong because an old value can
easily be null.
We could probably just rip apart most of this code, because for
the most part events are not constructed on the client anyway. We might be
able to get away with just making all the event constructors 0 arg, and
then we don't have to worry about UNSET_OLD_VALUE, we just always apply.
But let's try to be more similar to the Java code, and so now I emulate
multiple constructors by checking how many arguments were provided and
not configuring event-specific data if it wasn't actually provided
to the constructor.
Note: none of this would be necessary if we could just declare a constructor:
public function AttributeChangedEvent (
targetOid :int = 0, name :String = null, value :Object = null,
oldValue :Object = UNSET_OLD_VALUE);
But you can't use constants as the default value in a parameter list
(commence being boggled) so we have to use null instead of UNSET_OLD_VALUE
as the default value, and then check the 'arguments' special variable to
see if someone passed in null or whether it came from the default value. Aiya.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4726 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
them to the appropriate ChatDisplay when we're doing chat in IM-style
individual windows.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4663 542714f4-19e9-0310-aa3c-eee0fc999fb1
except that messages will never leave the server. If generated on a client,
they'll go to the server and be processed like a normal event there
(event handlers will be called) but the event will not leave the server and
be sent to subscribing clients.
Changed the ManagerCaller used by PlaceObjects to use ServerMessageEvents.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4648 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
Michael Bayne