out in this order now. This should not be non-deterministic. Reflection should
give me the methods in the order they are declared in the Java class so I don't
know what the major malfunction is here, but if it keeps up I'm going to
fucking alphabetize them and be done with it.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@95 c613c5cb-e716-0410-b11b-feb51c14d237
between the Java and ActionScript version since ActionScript doesn't support
method overloading. We only have to observe this limitation in Streamable
classes.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@88 c613c5cb-e716-0410-b11b-feb51c14d237
because otherwise the EZGameController will try to unmarshall the value.
The marshalling/unmarshalling is purely clientside, the server doesn't
understand how to do it, so it must dispatch a different event that just
contains a nice normal integer.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@85 c613c5cb-e716-0410-b11b-feb51c14d237
Hopefully this'll fix yohoho's problem with the puzzles sometimes not restarting after stars are filled.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@81 c613c5cb-e716-0410-b11b-feb51c14d237
preserved with old games that only override getPlaceObjectClass(). Nothing
should be using PuzzleObject directly anyway.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@76 c613c5cb-e716-0410-b11b-feb51c14d237
They *are* just updates, but if it's ok for them to not load then a
game-specific scene repository needs to make that decision and just
return a blank update list rather than throwing an exception.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@68 c613c5cb-e716-0410-b11b-feb51c14d237
dispatched message event system. Rearranged the methods in GameManager into
some semblance of order.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@60 c613c5cb-e716-0410-b11b-feb51c14d237
createPlaceObject() because it needs to fall back to PlaceManager's
createPlaceObject() which calls getPlaceObjectClass() which all GG games
currently use.
It doesn't really make sense for GameManager to implement that method anyway
because no one will ever just use a GameObject, they'll need some sort of
derivation if they want to have any game state at all.
Really that method should be abstract in PlaceManager and GameManager but I'm
not sure we could change that now without breaking things (certainly we
couldn't preserve backwards compability which renders the idea moot anyway).
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@59 c613c5cb-e716-0410-b11b-feb51c14d237
if implemented by something on the display hierarchy.
You may also implement them in utility classes and register and unregister
event listening by hand.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@55 c613c5cb-e716-0410-b11b-feb51c14d237
so not everything is converted. I'll revisit once I've decided what to do.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@49 c613c5cb-e716-0410-b11b-feb51c14d237
We'll be using this in game gardens, at least.
Note that the actionscript side currently doesn't compile because of
limitations in building a .swc file, but that'll be fixed soon.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@47 c613c5cb-e716-0410-b11b-feb51c14d237
compiling, but I'm playing around with building .swc libraries to cut
down on the build time of the client.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@46 c613c5cb-e716-0410-b11b-feb51c14d237
Michael Bayne