Let's try it and see if it works. Let us know Nathan.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5728 542714f4-19e9-0310-aa3c-eee0fc999fb1
test cases I've made, it just doesn't work in *other instances*,
which I haven't yet been able to control for.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5676 542714f4-19e9-0310-aa3c-eee0fc999fb1
Apparently they enhanced AMF3 encoding in flash 10. Dictionaries
seem to be encoded differently. I'm sure they thought that they
could sneak this in because it's backwards-compatible, but they
thought wrong. If a Flash 10 client encodes a Dictionary, it
can't be read by a flash 9 client because it's not forwards-compatible.
If you change the spec, you gotta change the version number, because
this shit might be persistent.
So: work around it. Might be sketchy. Let's keep an eye on it.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5673 542714f4-19e9-0310-aa3c-eee0fc999fb1
My change to ClassUtil broke this when serializing
ByteArrays and such from a sub ApplicationDomain.
Jesus this stuff is annoying.
I have no idea why it's not the same Class when you
create a standard flash library class from within a sub AppDom.
But let's go ahead and check the object by name, then.
Hopefully this doesn't break something ELSE.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5232 542714f4-19e9-0310-aa3c-eee0fc999fb1
from screwing with our registered aliases. This might make points and
rectangles work.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4978 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