are translated by the client upon receipt. We love to translate.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1319 542714f4-19e9-0310-aa3c-eee0fc999fb1
became necesssary when *Codes were moved out of .client and into .data.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1247 542714f4-19e9-0310-aa3c-eee0fc999fb1
as they are intended to represent codes shared between the client and the
server. Made correspondingly necessary changes throughout.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1240 542714f4-19e9-0310-aa3c-eee0fc999fb1
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
Michael Bayne