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
texty-input components that wish to have the chat system leave their focus
alone.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4626 542714f4-19e9-0310-aa3c-eee0fc999fb1
EXACTLY held. I think this is ok because all callers currently pass a single
token at a time, but I have not verified this for every project.
Please verify this for your project!
Added holdsAnyToken() which has the old behavior of returning true if any
bit is on.
I think we should change all the projects' various isSupportPlus() methods
to be just called isSupport() and those will return
holdsAnyToken(SUPPORT | ADMIN | etc);
If you need to check if a user has a single SUPPORT token but is not an
admin, you can do that by hand.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4617 542714f4-19e9-0310-aa3c-eee0fc999fb1
objects to non-modifiable, restrict client object subscriptions to the client
in question). Modified Peer code to not log a warning when a peer is not online
in an expected way (not listening for connections).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4598 542714f4-19e9-0310-aa3c-eee0fc999fb1
notion of a global group (though we implicitly define one in InvocationCodes)
added a mechanism for directors (which generally handle the client side of
invocation services) to register their interest in bootstrap service groups so
that the whole goddamned complex business can happen magically behind the
scenes.
If you instantiate a director, it will automatically register interest in the
service group it needs and everything will work. If you don't use the director
code, you don't get the services and you can safely exclude all of that code
from your client even though the services are still in use on the server (and
presumably used by some other types of clients).
This is going to break all the builds, which I'll soon fix. Then I'll go write
all this in ActionScript. Yay!
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4552 542714f4-19e9-0310-aa3c-eee0fc999fb1
There is no recent (~years) modification of this line, but at the same
time it appears that none of our products use the LocationProvider.moveBody()
method, so maybe this bug has just never been tickled.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4549 542714f4-19e9-0310-aa3c-eee0fc999fb1
It was always a little special, since it's dispatched from the client, but
I want it to be handled like other messages so that we can recolor
different parts of the message as I do in metasoy.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4495 542714f4-19e9-0310-aa3c-eee0fc999fb1
one another whether they've already displayed a chat message.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4421 542714f4-19e9-0310-aa3c-eee0fc999fb1
field/method names for the ActionScript version of a class (or to omit
something entirely). This removes the need for special case hackery for
toStringBuilder().
In order for annotations to work, however, we have to require that the
GenActionScriptTask be loaded from the same classloader that loads the classes
to be reflected upon. Before we only reflected on the target classes, never
instantiated them. Annotations are actually instantiated, so we have to be able
to create an instance of the ActionScript.class that is compiled into our
target classes and assign it to a reference that is compiled into
GenActionScriptTask. Beware the complexities of dealing with multiple class
loaders.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4405 542714f4-19e9-0310-aa3c-eee0fc999fb1
like Groovy and JRuby. Created a DynamicEventDispatcher that automatically maps
attribute, element and set events to methods. Say you have a field:
public DSet occupantInfo;
you can create a method in any class:
public void occupantInfoAdded (BodyObject source, OccupantInfo entry);
and then bind that class as a listener using the dynamic event dispatcher:
_myobj.addListener(new DynamicEventDispatcher(object));
I also created a nicer replacement for the MessageHandler system which is
clunky but still way simpler than using a full InvocationService. Basically we
dispatch MessageEvent as if it were a method call.
For example, in AtlantiManager I define:
public void placeTile (BodyObject placer, AtlantiTile tile)
which receives a request by a player to place a tile on their turn. Then in
AtlantiController, I simply call:
_atlobj.manager.invoke("placeTile", tile);
Of course, in JRuby and Groovy, that's going to look like:
_atlobj.manager.placeTile(tile);
which is all part of the fun.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4344 542714f4-19e9-0310-aa3c-eee0fc999fb1
distributed objects by reflection since we don't allow clients to create
objects, furthermore we needn't do it asynchronously. The object creation
methods were moved into the server-side only interface and made "immediate", so
the caller creates a derived instance of DObject and registers it with the
system instead of creating it with a Subscriber callback.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4342 542714f4-19e9-0310-aa3c-eee0fc999fb1
Also, while I was in there, added some safety so we don't lose track of shutdownIntervals and let them run amuck.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4295 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne