These are the preferred way to get instances of Boolean, Byte,
Short, Character, Integer, Long, Float, and Double object.
It's always made sense for Boolean objects, and with 1.5 these factory
methods were blessed as the proper way to get instances unless one
absolutely needed a distinct object.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4145 542714f4-19e9-0310-aa3c-eee0fc999fb1
also added a log error message to my equals() logic error checking.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4141 542714f4-19e9-0310-aa3c-eee0fc999fb1
interface and specific games can define their own concept of a location.
Portal and SceneLocation now both have a Location instance within them.
All the whirled stuff is happy not knowing the details of the Location even
though it manages portals and other such goodies. The 'stage' stuff
does need to know, and yohoho uses the new StageLocation class
that is essentially identical to the old 'Location'.
SceneLocation previously extended Location, and there were a lot of places
where they were used somewhat interchangeably, or a SceneLocation and
a regular Location were compared. This shouldn't be done anymore and I've
left in code that should dump stack if it occurs, so that we can spot
these logic errors at runtime.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4140 542714f4-19e9-0310-aa3c-eee0fc999fb1
object in the SceneDirector to be overriden. The ZoneDirector needs to
inform its listeners when a zone change is made during this failure
case.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4087 542714f4-19e9-0310-aa3c-eee0fc999fb1
with Location subclasses as easily as possible. Subclassing the ruleset
and returning a different instance for Location should do the trick.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4077 542714f4-19e9-0310-aa3c-eee0fc999fb1
with 3d coordinate systems (or that track additional location information
besides orientation) can just drop in their new Location class.
Refactored Portal to contain a Location object rather than duplicate
the fields, so that Portals can work unchanged with a 3d coordinate system.
Note: I haven't yet updated SpotSceneRuleSet.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4072 542714f4-19e9-0310-aa3c-eee0fc999fb1
looking it up by name which creates PITA when we want to obfuscate and strip
out unused code.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4026 542714f4-19e9-0310-aa3c-eee0fc999fb1
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
Ray Greenwell