 |
Indral
Newbie
Joined: 27 Feb 2008
Posts: 9
|
 Posted: Wed Feb 27, 2008 10:20 pm
complex automapper question
|
Hello!
I hope some of the experienced fellas is gonna have the time to read this.
Now, suppose I want my Automapper to create new rooms as i tread into unknown areas, and get room name, description and exits. Not too much to ask.
Of course, I expect it to follow me as I travel in already mapped areas as well as precise slow-walking, matching room names.
First of all, the MUD (Discworld MUD) is using MXP, however, no paragraph tags are used, and no room name and description tags are used.
Of the relevant ones, only the ROOM tag is used.
This is a typical output:
| Code: |
[common room of the Paper Dragon Inn]
Low tables, mounds of cushions, lotuses floating in bowls of clear water, hanging paper lanterns, cut glass wine snifters on the bar, blown-glass bottles behind it, all these combine to give this place the look and feel of an Agatean pub with a touch of class. Menus lie scattered around the room on each low table.
There is one obvious exit: southeast.
Loo Ni is sitting at the bar.
A bulletin board [ 80 notes ] is mounted on one wall and a go board is fixed to a table.
> |
Now, I managed to trigger on the room name, quite simple.
For the exits, I used a #MXPTRIG to #TAG the line as containing exits, to be as fool-proof as it can.
The description is always between the name an the exits. In this sample, the description is single-line (probably wrapped when viewed here on this page), but it can also be sent as multiple lines, each containing a distinct piece of description.
The text between the exits and the prompt is useless.
When I simply put #TAG as actions for roomname, description and exits triggers, I realize I have to "re-configure" the mapper. So I do that, and it puts in very weird numbers, such as 99 for starting line, and so on.
My problem here is:
Does the #TAG tag a line without regard to what paragraph and starting line the mapper expects?
Do I have to check the "Room Name", "Room Description" and "Room Exits" checkboxes in Map Preferences to use the #TAG command?
Can I safely use functions for setting these properties, e.g. %roomname(, @mystringlist) ?
I fail to understand the logic of these paragraphs, since it happens on my MUD that perhaps, due to high level of activity in a room, the entire output of the look command arrives in another paragraph (with respect to prompt), and the mapper fails to detect it, since it only looks for the ONE paragraph that you configure.
This doesn't seem to me like a very complex MUD output.
Thank you in advance!!  |
|
|
|
|
Fang Xianfu
GURU
Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom
|
Posted: Wed Feb 27, 2008 11:00 pm
|
1) I believe the paragraph numbers are irrelevant when you're using #tag, yes.
2) Only if you want to use all of them (and have #tag triggers for all of them). The description is very optional - I don't normally bother with it.
3) Yes, but I wouldn't because "safe" depends on your code not doing something wrong. #TAG is safer.
If we saw the actual code you're using and the actual MUD output (including MXP tags) we'd be able to give you better help. |
|
|
|
|
Indral
Newbie
Joined: 27 Feb 2008
Posts: 9
|
Posted: Thu Feb 28, 2008 12:38 pm
|
Here's the actual MUD output of the same room as above, with MXP: (I haven't found a way to log MXP tags other than turning off MXP in zMUD, then logging to a file, so sorry for the lack of formatting)
| Code: |
| [common room of the Paper Dragon Inn]<BR>Low tables, mounds of cushions, lotuses floating in bowls of clear water, hanging paper lanterns, cut glass wine snifters on the bar, blown-glass bottles behind it, all these combine to give this place the look and feel of an Agatean pub with a touch of class. Menus lie scattered around the room on each low table.<BR><Green>There is one obvious exit: <Exit>southeast</Exit>.<BR>Loo Ni is sitting at the bar.<BR>A bulletin board [ 80 notes ] is mounted on one wall and a go board is fixed to a table.<BR>> <!EN hp 498 publish><!EN xp 44402 publish><!EN gp 50 publish><!EN maxhp 498 publish><!EN maxgp 50 publish> |
MXP makes linebreaks with <BR>, does zMUD (of course, with MXP turned on), count these tags as linebreaks?
Ok, now my triggers are:
| Code: |
| #TRIGGER "tRoomName" {^~[(*)~]$} {#TAG name %1} |
Room exits: (either one works, except perhaps the MXP trigger, which fires multiple times if more than one exit is present)
| Code: |
#TRIGGER "tExits" {obvious exit*: (*).} {#TAG exit %1}
#TRIGGER {exit} {#TAG exit #0} {mxp} |
For now, I'll forget about room descriptions.
Now, this doesn't always work. How (if) should I reconfigure the mapper settings?
And another thing, the MUD uses command queuing, so when the mapper sends two consecutive slowwalk commands too quickly, the second one gets queued, with causes the MUD not to send the prompt after the second room look and thus aborting the slowwalk. I solved this thing by setting the mapper not to wait for prompt. Anyway, I'd like to avoid command queuing, and I'd like a trigger to "queued command" pattern to pause the slowwalking for, say, 5 seconds. Is this possible? |
|
|
|
|
JQuilici
Adept
Joined: 21 Sep 2005
Posts: 250
Location: Austin, TX
|
Posted: Thu Feb 28, 2008 3:16 pm
|
Generally, you can use the autoconfigure option (choose Config->Reconfigure from the mapper menubar, and follow the directions), and the mapper will set itself up to use your tags. If the mapper is not following correctly after you do this, please provide additional detail about the failure. E.g. if it 'does not always work', let us know when it does/doesn't and if there are any patterns you can detect.
Setting a delay is easy. Choose Config->Configuration Settings from the mapper menubar. Choose Speedwalking from the tree on the left. There will be an input field for 'Step Delay' visible - put the number of milliseconds delay you want in there, and it will wait that long after each step before sending the next step. |
|
_________________
Come visit Mozart Mud...and tell an imm that Aerith sent you! |
 |
