Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD General Discussion
vwombat
Beginner


Joined: 25 Oct 2012
Posts: 11

PostPosted: Thu Oct 25, 2012 10:35 am   

Need help with Automapper - classifying/ignoring text by ansi color
 
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:
Code:

A Room Name                                                                    <-- In Cyan
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod       <-- Room Desc, in Magenta
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam,   <-- in Magenta
 quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo       <-- in Magenta
consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse      <-- in Magenta
cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat      <-- in Magenta
non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.   <-- in Magenta
A few drops of blood are on the ground                                         <-- in Red
Someone left a huge pair of underwear on the ground.                           <-- items, in Gray
Bob the mob is here.                                                           <-- mobs, in Green
Joe the Schmoe is here                                                         <---- Players, variable color
Obvious Exists:                                                                <---- in Blue
North - A Tempting Dancefloor                                                  <--- Exits, in blue
South - Vortex of Chaos                                                        <--- Exits, in blue ("South" text is in yellow)



I need to just ignore anything that isn't Room name, Description, or exits... I'm sure some of you have figured this out but I'm really confused because I'm out of my element in the application, the scripting language, and the mapping logic. Can someone help me solve this?
Reply with quote
Amorelia
Beginner


Joined: 09 Oct 2012
Posts: 18

PostPosted: Thu Oct 25, 2012 5:05 pm   
 
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.
Reply with quote
vwombat
Beginner


Joined: 25 Oct 2012
Posts: 11

PostPosted: Thu Oct 25, 2012 7:40 pm   
 
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?
Reply with quote
Amorelia
Beginner


Joined: 09 Oct 2012
Posts: 18

PostPosted: Thu Oct 25, 2012 8:18 pm   
 
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).
Reply with quote
vwombat
Beginner


Joined: 25 Oct 2012
Posts: 11

PostPosted: Thu Oct 25, 2012 9:49 pm   
 
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.
Reply with quote
vwombat
Beginner


Joined: 25 Oct 2012
Posts: 11

PostPosted: Fri Oct 26, 2012 10:06 am   
 
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...
Reply with quote
shalimar
GURU


Joined: 04 Aug 2002
Posts: 4662
Location: Pensacola, FL, USA

PostPosted: 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}
_________________
Discord: Shalimarwildcat
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Fri Oct 26, 2012 4:49 pm   
 
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.
_________________
EDIT: I didn't like my old signature
Reply with quote
Amorelia
Beginner


Joined: 09 Oct 2012
Posts: 18

PostPosted: Fri Oct 26, 2012 7:43 pm   
 
vwombat wrote:
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.


#TRIGGER {^The (*) appears to be closed.$} {#DOOR %lastdir() %1;#NODIR}
Reply with quote
Amorelia
Beginner


Joined: 09 Oct 2012
Posts: 18

PostPosted: Fri Oct 26, 2012 7:52 pm   
 
vwombat wrote:
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.


Use of the ^ and $ might help.

Quote:

Then at some point it totally stopped mapping; it wouldn't move or create new rooms at all.


Do you have the Automapper switched on in "learn" mode?

Quote:

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...


It can get discouraging. I think the lack of examples / tutorials on setting up the Automapper is a problem.... and having the developer dropping the project even for bug-fixing is disturbing. But once you get past the issue and understand any bugs you have to work around, I've found it generally works pretty well.
Reply with quote
vwombat
Beginner


Joined: 25 Oct 2012
Posts: 11

PostPosted: Wed Oct 31, 2012 6:58 am   
 
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.
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Wed Oct 31, 2012 4:45 pm   
 
Code:
#trigger "tName_Desc" {^%e[1;36m([%w%s])%e[0m$} {
  //initialize room variables
  RoomName = %1
  RoomDesc = ""
  RoomExits = ""
  RoomBlood = ""
  RoomItems = ""
  RoomPlayers = ""
  RoomMobs = ""
  //enable triggers for optional room-stuff: blood, items, mobs, and players
  #T+ RoomOptionals
} {} "Room Info"
#condition {^%e[1;35m([%x%s])%e[0m$} {
  RoomDesc = %additem(%1,@RoomDesc)
} {WithinLines|param=1}
#trigger "tExits" {$Obvious exits:$} {
  //disable optional room info triggers
  #T- RoomOptionals
} {} "Room Info"
#condition {^%e[1;(%d)m({North|South|East|West|Up|Down}) - (*)%e[0m$} {
  #additem RoomExits %2
} {WithinLines|param=1}
#trigger "tPrompt" {your prompt pattern goes here} {
//todo: stuff you want to do with your prompt information
//todo: stuff you need to do for any other scripts that rely on the prompt (optional)
#tag name @RoomName
#tag desc @Roomdesc
#tag exit %if(@RoomExits,@RoomExits,"none")
#tag prompt
} {prompt|nocr} "Room Info"

