[X3D-Public] interest in network sensor / client based server software
eric at geovrml.com
Tue Jan 7 07:21:27 PST 2014
In my implementation, the avatar that took the key is the owner, and
it's reflected in the scenegraph: the key isn't on the door lock
anymore, it's in the hand of the owner, and moves with the owner. No one
but the owner may open the door, unless someone steals the key to the guy.
This is possible, and options are open, let's call owner Avatar A and
the stealer Avatar B:
- the guy AvatarA owning the key is an avatar, then it's own AI is
'unplugged' and incoming messages *at semantic level* is output to the
user in charge "From, AvatarB, TAKE, zeKey" obviously this answer here
would be a boolean, so the message would be presented with a yes/no
option. User chooses ....
- the guy AvatarA owning the key is a robot, and AvatarB is an avatar:
we take for granted that B knows better and he actually grabs the key
(in the scenegraph, the node is now under AvatarB.
- Robot/Robot unlikely to happen, or it is scripted in the scenario or
handled by external AI and the outcome is known
- Avatar/Avatar: In the AvatarA screen, "From, AvatarB, TAKE, zeKey" is
answered, and the answer triggers the action. Eventually, an avatar may
fight another, or we have plenty of revolvers, guns, rifles,... that may
be available around for 'taking' and 'using' if problem can't find a
I don't need a responsible here. All -mobile- objects may be taken,
used, released etc ... their position in the scenegraph tells about
their owner or availability. Classicaly, messages are exchanged between
objects upon 'grabing' and each object 'grabber' and 'grabee', 'owner'
and 'stealer' (parents if in scenegraph/container if not) may 'discuss'
locally (in the instances where user interaction is taking place), and
result is shared globally.
Note that I don't have a message 'takeKey' , but simply a Take, with
parameters' messageFrom, messageTo, typeBoolean'. This is a lot different.
Le 07/01/2014 15:15, Christoph Valentin a écrit :
>>> Each object in the simulation is managing it's synchronisation with other instances of itself. Only user interaction need to be shared on the global layer (local -> global).
> [Christoph:] it's similar in Simple Multiuser Scenes, however, each object defines one instance that is "responsible" for the shared state (but the shared state is stored in each instance and on the collaboration server persistently). If the instance "responsible" for the state gets lost, another instance takes over the responsibility.
> [Eric] Looks like my Token system. Now, what will be triggering a state change ?, most of the time, it's user interaction; If not, it may be a timed event (or functionally time bound) thet doesn't have to be shared, for it can be produced locally. In your scheme, this means: getting event from interaction, conveying it to the application where the 'responsible instance' lies, then propagates to all: distributed server approach, unless all 'responsible are living on the same application. In the latter case, the application load balancing may inply lag on the server app. Why do you need a 'responsible' ? or, put it all the way round, why wouldn't any instance be responsible of propagating user interaction ?
> [Christoph:] As an example, I have got a "key container" object (an X3D prototype), which provides e.g. input field "takeKey" (SFString) and output field "containedKeys" (MFString). "takeKey" may happen in any scene instance, but access to "containedKeys" must be coordinated "centrally" (in the "responsible" instance), such that only one avatar gets the key, key must be deleted from the shared state immediately, when "takeKey" arrives at the "responsible" instance.
> The "key container" prototype wraps a networks sensor, which is used for all requests and for distribution of the shared state.
> X3D-Public mailing list
> X3D-Public at web3d.org
More information about the X3D-Public