Zugg Software :: View topic

Newbie Joined: 30 Nov 2007 Posts: 9

One can use the %roomexit() function to get the string list of exits from the current room. One can also use %doorname(direction) to return the name of the door in the given direction.. although none of my doors have names.

Is there a function to check that an exit is a door? Something to the effect of %isdoor(vNum,direction)? When looking at the spreadsheet view of my map, I can see that the field name of the information I need is "ExitKindID". How can I get at this information via script? Possibly mapquery() but I can't seem to find a solution.

Edit: Maybe it is possible to directly access the mapper database tables using the database functions? I can't figure out how to load it.

Any help out there?

Beginner Joined: 06 Mar 2008 Posts: 27

EDIT:opps

misread your post

EDIT:

dont know if this will help you

Newbie Joined: 30 Nov 2007 Posts: 9

I had previously added door parsing to my room exit triggers, and have been using an onroomcreate alias and #DOOR to create doors as I explore. What I’m trying to do is to update the doors on my map automatically as I reload a room’s information via the button on the mapper.

This is a very clever idea to solve my problem. Get the path from the current room to a room 1 step away, and then expand the first step of the path which should be an open door command… even when the door has no name.

Of course there is no #un-door command that corresponds to #door, so I'll have to resort to saving the link’s information, deleting it, and recreating it doorless when a door needs to be removed.

Thanks a bunch! I'll let you know how it goes.

Newbie Joined: 30 Nov 2007 Posts: 9

Been a while, but getting back to this problem now... which leads me to my next hurdle. How do I find the room key of all adjacent rooms?

Take a room with the following exits as an example:

Posted: Thu May 01, 2008 3:21 pm

That's very interesting; I was under the impression that %roomexit returned proper directions. You could perhaps try fooling it by passing the character through one of the path functions first so that it's converted from the path character to the real direction.

Newbie Joined: 30 Nov 2007 Posts: 9

I've had similar thoughts. However, they annoyingly echo text to the screen… and also spit back the speedwalk characters and not the directions.

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

#DIRECTION is only for creating speedwalk letters. It's like how you can't use #KEY to simulate a keypress, as it's only for creating macros.

Newbie Joined: 30 Nov 2007 Posts: 9

This is overly complex for what I am attempting to do. Really what I need is direct access to the exits table in the mapper database. I think I'm just going to cross my fingers, and wait for a more advanced cmud mapper module that will allow me to query it for things like FromID, ToID & ExitKindID.. or at least have a more complete set of exit, door & room functions. Things like #undoor and %isdoor() would really make my zmud to cmud upgrade much more probable.

Posted: Thu May 01, 2008 9:45 pm

you could likely do:

#MOVE j

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

Newbie Joined: 30 Nov 2007 Posts: 9

Wow, thanks Arminas! That's exactly what I was looking for!

After playing around for a little bit, I also figured out that by adding directions for each of my custom exits %exec() would expand them correctly too.

For example, take the "in" exit, or a swim exit:

Posted: Fri May 02, 2008 2:26 pm

Were it me, I'd've called my in and out exits i and o, for ease of readability's sake.

As for swim exits, if your MUD allows rooms to be turned into water (and to be made passable on foot - one mud I played had a levitation spell that, if you had it on, let you walk across water) then hard-coding exits as swim exits is a bad idea. If it were me, I'd have a trigger "You need to swim in that direction" or whatver that'd do swim %lastcom or something, and then add "swim x" to each direction's list of possible commands.

Newbie Joined: 30 Nov 2007 Posts: 9

I had originally used i and o for my in and out exits, but was encountering problems (with the code from this post even) so switched to something obscure which seemed to have solved it. As for hard coding swims into exits, I agree with you 100%. I only use it as an example. The point I was attempting to express is that you can match any "other" exit text to a #DIR so that it can be expanded properly by the %exec().

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

Be warned that if you start putting aliases or commands in your other exits the %exec can make them do strange things. So always test things before you put them into production.

I actually created a more complex system for CMUD using the new user defined functions.
For most things so long as you don't get outlandish, like me, and you test things; the %exec function is good enough.