[X3D-Public] interest in network sensor / client based server software

Eric Maranne 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 
easy outcome.

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
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org

More information about the X3D-Public mailing list