Detecting exit linked-to object?

[Ben Trafford]

So, let's say I've got a room with a DBREF of #100. It's got an exit
called Out, that has a DBREF of #101. In another room, with a DBREF of
#99, there is an exit called In, that has a DBREF of #102.

What I want to know is if there is a function to detect what exit an
exit is linked to. Can I figure out that Out is linked to In, in other
words?

I know loc() can tell me what -room- an exit is linked to, but I want to
know the reciprocal exit.

I suspect the structure is such that the two exits have nothing in
common, simply being links to room with no actual connection beyond the
semantic.

What I'm -trying- to do is put @dig roomname=exit1,exit2 into a command
write exit1 and exit2 into setq(). I just can't seem to get one of the
exits into setq(), because there's no obvious way to reference it -- in
the other two cases, I'm using lastcreate() (which gets me the exit) and
where([lastcreate()]), which gets me the room that @dig creates.

--->Ben

[S. Holland]

You're correct, 'reciprocal exits' are illusory. You have two rooms, and two exits. Each exit goes to the other room, but the exits themselves don't actually know anything about each other. All an exit 'knows' is where it's located (the origin) and where it's linked to (the destination). If you've got something that's working for you, that's probably the best you're going to get. I could be (and frequently am) wrong however, so if a guru wants to weigh in and prove me thus I'm all ears. :D

2009/12/24 Ben Trafford <b...@prodigal.ca>

[Ben Trafford]

Unfortunately, I -don't- have anything that's working for me. I can't
figure out a way to locate the first parameter of the @dig that doesn't
involve using some weird permutation of search().

There's got to be an easier way to do this that I'm missing. :(

--->Ben

[Rachel Blackman]

Off the top of my head, just written in the mail client here...

&FILTER-RETURNS-HERE <object>=strmatch(loc(%0),%q0)
&U-EXIT-TWIN <object>=[setq(0,home(%0))][first(filter(me/filter-returns-here,lexits(loc(%0))))]

u(<object>/u-exit-twin,<exit dbref>) <-- this'll then return the first matching/returning exit (or an empty result if there is no exit).

[William Young]

Myself, I set up something similar in a really "clunky" way, when I got sick and tired of having to hunt down the other side of an exit when moving exits around...

&OLDSOURCE %0=where(%0) ;&OLDDEST %0=loc(%0) ;@dolist lexits(u(%0/OLDDEST)) =@switch loc(##)= %l, &OTHERSIDE %0=##

...that's mid-command, first setting the old source-room and the old destination-room for the target exit (IE: %0), then working out what the "other side" of the target exit is. Obviously, one could redo the various @commands as functions(). 

T'Then...
William D. Young

Real Mail 42 Winter St, Bangor ME, 04401
E-Mail youngw...@hotmail.com

> Subject: Re: [TinyMUX] Detecting exit linked-to object?
> From: cerulea...@gmail.com
> Date: Thu, 24 Dec 2009 10:21:36 -0800
> To: tin...@googlegroups.com

[Jerry Van Suchtelen]

Basically it is thus. Exits only serve as a way to go from one room
to another and know nothing of what comes back into the room. Exit ->
Room, the end.

Its not a two way pipeline where Room <--- Exit ---> Room. Perhase if
a 'what links here' was created so that one can run a simple command,
it might solve your issue.

[Ben Trafford]

Hey, everybody,

I solved it, thanks to the hints given here. I didn't end up using
attributes or strmatch -- the attribute solution seemed inelegant, and
the strmatch concerned me -- it'd match both #125 and #1250 if I tried
to match for #125.

This is what I did, instead:

[iter([lexits([loc([r(1]])])],[if([eq(1,[comp(##,[num([r(0)])])])],[setq(3,##)])])]

...where r(1) is the exit I know about from lastcreate() and r(0) is
equal to [where([lastcreate()])], and thus, the parent room. All of
which is set by preceding code.

Thanks for all your help!

--->Ben

[Sandi Fallon]

Ben Trafford wrote:
>
> What I'm -trying- to do is put @dig roomname=exit1,exit2 into a command
> write exit1 and exit2 into setq(). I just can't seem to get one of the
> exits into setq(), because there's no obvious way to reference it -- in
> the other two cases, I'm using lastcreate() (which gets me the exit) and
> where([lastcreate()]), which gets me the room that @dig creates.
>

Sounds like instead of using @dig, you need to write a +dig that will do
what you want.

I identify paired exits with an &BACK attribute.

Sandi

[Ben Trafford]

That was basically the idea, yeah. It's working now. :)

Thanks!

--->Ben

[Stephen Brewer]

It's worth pointing out that strmatch() will not glob if you do not tell it to.

think strmatch(#1234,#123)
0

think strmatch(#1234,#123?)
1

think strmatch(#1234,#12*)
1

--Stephen/Soylent

[Ben Trafford]

Huh. That's odd behavior for a string-matching tool.

--->Ben

[Stephen Brewer]

Not really, it just makes fuzzy matching optional. strmatch(string,string) still returns 1.