I'm pretty sure it's the BaseGameConfig.
Typically, clients don't add directly to a StreamableHashMap received
from the server, why would they? So let's just treat it as a String-key map
and shut it up.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5937 542714f4-19e9-0310-aa3c-eee0fc999fb1
Not generally useful to your everyday flash coder.
MessageBundle and MessageManager are built on top of Flex Resources,
and were already being excluded from our asdocs, and TimeUtil uses MessageBundle.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5932 542714f4-19e9-0310-aa3c-eee0fc999fb1
Let's guess the type based on the first key unserialized, and guess if it
was empty.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5928 542714f4-19e9-0310-aa3c-eee0fc999fb1
The old HashMap class was a frankenstein one-size-fits-all mess of:
- storing simple objects
- storing Hashables
- having the capability to provide external functions to hash and check
equality of any other type of key.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5927 542714f4-19e9-0310-aa3c-eee0fc999fb1
support streaming them as bytes.
It's better than writing a modified UTF String, but
it'd be even nicer if we could avoid the short to read the class name
(Enums are final), but I suppose we still have to know whether one is null
or not. Hm.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5920 542714f4-19e9-0310-aa3c-eee0fc999fb1
The other happens now in normal circumstances in msoy, and I'd rather
not surround the call to super with an if to avoid this warning, and
potentially kablooie in the future if other functionality is added
to leftLocation in this base class...
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5918 542714f4-19e9-0310-aa3c-eee0fc999fb1
Removed the unholy 'alreadyDisplayed' hack and associated return value
from ChatDisplay.
The localtype should be used to determine whether something should be
displayed. If not, why should ChatDisplay registration order matter?
It shouldn't. If there are two ChatDisplays that could potentially
show the same message and you only want one of them to, sort that
out in your own fuckin' code.
I'm not changing the Java side right now because I'd have to patch-up
a bunch of projects...
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5916 542714f4-19e9-0310-aa3c-eee0fc999fb1
Don't ask what I'm doing driving in this neighborhood.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5913 542714f4-19e9-0310-aa3c-eee0fc999fb1
No need to tell the server the callerOid, it already knows it.
This saves 4 bytes for every listener you pass into an invocation request.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5908 542714f4-19e9-0310-aa3c-eee0fc999fb1
including some implicit coercian to a Boolean, which can actually
be quite dangerous... but only with Strings and Numbers and whatnot.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5907 542714f4-19e9-0310-aa3c-eee0fc999fb1
is known by any invocation marshaller, and so the client does
not need to be passed in.
Just here on the actionscript side for now, but this change may
make its way to Java.
Other changes may follow...
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5904 542714f4-19e9-0310-aa3c-eee0fc999fb1
checking the PresentsInvoker itself and the DObjectMgr. Expose waiting for all theses queues to
empty on PresentsInvoker such that Presents servers can do things like wait for all the queues to
empty before opening to the public.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5898 542714f4-19e9-0310-aa3c-eee0fc999fb1
interface. The way this works is a little tricky, but it all works out.
We have a service SceneService with SceneMoveListener declaration. You can make
FooSceneService and have a method in that service take a FooMoveListener which
extends SceneMoveListener. An instance of FooMoveMarshaller will only be
created if you call the method on FooSceneService and that will result in an
object on the server side that implements SceneMoveListener, but calls to the
SceneMoveListener response methods will result in the FooSceneService response
codes being marshalled and sent back to the caller.
So you can pass the FooMoveListener around to code on the server that expects a
SceneMoveListener and it will magically do the right thing when server code
calls through the SceneMoveListener interface. You can even turn around and
pass the FooMoveMarshaller to another invocation service method (on a peer
perhaps) that takes SceneMoveListener and it will work because the SceneService
call will generate a SceneMoveMarshaller on the remote server, which will use
the SceneMoveMarshaller's codes to communicate the response back to the first
peer, which will unmap those and call the methods on the SceneMoveListener
interface which will remarshal them with the FooMoveListener's codes and send
them back to the client, and bob is everyone's uncle.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5891 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne