I just feel like: imagine if there were no Map.containsKey().
You would instead have to get() the value and see if it's not null.
If you did that, you certainly wouldn't throw away the value if you
were going to get it again right below, would you? So why would
you do it simply because of the addition of a convenient method
called containsKey()?
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5067 542714f4-19e9-0310-aa3c-eee0fc999fb1
crowd was intentional (with presents on top because it is more "generic"). We
must resist Eclipse's desire to squish our imports together into one giant,
hard to (visually) parse blob.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5060 542714f4-19e9-0310-aa3c-eee0fc999fb1
(I just noticed marshallers are importing themselves but the flash compiler
doesn't seem to mind, so committing now)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5043 542714f4-19e9-0310-aa3c-eee0fc999fb1
like this, we can think about where the interface would be useful.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4910 542714f4-19e9-0310-aa3c-eee0fc999fb1
completed, or connecting, disconnecting and reconnceting before client object
resolution completes a little more gracefully.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4889 542714f4-19e9-0310-aa3c-eee0fc999fb1
than trying to go to our previous place. If we're no longer in a place (like we
switched servers to get where we're going), then we'll try to go back to our
previous place.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4875 542714f4-19e9-0310-aa3c-eee0fc999fb1
manager prior to it being initialized or started up.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4869 542714f4-19e9-0310-aa3c-eee0fc999fb1
rather is configured with it when added to the manager as a delegate.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4868 542714f4-19e9-0310-aa3c-eee0fc999fb1
call didShutdown, so we can't stop listening to it until then.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4824 542714f4-19e9-0310-aa3c-eee0fc999fb1
manager can be collected even if the object lingers about for a while and
because it sets a good example.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4823 542714f4-19e9-0310-aa3c-eee0fc999fb1
configuration information to other peers so that they all remain in sync.
Also nixed constructor arguments to the peer manager so that it can be created
at server construct time like all other managers and be available for the
twisty maze of inter-registration that takes place during the manager init
process.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4814 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
proper interface like all the other new invocation service backends.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4795 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
dangerous with two big inner helper classes. Added the nodeName to NodeObject
and some other handy methods.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4767 542714f4-19e9-0310-aa3c-eee0fc999fb1
the fancy for loops in a case like this, but apparently it DOES work.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4754 542714f4-19e9-0310-aa3c-eee0fc999fb1
manually squirt messages into a chat history without actually sending
the message to the client.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4753 542714f4-19e9-0310-aa3c-eee0fc999fb1
provided to the object when it was created, have the LocationDirector
initialize the manager caller when it receives the PlaceObject and have it use
its client distributed object manager which tags events with the proper
clientOid. This still prevents us from running multiple clients in the same VM,
so this will probably all have to change again but this works for now.
Also some widening.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4712 542714f4-19e9-0310-aa3c-eee0fc999fb1
readObject()/no-readObject() havers otherwise everyone everywhere will have to
generate streamer methods which is way too big a PITA. Grumble.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4690 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
Michael Bayne