longer maintained. Implementations can choose to create their own
authentication thread if they wish or use some existing combination of the
invoker and dobjmgr threads. Also added an invoker to the base server
class.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1085 542714f4-19e9-0310-aa3c-eee0fc999fb1
zone entry request and for it to be notified when a zone entry is
completed. (So that it can do any processing that it might care to do.)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@957 542714f4-19e9-0310-aa3c-eee0fc999fb1
we need to use it on the client. This will necessitate some CVS jockeying
because the server/util directory no longer exists in the repository.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@892 542714f4-19e9-0310-aa3c-eee0fc999fb1
added some checks to avoid sending cluster speak requests unless we
currently occupy a location that is in a cluster.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@806 542714f4-19e9-0310-aa3c-eee0fc999fb1
than a place service (which may be changed back when place services
improve or I may change the main chat stuff to be an invocation service).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@803 542714f4-19e9-0310-aa3c-eee0fc999fb1
the scene registry automatically register the scene provider when it is
constructed.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@791 542714f4-19e9-0310-aa3c-eee0fc999fb1
SceneDirector which, without multiple inheritance, would make it
impossible to use both in a single client. Of course, we need to use both
in Yohoho!
So I refactored the whole enchilada to delegate rather than extend, which
blows because various methods must now be made public and a particular
failure case for the moveTo request now requires that a special failure
handler interface be made available so that LocationDirector "extensions"
can inject themselves into the failure handling process.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@789 542714f4-19e9-0310-aa3c-eee0fc999fb1
SpotSceneManager now actually does the proper assignment in
populateOccupantInfo and it does so having been warned that a body is
entering via a particular location by the SpotProvider when it processes a
traversePortal request. If the user enters a scene via some other
mechanism (like a zoned moveTo request), they will be assigned to the
default entrance for the scene, which is what we want. We also avoid the
extra occupant update that was necessary with the previous method. Yay!
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@788 542714f4-19e9-0310-aa3c-eee0fc999fb1
tracking and reporting locations of bodies within a scene and handling
chatting between users in a cluster. Other minor cleanups.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@774 542714f4-19e9-0310-aa3c-eee0fc999fb1
model as we'll be having scene names in the runtime system.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@757 542714f4-19e9-0310-aa3c-eee0fc999fb1
it's the one that knows which location ids are in use.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@748 542714f4-19e9-0310-aa3c-eee0fc999fb1
the way I was doing inheritance between the display and editable scene
implementations was not copacetic. The new method (which is for every
editable scene impl to delegate to a display scene impl so that regardless
of how far along you are on the inheritance chain, there are only ever two
actual objects, the display impl and the editable impl) is somewhat
cleaner, but makes it clear that no method can work as nicely as it would
were we to have mutliple inheritance.
The basic problem is that the editable versions of the scenes have to be
able to manipulate the instance variables in the display versions of the
scenes because they have to keep them up to date so that they are
displaying the right thing. As the editable versions are in different
packages, they don't have access to the display instance variables, so the
display versions simply have to make available enough "editable"
functionality to allow the editable versions to get their job done. It's
more coupling that I'd like, but at least it's only between the display
and editable versions across the inheritance hierarchy rather than down
the hierarchy.
Blah.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@745 542714f4-19e9-0310-aa3c-eee0fc999fb1
the new new style (or was that the new new new style).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@739 542714f4-19e9-0310-aa3c-eee0fc999fb1
Augmented standard scene and spot scene models with versions that provide
access to data only needed by the editor and loader. Filtered that whole
paradigm down through the locations and portals and all that.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@737 542714f4-19e9-0310-aa3c-eee0fc999fb1
higher-level mechanism. Zones provide zone summaries which can be used to
generate maps of the zones on the client.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@727 542714f4-19e9-0310-aa3c-eee0fc999fb1
ZoneDirector can extend the moveTo process to incorporate zones.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@726 542714f4-19e9-0310-aa3c-eee0fc999fb1
can extend it when extending the Whirled services rather than having to go
down to CrowdClient and cut Whirled out of the loop.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@724 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne