I accidentally replied just to Gal, but here's the plan for doors.
Gal's replied to me that this satisfies his application requirements,
though of course we all need it yesterday. :-)
---------- Forwarded message ----------
Hey,
I'd say to hold off on the door hack for now. Gal's right that the
additional field would provide the features he mentions, but there's a
larger plan for doors which will make that change obsolete.
The plan:
Doors are to be portals which you walk through to teleport to a new
space. This means that a door's template needs to define proximity
sensors (which we don't have yet) and a script that tells the client
to teleport to a new space. The client should show a graphic
(perhaps animated) while it shuts down the connection to the old space
and opens the connection to the new space.
Doors should also be two sided, by default, so that people don't go
through a door and turn around only to see no door. So both spaces
need doors which link to each other, and the links should specify the
destination door, so the link URI should be of the form
http://example.com/og/space/23/door/3
In the rare case that we actually want one sided doors, they should
use a link URI of the form http://example.com/og/space/23/44,33,22.1
to teleport to space 23 at coordinates x = 44, y = 33, z = 22.1.
Finally, doors to different spaces need to look different (aka
"facades"), which are templates which are defined by the remote door
record. For example, if there's a door to a desert island it can look
like it's made of palm fronds and drift wood. This is why doors have
a template ID field, though it isn't that useful at the moment since
it always defaults to template ID 2.
I'd like to avoid making door templates different from thing templates
if at all possible, and I'm not yet convinced that just naming a
template "Big Wooden Door" isn't enough to differentiate it from thing
templates.
Gal, does your application require that door templates be separated in
the UI from thing templates?
-Trevor
|
