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

[Christoph Valentin]

> 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.
> 
> Eric.
> 

[Christoph:] In my experimental implementation, I define "MIDAS Objects" (Multiuser Interactivity Driven Animation and Simulation, which is just a funny name :-) ).
I define 3 X3D Prototypes (could become X3D nodes eventually)
1) MIDAS Base for "no state" objects
2) MIDAS Base for "standard" objects
3) MIDAS Base for "animated" objects

1) does not calculate a shared state
2) changes the shared state every now and then (e.g. key container, switch)
3) calculates a state function state(t) (quasi-continuous, e.g. velocity of a train)

A MIDAS Object is created by "deriving" from MIDAS Base.

However, X3D Prototypes do not support inheritance, so I have to emulate inheritance by containment.

It's NOT my goal to provide all MIDAS Objects myself. I'd rather like users programming their own MIDAS objects ("deriving" from MIDAS base).