Zugg Software :: View topic

Newbie Joined: 20 Jun 2007 Posts: 4

Okay, here's the problem. For some reason, the auto-configuration doesn't like to recognize the room names on my MUD.

The problem is, the description can be 2 or 3 paragraphs, or 1 or none, and it can change depending on weather, time of day, etc.

The one thing that is constant, is that the room name is always on it's own line, and is always the first line received. Is there anyway to #tag the first line received when I create a new room?

Edit: Also, is there a way to keep the automapper from even capturing/using the descriptions? I don't particularly need or want it, just the room name and exits.

Posted: Wed Jun 20, 2007 9:38 am

The mapper only needs the room name and room exits, and perhaps your prompt depending on your MUD. If the description isn't tagged (or you choose not to detect it during autodetection) then the mapper won't use it. Without seeing some sample text, we can't help you create a trigger though I'm afraid :(

Posted: Wed Jun 20, 2007 4:31 pm

The other option is to change your automatic step configuration settings. (Assuming it's just a problem with following you and not the initial room capture.)

On the mapper window go to Config -> Configuration Settings. Click on Speedwalking. Change Automatic Step confirmation to 'Match Room Name'.

Newbie Joined: 20 Jun 2007 Posts: 4

Unfortunately not, the problem is that the automatic configuration for the mapper fails to recognize the room name when creating the room in the first place. Well, it does sometimes, when the room description is one paragraph long. Unfortunately, the same room could have a 2 paragraph description 10 minutes later, they change depending on time, weather, etc.

Here is an example:

>s
A decrepid cemetary

This large field is completely fenced in for the sole purpose of keeping
grave-robbers out (or something else, in).

A wind gusts leisurely from the southeast, and the moon casts an eerie
white glow on your surroundings.

Obvious exits are: south, west, and north.

>

Of course, the same room 10 minutes later, could look like:

>n
A decrepid cemetary

This large field is completely fenced in for the sole purpose of keeping
grave-robbers out (or something else, in).

Dark clouds fill the sky and make your surroundings hazy. It is raining
hard.

Obvious exits are: south, west, and north.

>

Or, it could be missing the weather description altogether, and have only a 1 paragraph description, like so:

>s
A decrepid cemetary

This large field is completely fenced in for the sole purpose of keeping
grave-robbers out (or something else, in).

Obvious exits are: south, west, and north.

>

Sometimes I end up with a room called "grave-robbers out" or "gusts leisurely". If it doesn't capture the actual room name, it seems to just pick something randomly from the description.

As you can see, the room name is always the first line following the move command, and is always on it's own line. Is there a way to set up the "onroomcreate" alias to tag the first line received, or is it just wishful thinking? The reason I'm having such a hard time is the automapper's insistance on starting at "0" from the last paragraph received, so I have no idea which paragraph number will relate to the room name.

Also, can I configure the mapper to simply forget about the description altogether?

Posted: Wed Jun 20, 2007 9:15 pm

How about an oninput trigger? You trigger on any of your movement commands - the oninput trigger has a second state which then matches any line. You can then use the #if command to check that the match isn't "You can't move that way!" or whatever, and if it isn't, to #tag it as the room name.

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

Is there any use of punctuation as part of the room name? Are there any other lines in the game which follow the same rules as the room name? Assuming no to both questions, set up these two triggers:

#trigger {^[%w%s]$} {#tag name;vRoomDesc = "";#T+ tRoomDesc}
#condition {Obvious exits: (*).} {#tag desc @vRoomDesc;#tag exit "%1";#T- tRoomDesc}

#trigger "tRoomDesc" {(*)} {vRoomDesc = %concat(@vRoomDesc,"%1")}

The second trigger might need an adjustment to the %concat() function to make it flow properly, depending on how your mud wraps lines (speaking of which, it if lets you control line wrapping use whatever value equates to turning it off on your mud; this will revert each paragraph to one line that is much easier for ZMud to capture and deal with).

I recommend that you first try these triggers with visible output to determine if and how properly they are working (#COLOR works very nicely for this). Once you are reasonably sure they are working correctly, remove that visible output stuff if you want and run the autoconfiguration utility to force the mapper to recognize these triggers. If all goes well (you didn't show what it looked like when PCs and NPCs were in the room), the mapper should be working correctly for you now.

Posted: Wed Jun 20, 2007 9:37 pm

I'm not sure how well those triggers are going to work given the weather problems he mentioned above, Matt. You have two options really, have the tRoomDesc trigger turn itself off when it first encounters a blank line, or avoid capturing the room description at all. I'd go for the latter, personally.

Newbie Joined: 20 Jun 2007 Posts: 4

Unfortunately I can't test those now, but I will as soon as I can. My only concern is, wouldn't this trigger:

#trigger {^[%w%s]$} {#tag name;vRoomDesc = "";#T+ tRoomDesc}

match everything? I didn't see anywhere that it was turned off. Wouldn't it match the room name, and then all the lines following it as well?

I do agree with Fang, that I'd prefer to avoid capturing the description at all. It seems to be just causing more headaches than not.

To answer your questions, Matt:

There is usually not punctuation in the room names, but occasionally there is. I can always override those few rooms manually, though.
The room names are coloured, unfortunately that colour changes. (Cyan for shops, brown for dirt paths, etc)
I can't control line wrapping, it seems to be hard-coded by the MUD.
I don't know what you mean by "same rules", but there is normally no punctuation in the mob descriptions.
Oh, and I forgot to mention, the names all follow "proper case". All main words are capitalized.
Here is another example of a different room:

>e

A Decrepid Cemetary

Some long boring description paragraph goes here and here and here
and here and here. Blah blah blah blah blah blah blah blah blah blah.

Another description paragraph.

The wind is blowing from the north, and the entire area is illuminated
by the midday sun.

A creaking skeleton stands here
A zombie has been unearthed and searches for a victim

Obvious exits are: east, west, and north.

>

I hope this clears it up a little. Thanks for your help so far.

Posted: Wed Jun 20, 2007 10:11 pm

It won't match every line because it's a mutli-state trigger. The first state is deactivated while the second state (the Obvious Exits one) is waiting for its match. Unfortunately, with the way that trigger's set up you're probably going to get a lot of false positives though.

That colour thing is a bit of a bugger. Colour's normally the easiest way to handle this.

I still reckon that an oninput trigger would be the easiest way to handle this. Perhaps something like this?

#trig {^{north|south|east|west|enter portal}$} {} "" {input}
#cond {^(*)$} {#tag name} {within|param=1}

Newbie Joined: 20 Jun 2007 Posts: 4

Okay, that I managed to test with #color, and it seems to work properly. This is what I used:

#trig {^(%t)$} {} "" {input}
#cond {^(*)$} {#color bold,yellow} {within|param=1}

Same as yours, except switched #tag for #color, and the list of directions with %t.

The only problem is, that it is matching the ">s" command I send to move, rather than the next line received. Is that the part matched by "param=1"? Could I solve that by making it a 2, instead?

Edit: Nevermind, I got it by substituting "skip" for "within". Thanks for your help!

Posted: Wed Jun 20, 2007 10:31 pm

No, within limits the second trigger state to only being active for one line. It sounds like you need to get the trigger to ignore lines starting in > - you'll also need to increase the within amount to 2. A pattern like ^[^>]*$ should work.

Also, the problem with %t is that you need to include every command that might set off a room description. That includes things that aren't traditional directions and the look command and might not be covered by %t.

And finally, I forgot to add the all-important #if command to the trigger condition as well. Before #tagging with name you need to make sure that the movement actually succeeded. Your final trigger will probably look like this:

#trig {^(%t)$} {} "" {input}
#cond {^[^>]*$} {#if (%line != "You can't move that way!" and %line != "That door is locked!") {#tag name}} {within|param=2}