|
|
Indral
Newbie
Joined: 27 Feb 2008
Posts: 9
|
Posted: Thu Feb 28, 2008 3:38 pm
|
| JQuilici wrote: |
| E.g. if it 'does not always work', let us know when it does/doesn't and if there are any patterns you can detect. |
It fails to work in this case, for example:
| Code: |
[shopping area on Long Street]
This is the start of the main shopping district on Long Street. The street is very quiet to the south, but is bustling with activity here and to the north; it's like someone drew an invisible line between this part of the street and the area to the south. There are many shops and stalls about here, and it's hard to move because of the huge crowds. Long Street runs off north and south.
It is a very cold spring prime's afternoon with almost no wind and scattered puffy clouds.
There are two obvious exits: north and south.
A string of lanterns is hanging across the street.
> s
You breathe a sigh of relief as you leave the busy commercial area.
[junction on Long Street]
This is the southern part of Long Street, where an alley runs east to Serpentine Way. Long Street isn't very busy here. But that can easily be excused. After all, it is the biggest and busiest street in the district, so it should be allowed one area where not so many tourist feet tread its weary cobbles. Long Street heads off north and south, while a nameless alley shoots off east.
It is a very cold spring prime's afternoon with almost no wind and scattered puffy clouds.
There are three obvious exits: north, south and east.
A string of lanterns is hanging across the street.
> |
Notice the "You breathe a sigh of relief as you leave the busy commercial area." is a paragraph, as far as zMUD is concerned, and because zMUD expects name and exits on the paragraph set up in map config, obviously it doesn't get the right one. So, the paragraph setting, I think, DOES matter even if I use #TAG.
However, paragraph no. 0 should always be the last one received, and hence the above output should be interpreted correctly no matter how many paragraphs are sent before the room info.
Even more than one paragraph can arrive, and that occurs quite often on Discworld MUD. E.g.
| Code: |
[shopping area on Long Street]
This is the start of the main shopping district on Long Street. The street is very quiet to the south, but is bustling with activity here and to the north; it's like someone drew an invisible line between this part of the street and the area to the south. There are many shops and stalls about here, and it's hard to move because of the huge crowds. Long Street runs off north and south.
It is a very cold spring prime's afternoon with almost no wind and scattered puffy clouds.
There are two obvious exits: north and south.
A string of lanterns is hanging across the street.
> s
A small urchin boy and a stall owner argue over who owns a chicken.
You breathe a sigh of relief as you leave the busy commercial area.
[junction on Long Street]
This is the southern part of Long Street, where an alley runs east to Serpentine Way. Long Street isn't very busy here. But that can easily be excused. After all, it is the biggest and busiest street in the district, so it should be allowed one area where not so many tourist feet tread its weary cobbles. Long Street heads off north and south, while a nameless alley shoots off east.
It is a very cold spring prime's afternoon with almost no wind and scattered puffy clouds.
There are three obvious exits: north, south and east.
A string of lanterns is hanging across the street.
> |
Maybe I am just missing something. Maybe it's not about paragraphs at all.
| JQuilici wrote: |
| Setting a delay is easy. Choose Config->Configuration Settings from the mapper menubar. Choose Speedwalking from the tree on the left. There will be an input field for 'Step Delay' visible - put the number of milliseconds delay you want in there, and it will wait that long after each step before sending the next step. |
I forgot to mention, I tried this, but that's the delay between sending a step, and sending the next step. If the MUD suddenly lags for more than the given delay, the next step will be sent immediately after successful move, causing the MUD to queue the command anyway. What I'm looking for is a delay after a successful step and the sending of the next command. |
|
|
|
|
JQuilici
Adept
Joined: 21 Sep 2005
Posts: 250
Location: Austin, TX
|
Posted: Thu Feb 28, 2008 8:22 pm
|
I'm not sure if the paragraph setting still applies even when #TAG is used, but I've seen behavior similar to yours on Mozart, too (e.g. weather messages getting used as room names). In my experience, this doesn't prevent correct following (in follow mode), but it will sometimes screw up the addition of new rooms in map mode.
To fix the problem, you will probably have to do some scripting using the #NOMAP command. In essence, you figure out a way to 'anti-tag' all of the lines that are not part of the room description. This could be easy (e.g. your mud uses a different color for weather, movement messages, etc, and you can just trigger on colors), or hard (you write a complicated multi-state trigger to detect whether or not you're seeing a room description or something else). I'll have to think on that a bit - it should be possible to write a robust multi-state trigger if you can reliably detect the room name and the exit line: you have a 'normal' state that #NOMAPs all lines, and a 'description state', active only between a room name line and an exit line (inclusive), that doesn't. Alternatively, you can just #NOMAP all lines except the room name and exits - your map won't have any descriptions in it, but many people don't care about that.
Regarding the step delay issue...yeah, that can happen in, say, Safe Walk mode. It shouldn't happen in Slow Walk mode, since zMud should be (a) waiting to confirm each step, then (b) waiting for a prompt, before sending the next direction (see this page for lots of detail). I assume that you have switched from Safe Walk (the default) to Slow Walk...but is the mapper detecting your prompt correctly? |
|
_________________
Come visit Mozart Mud...and tell an imm that Aerith sent you! |
|
|
|
Indral
Newbie
Joined: 27 Feb 2008
Posts: 9
|
Posted: Fri Feb 29, 2008 11:39 am
|
| JQuilici wrote: |
| To fix the problem, you will probably have to do some scripting using the #NOMAP command. |
I will try this, but if it happens that the mapper automatically ignores all the paragraphs except the one set in preferences, then even a #TAG in these paragraphs doesn't help. But, I have to test that thoroughly.
| JQuilici wrote: |
| Regarding the step delay issue...yeah, that can happen in, say, Safe Walk mode. It shouldn't happen in Slow Walk mode, since zMud should be (a) waiting to confirm each step, then (b) waiting for a prompt, before sending the next direction (see this page for lots of detail). I assume that you have switched from Safe Walk (the default) to Slow Walk...but is the mapper detecting your prompt correctly? |
The whole issue here is about the prompt.
For example, I input "west" and then immediately "west", to travel west twice, it's too rapid input and the MUD travels once, outputs room info, prompt, then says "command queued" and immediately sends another promt, then (when the second "west" is processed) travels once again, outputs room info, and NO PROMPT, because the corresponding prompt was send after the "command queued" warning.
I use Slow Walk, and the MUD does recognize my prompt correctly, I'm sure about this. When I set the delay in milliseconds, it's the delay between SENDING a walk command, and SENDING the next one. What happens is that after sending the first one, the delay count starts, the MUD lags (since Discworld MUD lags), and when the prompt is received, the delay is already gone, and the next command is send IMMEDIATELY after receiving the prompt, causing it to be queued, and thus lose my prompt after next room info.
So, what I need here is for zMUD to receive the first prompt after the first travel, THEN begin to delay for some time, and then send the second command.
In order not to delay after EVERY prompt, I'd need to make it delay only after the first prompt after exit information, or something like that. |
|
|
|
|
Arminas
Wizard
Joined: 11 Jul 2002
Posts: 1265
Location: USA
|
Posted: Fri Feb 29, 2008 3:17 pm
|
Well, make a multi state trigger that tells you when your exit line fires and after that when you receive the real prompt you #tag prompt that one.
So something like
#trigger rname {[stuff to match room name]} {#tag roomname}
#cond {stuff to match exit line} {#tag exit}
#cond {stuff to match prompt} {#tag prompt} |
|
_________________
Arminas, The Invisible horseman
Windows 7 Pro 32 bit
AMD 64 X2 2.51 Dual Core, 2 GB of Ram |
|
|
|
JQuilici
Adept
Joined: 21 Sep 2005
Posts: 250
Location: Austin, TX
|
Posted: Fri Feb 29, 2008 4:18 pm
|
I want to be sure I understand correctly, because it seems odd. The sequence of events I'm hearing is:
- Speedwalker sends 'w'
- Mud sends room info (name/desc/exits)
- Mud lags for a while
- Mud sends prompt
- Speedwalker sends 'w' again (immediately)
- Mud queues the second 'w' because it came too soon after the prompt (?!?)
In other words, the time between #1 and #5 doesn't matter (or the Step Delay would solve it)....but the time between #4 and #5 does. This strikes me as very peculiar, but I don't claim to know what MUD implementors are thinking.
If that is an accurate description, I think you have to write triggers that manually #PAUSE the speedwalk & record the time after each direction is sent, detect the prompt, insert a time delay if necesary, then #STEP. If that's NOT an accurate description, then please set me straight. 
Regarding NOMAP: My understanding is that the mapper doesn't even see any lines which have #NOMAP called on them. For instance, on Mozart, I have triggers which #NOMAP all the weather messages, so I no longer wind up with any spurious rooms named 'You are caught in a rainstorm' and the like (which used to happen if the weather message appeared between my direction being sent and the room name being received). |
|
_________________
Come visit Mozart Mud...and tell an imm that Aerith sent you! |
|
|
|
Indral
Newbie
Joined: 27 Feb 2008
Posts: 9
|
Posted: Fri Feb 29, 2008 7:06 pm
|
| JQuilici wrote: |
- Speedwalker sends 'w'
- Mud sends room info (name/desc/exits)
- Mud lags for a while
- Mud sends prompt
- Speedwalker sends 'w' again (immediately)
- Mud queues the second 'w' because it came too soon after the prompt (?!?)
In other words, the time between #1 and #5 doesn't matter (or the Step Delay would solve it)....but the time between #4 and #5 does. This strikes me as very peculiar, but I don't claim to know what MUD implementors are thinking.
If that is an accurate description, I think you have to write triggers that manually #PAUSE the speedwalk & record the time after each direction is sent, detect the prompt, insert a time delay if necesary, then #STEP. If that's NOT an accurate description, then please set me straight. |
That's precisely what's going on. I was trying to do what you suggest here, but I just don't have enough grasp over all these commands. Plus, I got steps being #OK-ed and slowwalk continued even if it's the wrong room. I suppose I just have to RTFM and spend some more testing.
| JQuilici wrote: |
| Regarding NOMAP: My understanding is that the mapper doesn't even see any lines which have #NOMAP called on them. For instance, on Mozart, I have triggers which #NOMAP all the weather messages, so I no longer wind up with any spurious rooms named 'You are caught in a rainstorm' and the like (which used to happen if the weather message appeared between my direction being sent and the room name being received). |
Thanks! I just got my problem solved regarding post-prompt-pre-roomname text. I just #NOMAP-ed all blank lines, probably making it all one big paragraph for the mapper, so my #TAGs do the rest. THANK YOU!! |
|
|
|
|
JQuilici
Adept
Joined: 21 Sep 2005
Posts: 250
Location: Austin, TX
|
Posted: Fri Feb 29, 2008 9:36 pm
|
| Indral wrote: |
| That's precisely what's going on. I was trying to do what you suggest here, but I just don't have enough grasp over all these commands. Plus, I got steps being #OK-ed and slowwalk continued even if it's the wrong room. I suppose I just have to RTFM and spend some more testing. |
Fair enough. I'll see if I can whip something (close) up for you. I just didn't want to spend time solving the wrong problem. In the meantime, the best advice I can give is to read the article on Understanding Speedwalking in Detail from the library. Scroll down to the heading 'Speedwalk Scripting' for details on the #PAUSE, #STOP, #STEP, and #OK commands, plus some examples.
And I'm glad that the #NOMAP solution worked for you. |
|
_________________
Come visit Mozart Mud...and tell an imm that Aerith sent you! |
|
|
|
Indral
Newbie
Joined: 27 Feb 2008
Posts: 9
|
Posted: Sat Mar 01, 2008 8:50 pm
|
Ok, I think I got it 99% percent working!
The 1%, however, is a purely aesthetic thing.
Namely, I made a prompt trigger that checks whether I'm speedwalking, and pauses the walk, waits for 1.2 seconds, and then if the room was correct, resumes the walk, otherwise stops it.
| Code: |
#TRIGGER {~>%s} {
#IF (%inwalk) {
#VAR ok %walkconfirm
#PAUSE
#WAIT 1200
#IF (@ok) {#STEP} {#STOP}
}
} "" {nocr|prompt} |
The reason I used a variable instead of just #IF (%walkconfirm) is that after a #PAUSE, %walkconfim becomes false. 
I got it set up so that the mapper automatically makes #OK after matching room name, and sets %walkconfirm to true.
Anyways, this works like quite fine, but, when I get to the destination of the speedwalk, this code runs once again. Now, I thought that in the last room, %inwalk would become false.
So, I tried with #IF (%inwalk & (%destroom != -1)), instead of the above #IF (%inwalk), because %destroom is -1 when you're at the destination.
Now, what happened here is really weird:
I start a speedwalk, %destroom is always the number of the room that is my destination. BUT, after the first #PAUSE, %destroom becomes -1, and remains -1, as if I were already on the destination, and my trigger never fires again. Very weird.
So I settled for the #IF (%inwalk), and as I say, the only result is that I get an extra #PAUSE having arrived at the destination, which doesn't matter because the speedwalk ends anyway.
I wanna thank you all for your advice, and help!
Wouldn't have made such a trigger without you! |
|
|
|
|
JQuilici
Adept
Joined: 21 Sep 2005
Posts: 250
Location: Austin, TX
|
Posted: Tue Mar 04, 2008 1:21 am
|
Glad it worked. Especially since I hadn't gotten around to writing anything myself.  Your solution looks very much like what I had floating around in my skull, BTW.
Regarding your end-of-walk problem...you could save the destroom to a variable at the beginning of the walk and clear it at the end. Then you could use the variable for your comparison, and eliminate the extra wait at the final run of the script. |
|
_________________
Come visit Mozart Mud...and tell an imm that Aerith sent you! |
|
|
|
|
|
|
|
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
|
|
