> = Miriam
> I think this is unnecessarily complicating it. If a small java
> program "logs" into the VNet server as a door in the world, then
> when it moves, it will move in the same way any other real avatar
> moves, and anybody coming into the world later will see it in its
> new position.
The door I had in mind moves relative to its frame, something that
isn't communicated by the normal position/orientation messages. If
you choose to use behaviors to distribute the door's state change,
then you run into the problem I mentioned. The current vnet server
dumps all avatar position/orientation/avatarurl info at client
login, but it doesn't give you anything else to work with.
(Aside to Steve Guynup: In the spirit of the tag game, how about
this: have a position sensor and a tranform hooked to a script. The
avatar detects position change events and delta's them out by moving
it's transform, then the script does _something_else_ with the
position and orientation messages.)
> The java program for the door probably does not log on as a real
> avatar does, since that would be wasteful. The door doesn't need
> updates of all the avatars and other shared objects' positions. Or
> perhaps get updates only from those avatars within a certain
> proximity. We need (as far as I can see) either a new kind of
> login for shared objects, or else an extension to the current
> login.
Something I should have been more clear about is that I was
speaking in the context of not changing the current server at all,
and keeping changes to the current client to an absolute minimum.
While this limits the _kinds_ of changes that can be made, it gives
us a great deal of freedom to play with ideas while not requiring
tedious rounds of client/server testing and release. It also lets me
play with new ideas and share them with others without having to
have my own public vnet server running, something that is less of a
concern to some than to others :-)
-cks
