need to be responded to. It turns out that a listener may not be
a marshaller if a server entity is calling a service request method
directly. The convenience method handles this and is also cleaner looking
for callers.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3832 542714f4-19e9-0310-aa3c-eee0fc999fb1
- OccupantInfo is created by the BodyObject
- the BodyObject is passed to the OI constructor and it uses information
therefrom to configure itself
- the PlaceManager are no longer responsible for indicating the type of
OccupantInfo to use or how to populate it.
This makes much more sense as the same type of OccupantInfo is generally used
across the entire system and it's annoying to have to have every PlaceMaanger
derived class know the type of OccupantInfo to create and know how to
initialize it. The one drawback is that only information from the BodyObject
can be used to populate the OccupantInfo, unpublished server-side only
information cannot be used (unless its stuffed into a transient field in the
BodyObject).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3774 542714f4-19e9-0310-aa3c-eee0fc999fb1
as their authentication name (which we leave in BodyObject.username). This
turns out to be simpler than the system we adopted for Yohoho wherein we
replace the player's user object after they select a character, but converting
to this sort of system is way more work than would be worth it.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3758 542714f4-19e9-0310-aa3c-eee0fc999fb1
inform the client that the shit hit the fan so that it's not locked from
making any other move requests.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3703 542714f4-19e9-0310-aa3c-eee0fc999fb1
it was trying to print where() which failed because it was doing so
before all the values were intialized.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3680 542714f4-19e9-0310-aa3c-eee0fc999fb1
of having an error triggered right after this one that happens to print
a stack trace look like the matching stack trace for the original error.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3679 542714f4-19e9-0310-aa3c-eee0fc999fb1
now that all the scene updating stuff has been cleaned up. Basically we
can't rely on the updating process itself to assign a portal id, updates
must be created with all the information they need before they are applied
to the scene.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3451 542714f4-19e9-0310-aa3c-eee0fc999fb1
needed all told, but I like to see the number keep going up.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3438 542714f4-19e9-0310-aa3c-eee0fc999fb1
you had logged on to one ocean and then moved to another, the previous
ocean's sceneIds are still in the scene cache.
Fix: Clear the scene cache both when we log off and when the scene repo is set.
Also, I made the cache be a LRUHashMap holding a measly 5 scenes.
Why are we filling up memory on the client with scenes that may or may not
ever be revisited?
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3385 542714f4-19e9-0310-aa3c-eee0fc999fb1
CommunicationAuthorizer and rolled that into the BodyObject-based
permissions system. A victory for consolidation and elegance.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3380 542714f4-19e9-0310-aa3c-eee0fc999fb1
messages if repeat requests come in or for some reason the client and
server ever differ in opinion as to which scene the player is in.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3363 542714f4-19e9-0310-aa3c-eee0fc999fb1
There is no more SafeInterval, instead Intervals can be constructed with a RunQueue to use for expiring.
PresentsDObjectMgr implements RunQueue.
Client has a getRunQueue() method to get the client side RunQueue.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3283 542714f4-19e9-0310-aa3c-eee0fc999fb1
generator. It handles inner classes slightly differently and prepends a
project-specific header to the generated classes.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3239 542714f4-19e9-0310-aa3c-eee0fc999fb1
Mike Thomas