Room connections

Authoring Dialog
1

is there a way to programmatically remove room connections?

i realize that connections can be present or not based on a query, i.e.
(from $Room go $Dir to $AnotherRoom)
(some condition is true)

but i’m doing something complicated/strange and it would be much easier to implement if i could just zap away a room (or door) connection after it’s been declared.

2 Likes
2

Just use a dynamic predicate?

(way is clear)

(from #room1 go #north to #room2)
    (way is clear)

(prevent [jump])
    (now) ~(way is clear)
    You jump, which causes rocks to fall from the ceiling and block the way!

It might even be possible to use a (now) with a (from $ go $ to $) directly, but it’s better to keep it non-dynamic, since that what others expect.

It you need that with a lot of rooms, you could use a per-object flag. (Although you will need a separate predicate for each direction, I think.)

2 Likes
3

Short answer no. Dynamic predicates can have at most two parameters, from $ go $ to $ rules have three parameters. So we can’t zap them away with (now) keyword.

If you don’t want to use query based exits like you said in your post or like Nathanaël suggested, one other method is to use negated rules with conditions like:

~(from #room1 go #north to #room2)
    ~(way is clear)

You have to use the negated rules before the actual exit rules in the code. I don’t like that approach, it is kinda backwards and hard to read in my opinion.

Edit: Heh, the negated rule approach is no good either, I clearly forgot that in some rules the library does a multi query with (from $ go $ to $) with second and/or third parameters unbound. A negated rule like I suggested above would mess those multi queries. For example the exits commands would start misbehaving.

Hence, use normal exits with check queries, is my only advice.

1 Like
4

that’s what i thought.

just thought i would check first, though, to maybe save myself some spaghetti code.

1 Like