Zugg Software :: View topic - Need help with Automapper

Beginner Joined: 25 Oct 2012 Posts: 11

Hi guys!

I am loving the automapper in this. I've been a mudmaster user for years and years but CMUD is really a step up... the scripting alone is crazy, but the mapper is incredible. It just needs some tweaking!

And that's why I'm here- I can't seem to get the #TAG or #NOMAP stuff to work to really hone the configuration to match my mud. Can anyone help?

My primary concern is ignoring any "extra" lines.. things like mobs, blood on the ground, objects, corpses, people, etc.

The format looks like this:

Beginner Joined: 09 Oct 2012 Posts: 18

I use the debug window and a combination of #TRIGGERs (with the ANSI “color” option enabled), variables, and use of the %stripansi function.

The debug window shows the ANSI codes for the input. I then use this with the #TRIGGERS using %e. I haven’t tried using the %ansi function in the trigger instead of %e, but am guessing that should work too.

E.g. a trigger with ^%e[1~;36m(*)%e[0m$ will return %1 when a line appears with bright-cyan at the start. Then use #TAG name %stripansi(%1) within the trigger.

For the room description, I use a variable. Your trigger would be for anything beginning with magenta, then #VARIABLE RoomDesc {%stripansi(@RoomDesc ) %1}. Your Prompt trigger would then #TAG desc @RoomDesc

The only problem I foresee is with the player colours - you'll need something to differentiate a line of room-description from a player-name appearing in magenta.

Beginner Joined: 25 Oct 2012 Posts: 11

The player names don't start with Magenta- they just might have magenta in them in the title. They start with either a (hero prefix) or just with the name, which is Cyan. The title after the name is green or may be customized with other colors. Seems like that would make it fairly easy right? because the triggers should only work for a line that is 100% magenta (or would they?).

Do your triggers accidentally fire when you get random "other" text from the mud? Like if you are triggering on a bright cyan for the room name and are auto-mapping, and then some weather or god echo occurs that is also bright cyan, will the automapper freak out or will it know that it was not a room simply on the fact that there was no description and exits listing?

Beginner Joined: 09 Oct 2012 Posts: 18

The trigger would would only fire when the line begins with magenta (as depicted by the ^ character) and ends with ANSI-normal (as depicted by the $ character). You should verify with the debugger if this is what the MUD is actually sending... the debugger can also show the trigger firing.

I don't often get triggers accidentally firing because I define them quite tightly ... so I tend to get them not firing when I'm expecting. Moving around in rooms without a description (e.g. when in a maze I've previously mapped) seems to be the current sticking-point. I also occasionally have to define a new #NODIR trigger (to stop the mapper from creating a door whenever I walk into a wall).

Beginner Joined: 25 Oct 2012 Posts: 11

That's another thing I was having a terrible time trying to figure out. :)

When I hit a door, I get a "The xyz appears to be closed." where xyz could be anything. Door, gate, portcullis, portal, etc. I'm very interested in having the mapper automatically know that there is a door in that direction when I make the attempt to go that way, and further, to remember the custom name. I haven't even sorted out how to do it manually. I saw that there is such a thing as label, custom door name, etc, but it doesn't quite fit in my head yet and I haven't had success with it.

Beginner Joined: 25 Oct 2012 Posts: 11

Well... I give up... :(

Spent about 8 hours trying to get various things to work. Matching cyan lines would get odd things into rooms sometimes (mob emotes/says, etc) even if I had higher priority triggers that were #NOMAP.

Then at some point it totally stopped mapping; it wouldn't move or create new rooms at all. I was so exasperated in not being able to get it going again that I deleted the whole folder and started over from scratch- new session, db, etc, with stock map settings (which worked-ish the first time). Same issue... really disappointed as I could sense the potential this thing has.

I even have an imm character that gets VNUMs in the exits and an extra line with vnum/etc above the room name, and when it was working, the mapper refused to set the vnum of the room in the mud to the vnum within its map; whether I used #TAG or #CALL roomnum or #CALL roomvnum.

Kind of discouraging. Anyway thanks for your help, I really wanted to get this working and get a copy of the app but I will have to stick with MM and graph paper...

Posted: Fri Oct 26, 2012 3:42 pm

Dont give up.
Text color is usually the last thing you need to trigger off of.
I understand that mobs and such appearing as part of theroom are a kind of clutter, but it should not stop the map from being effective.

If the game has a who command you could use that to collect a database of all the player names, then use something like..

#TR {^{~(Hero~)|}{@players}} {#NOMAP}

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

Look into multistate triggers. Single-state triggers are functionallyisolated from each other, causing stuf like misfires. .ultistate triggers generally don't have this problem, given all the possible options.

Beginner Joined: 09 Oct 2012 Posts: 18

Beginner Joined: 09 Oct 2012 Posts: 18

Beginner Joined: 25 Oct 2012 Posts: 11

1-

The lines that interfere are Magenta/Cyan- so the same trigger that captures a room name or description also captures the emote or shout or whatever. The only way I can think to distinguish is by checking the previous or next line's color. The ^ and $ didn't seem like they would help in this situation.

2-

Yep, was in learn mode. Tried almost everything I could think of.

3-

This is the major issue I think- no promise of support or fixes, new releases, etc means buying the software isn't a wise decision. :(

Doors-

I had that exact trigger set up for doors- cmud still didn't like it for some reason and would freak out, make new rooms, try opening doors in the wrong directions, etc.

Vnums-

This one costed me several hours of trial and error with no success. I still haven't had any luck- CMUD wants to use it's own room index # to identify rooms instead of any number that the mud sends to it regardless of my using commands that, based on the documentation that I've seen, should force it to use that data.

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

Beginner Joined: 25 Oct 2012 Posts: 11

Thanks so much for the help Matt. I hope you have some more patience- unfortunately it doesn't look like pasting this into the command line does what I imagine it is supposed to do... what are your thoughts?

From what I can tell the commands don't go in the way you intended. Some of the characters don't make it... they turn into left arrows. The prompt trigger also gets nested into two classes (\prompt\nocr\ ?). I'm not sure if that is what is supposed to happen given my lack of experience with zmud/cmud. And is there supposed to be a leading ^ instead of $ for the Obvious Exits?

At first I get a

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

I was merely attempting to create the triggers in a specific class, but it looks like I made a mistake. You can just move it and get rid of the classes.

As for the left arrow things, you need to change those back to %e. The arrow is the parsed result.

Beginner Joined: 25 Oct 2012 Posts: 11

I see, thanks for clarifying.

Looks like I finally got my own version of these things running ok. It's crude but it works... I just trigger on ANSI color and have a higher priority trigger for any other channel communication/text that will "look like" a room name - the higher priority triggers deactivate the room triggers, and my prompt reactivates them.

I also got the VNUMs working, finally, but I see that the mapper only updates the VNUM field and not CMUD's internal numbering/id. I'll take what I can get!

It's more or less working as intended except one hiccup I can't figure out. If I go South and enter Room A with S/N/E exits for the first time, it creates the room on the map. If I go South again from Room A into Room B which has a closed West exit, I get some odd behavior. I have a trigger for

Wizard Joined: 22 Mar 2007 Posts: 2320

I think the problem with the door being created in the previous room is because Cmud won't actually move you into the new room until it processes the prompt.
So #DOOR is being executed before you get moved. One solution would be to have the trigger create a stringlist variable saying which exits need a door added.
Then create an ONENTER event which checks that variable, creates the doors, and clears the variable.

Beginner Joined: 25 Oct 2012 Posts: 11

What I tried (in light of your suggestion) was to set a boolean variable every time I saw a closed door. There is one variable per direction (for instance, exitUp, exitDown).

Whenever I see a prompt, I check the variables and if any of the direction variables are true, I run the #DOOR command. Still hasn't fixed the issue.. I get phantom doors either way. In fact if I take out this functionality altogether I still get the phantom doors. It's also apparently related to whether a room already has a door; moving into that room and then out of it sometimes creates a fake door somewhere. It's a little hard to reproduce.

Beginner Joined: 25 Oct 2012 Posts: 11

I changed my approach- I guess the prompt trigger didn't address the problem. I bound KEY0 to #RAISEEVENT an event that did the same checks and #DOOR commands and whenever I see a door, I hit it. Creates it like magic! Then I set vars to false whenever I hit KEY0 or see "Obvious Exits". Nice!

Now if I can just figure out why it stopped gathering mud vnums. :)

Beginner Joined: 25 Oct 2012 Posts: 11

Got that one too... yay. :) Thanks for the advice.