#trigger "tRoomOptionals" {^%e[1;3(?)m(*)%e[0m$} {
  #switch (%1)
    ("1") {RoomBlood = %additem(%2,@RoomBlood)}
    ("0") {RoomItems = %additem(%2,@RoomItems)}
    ("4") {RoomMobs = %additem(%2,@RoomMobs)}
} {} "Room Info"


1)paste this into the command line. I made the triggers with a class argument, so a new class folder called "Room Info" should appear with the triggers inside. Feel free to move them wherever else you want, and make sure the "tRoomOptionals" trigger is turned off (it will be created in the enabled state, so it'll start capturing stuff it's not supposed to). Be sure to remove any other capture-related triggers you might have had before, as once you start mapping they'll probably interfere.

2)make sure to turn on ANSI trigger for the name and desc trigger (the ansi option was never included in this old-fashioned zscript syntax)

3)I did not handle players because of the high potential for customization on either side of the player name. Is there anything about the player line that is standardized? If so, that will be key for testing for players. It probably would also help if you could turn off one or the other (or both) player-title things, if your game allows you to do so.

4)Take these triggers through a few dry runs, definitely with the mapper not in creation mode. The intent of this step is to make sure the triggers themselves and the variables they populate are working correctly. If they aren't, we don't want such mistakes getting into the mapper as we'd just have to remove them after ironing out all the bugs.

5)Once the triggers are deemed in proper working order, turn the mapper back to creation mode and run the reconfigure wizard. This will activate the #tag triggers so that the mapper will use them. At this point, you should be able to safely map but you should only attempt one room. Check it out to see if this worked properly as well. If so, try a few more and check those. If you are still at zero mistakes (that can't be easily fixed via supporting #NOMAP or #NODIR triggers), then barring the inevitable special exceptions you now have a spot-on map configuration for your mud.
_________________
EDIT: I didn't like my old signature
Reply with quote
vwombat
Beginner


Joined: 25 Oct 2012
Posts: 11

PostPosted: Fri Nov 02, 2012 9:41 am   
 
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
Code:
ERROR: Trigger "^%e[1;36m([%w%s])%e[0m$" fired but did not compile


That happens several times, and then it stops firing altogether (according to the debugger). I don't see any of the others fire except the Obvious Exits after I modify it a bit. Am I doing something extremely wrong? Is there another way to import these? I did follow the directions to a t, including the ANSI trigger settings etc.


Here is what it looks like in the editor when I just copy paste it (I'm on version 3.34):



In the screenshot you can see how those triggers were exported. I also included some example extra stuff in the room if it helps troubleshoot. As you can see I'm also able to see VNUMs (and the exit text is a bit different than I first suggested). The pattern I used for my prompt is:

Code:
~(~#(%d)~) ~[HR~]
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Fri Nov 02, 2012 10:46 am   
 
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.
_________________
EDIT: I didn't like my old signature
Reply with quote
vwombat
Beginner


Joined: 25 Oct 2012
Posts: 11

PostPosted: Fri Nov 02, 2012 11:24 am   
 
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

Code:
West  - [Closed]


which does the following in this case

Code:
#TAG exit West
#DOOR West


However on the map, it creates a new door/exit in Room A to the west, instead of in Room B - where it actually saw this closed door. This behavior is consistent. Is this because tags and/or variables aren't being cleared properly between rooms so that it thinks the locked room belongs to the previous one? These rooms have unique vnums/descriptions/names and unique sets of exits, so I've ruled that out. Would appreciate any advice if someone has run into this or has an idea.


Yikes, too many late nights. :)
Reply with quote
Rahab
Wizard


Joined: 22 Mar 2007
Posts: 2320

PostPosted: Fri Nov 02, 2012 12:38 pm   
 
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.
Reply with quote
vwombat
Beginner


Joined: 25 Oct 2012
Posts: 11

PostPosted: Fri Nov 16, 2012 8:23 am   
 
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.
Reply with quote
vwombat
Beginner


Joined: 25 Oct 2012
Posts: 11

PostPosted: Fri Nov 16, 2012 8:32 am   
 
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. :)
Reply with quote
vwombat
Beginner


Joined: 25 Oct 2012
Posts: 11

PostPosted: Fri Nov 16, 2012 8:35 am   
 
Got that one too... yay. :) Thanks for the advice.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD General Discussion All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net