-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Karsten Otto wrote:
> The point here is that the action *must not* be a simple string. While
> an English speaking human may understand the string "open", someone who
> only speaks Chinese will not understand it. Same with your average
> agent, who does not speak *any* language at all :-)
>
> Thus, actions should be unique terms, like the URIs used in RDF, or at
> least using namespaces ("controlled vocabulary") as usual in VOS.
The action vobject's canonical URL and/or contextual name can serve as
its ID.
It could be a new "action" vobject type, with it's title and description
provided by the misc:description and and misc:title properties (it would
also have the metadata vobject type then).
See my other email for discussion about translated text...
>
>>
>> A second phase would be left To Be Determined and let you combine
>> objects. There are lots of ways to do this if you use either the
>> avatar or a new "browser" object as a container to hold references to
>> the various objects involved in a more complex interaction, or if you
>> create a sufficiently clever way of mapping out the interaction ahead of
>> time in the "clickable" metaobjects.
>>
> Well, ok, my suggestion only provided for one object, but if you really
> need more than that, you can specify them all in the "clicked" message.
> After all, VOS allows ordered lists of properties there.
>
> I am not sure how the "browser" vobject is involved in this. IMHO the
> clicked message should contain all necessary information, and not
> require the clicked object to refer back to the browser of the
> initiator for that. I fact, the initiator may not even *have* a browser
> vobject; I expect this to be the case for most VOS-internal
> interaction, or for agents.
>
> My suggestion was merely that the browser may help in *composing* a
> clicked message. I was thinking about the average graphical adventure
> game interface (LucasArts, Sierra, ...).
> They usually allow you to select an action keyword or icon, and maybe
> some inventory item to use in the interaction ("open door with key").
>
Well, I was trying to make the first phases be simpler, then once we
know needs, devise something complex. You probably have more experience
with creating complex actions like this between agents though.
browser really means "user agent" where the user could be human or not I
guess. Or you could use the avatar object, not the browser. What I
meant was, you can use Vobject linking to connect the different objects
you are using together, before performing the action. Then you can
devise any kind of relationships between objects. So not just <VERB>
the <OBJECT> with the <SUBJECT>.
But that's just a second idea I had, not sure yet if it's good or not.
> The problem here seems to be our differing(?) understanding of the term
> "portal".
Here's the terminology we have used thus far in VOS: Sectors are really
seperate spaces. The user is in one sector at a time, usually. The
user views one sector at a time. If an object is a child of a sector,
that object is rendered according to its properties. (An object can be
a child of more than one sector of course.) A portal is a polygon
floating in space onto which a view of another sector is rendered; it's
very very much like a window in a house. This polygon can be any size
and any shape. You can position portals to create the illusion that
two sectors are joined with each other at some plane in viewing space
(but it will still eventually have edges, it could just be huge). If you
pass through a portal, then your avatar is added to the new one and
removed from the old one. And you are now viewing the new sector. If
there is no portal on the other side back to the old sector, you no
longer see any objects contained in it. Sectors and portals themselves
are invisible and have no visible stuff attached to them.
>
> Basically yes, I want to see all the objects from all the sectors at
> once. For this to work, you need spation relations between the zones
> (=sectors), otherwise they would all wind up on top of each other. So a
> zone needs to specify a "link" to another zone, saying something like
> "from my point of view, this other zone's origin lies at (100,0,-50)".
I see.
If you want sectors to share objects, they can just share objects. If
you want to use several servers to host different objects within a
sector, you just do that, but one server has the actual sector object.
Trying to stick sectors together like that would just make things kind
of complicated, for the client and for scripts, don't you think?
>
> Now, I consider a "portal" to be a special kind of link, which in
> addition to position and target zone also contains some geometry,
> usually a polygon, restricting visibility of the target zone. Thus, you
> cannot always see the zone, only when you look at the front side of the
> polygon it acts as a hole or window into the other zone. You can do
> nifty stuff with that, like modeling three magic doors on a beach that
> lead into other worlds (S.King, "The Drawing of the Three").
Yes this is exactly what a portal would do.
Any *visible* geometry would be seperate object(s) from the portal. If
you wanted to have a door like a house door, you would have a portal
object, and then you would also have object(s) for the door frame, the
actual door which can open on its hinge, doorknob, knocker, etc.
Reed
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFETsOhFK83gN8ItOQRAqPwAJ4pkiN3bbKE25wXus0LYPG4/0sgjQCgh+3F
P+DB0YNfxCnfAKdp4oO/RVc=
=Xgw4
-----END PGP SIGNATURE-----
_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
