Mapping bug

Posted by Shadowfyr on Thu 06 Jun 2002 06:47 PM — 17 posts, 53,940 views.

Shadowfyr USA Thu 06 Jun 2002 06:47 PM #0

Just noticed this glitch...

If you use a something like '3 w' and you are going in a direction you can't move it not only ignores the command, but since it sees 3 invalid direction responses it also deletes three existing and already mapped directions. So:

4w 2n -> 3w

This also can happen when moving quickly, but seems to be harder to reroduce, in most cases trying to more using the keypad in an invalid direction will result in the 'recording' of moves you never made. So hitting west into a barrier 4 times, quickly enough that the mapper doesn't see the fail message after each move produces 3w, since it only deletes the first response it see a return from.

These bugs are really odd, since one would assume that they should be the other way round, i.e. '3 w' should add 3 moves and delete them, not delete previos valid moves, while the keypad moves should be ignoring multiple moves in the invalid direction (or at least keeping track of the number of fail responses it needs to watch for). Not sure how to fix that though since the prompt displays between each fail response when moving by hand, but the first problem should be fixable, since all responses are being seen, but the client is apparently only seeing the w and not the number (this being a mud side repeat x times command and not a speedwalk).

Maybe support for recognizing this common mud command format and a change to ignore user prompt as a break when looking for fail responses.

Nick Gammon Australia Forum Administrator Fri 07 Jun 2002 10:53 PM #1

First, I don't see how MUSHclient will work with MUD-side repeats, because it won't know to add them to the speedwalk list. I would stick with client-side repeats for mapping.

Second, the way the mapper works is to add walks to the list, and remove the latest one when it gets the specified error. However if you move too quickly you will fool it.

eg. 2n 2w 3s

If that is sent quickly (eg. no delay) and the MUD has a lag, and then responds "can't go that way" for the "west" directions (twice) it will actually remove the last two from the list (two of the 3s).

I don't see how you can easily fix this, unless you have a positive confirmation when you walk (which might be possible with MXP). The client needs to see something like:

You walk east.

... if it is going to really know when and where you walk.

Shadowfyr USA Sat 08 Jun 2002 12:07 AM #2

Hmm. Well as to the first you may be correct, though why it can't be customizable to deal with that sort of repeat is questionable. It is hard to remember to switch from doing 90% of the stuff on the mud as '# command" then have to use '#direction' for mapping. This can be confusing.

As to the second thing.. Why need a positive? When you go the wrong way too fast on mine you get:

What?
Prompt>
What?
Prompt>
What?

or something similar. Most clients probably do the same and there is generally not enough time better commands to worry about a tell, channel message or other stuff getting in the way (at least most of the time and over a small number of moves). All the negatives are there, the client just isn't catching them because they are broken by the prompt.

A '# direction' though does this:

What?
What?
What?
Prompt>

The only difference is that the mapping routine is treating a prompt line as a 'good' response, when it should behave like the '# direction' one does. It after all has to know how many moves you tried to make, it should know how many negative responses to expect and simply not worry about the prompt unless the user enters a new command. I am trying to think of any case this would not work, but can't. Another non-direction command should just clear the stack and a new driection just adds another to the stack for it to watch for. As long as some wiz doesn't get cute and send a bunch of invalid direction or What? stuff to you while the client waits to see what you are doing it should work.

Both are fixable, but just not within the limits of the assumptions the client currently makes.

Magnum Canada Sat 08 Jun 2002 11:56 AM #3

With all due respect, cut the mud side fancy multi-moving while you are creating a movement alias. I mean, how often do you create movement aliases? Take your time, move slowly so that your screen updates properly after each move. When you are done, save the movement and smile.

My point is, this shouldn't be too much of a bother for you to work around, while attempting to program around that could be a big bother, and I feel it's too trivial an issue for that. Patience, grasshopper. :)

Shadowfyr USA Sat 08 Jun 2002 06:53 PM #4

Right Magnum... Patients may be a virtue, but consider this... I assume that the two clients that do have true mappers in them ran into this problem, realized what it was and fixed it. Once macro definitions become mappable to any key and you can call scripting with them, someone is likely to eventually make a true mapper to pug into this program. They 'could' design it with a bloody lot of extra triggers and things to check to make sure that it does work right, but unlike the client, scripts have 'no' way of knowing that the line just recieved is in fact a prompt and thus have to check for something else to get it right. My point is that the client allows you to set a switch to 'wait' for a prompt before sending the next command, this means that it is aware of them and can, if allowed to do so, simply ignore those as valid.invalid moves and keep checking. As for the idea of not using mud side repeats... Are you going to tell that to everyone that gets confused as to why they don't work? How hard is it to check for a space between the number and direction and assume it means the same thing as the speedwalk version? These are standard features of most muds. Suggesting that they shouldn't be accounted for is like suggesting that you shouldn't be allowed to use custom colors, because they don't represent what the mud's designers intended or something equally pointless. All that is needed is something like this.


if new_direction
  if was_opposite_last <- I don't entirely agree with this one
                       since it fails to take into account odd
                       rooms where the entrances don't match.
    if responses_expected > 0 then
      pop direction
      dec responses_expected
    end if
  else
    push direction
    inc responses_expected
  end if
else
  if client_new_command or new_mud_data then
    if not_prompt then
      set responses_expected = 0
    end if
  end if
end if

This is difficult or impossible? It already checks as I feel somewhat incorrectly for a more that is in the opposite direction from the last move, why not the rest? As
it is if you planned to use the mapper to explore and you suddenly had to run away you either get extra info that shouldn't be there or parts of you existing data swallowed up. If you use it for the only purpose I do, which is to mark a location and later return there automatically, then having it mess up if something goes wrong is not terribly useful. In general it is probably easier to ignore the mapper as it is and right the directions down by hand if trying to figure out a path. When you do need it it to leave some place fast it can fail, 'horribly'.

Magnum Canada Sun 09 Jun 2002 08:39 AM #5

Ok, point taken. My apologies, I was in somewhat of a foul mood and shouldn't have bothered to respond.

Personally, I only use the mapper\speedwalk to move from Login to the various area entrances.

Once the keypad gains the ability to run scripts, we will be able to program our own fixes for mapping errors, and as you said, perhaps even program more elaborate (graphical) mappers...

Shadowfyr USA Sun 09 Jun 2002 06:46 PM #6

Quite true. My interest in seeing how it worked was to try to see if the automatic mapping could be 'borrowed' as a means to get the direction you moved when making a graphics mapper work. It is true that you don't need it if you can remap some things like macros, but there are still problems, like what do you do if someone has a mud where you can 'hop north', you can't do it as a macro and aliases don't look for additional matches 'after' they correctly find one, so one that aliased '*' would capture the input, but would also automatically exclude all other aliases. This is slightly counter productive, since it means you need an alias for each and every possible mapping response to make one. It would be better if the existing mapper didn't bug and allowed for the added option of A) customizing direction aliases and B) calling a script to process the movement. Either way you do it you need an alias for each new command, but it would be nicer if a integrated method existed to set up those specific to mapping, otherwise once the keypad is scriptable, there will be absolutely no reason to even have the current mapper, since a scripted one would be potentially less buggy, more versitile and customizable.

Nick Gammon Australia Forum Administrator Sun 09 Jun 2002 10:37 PM #7

Quote:

All the negatives are there, the client just isn't catching them because they are broken by the prompt.

...

The only difference is that the mapping routine is treating a prompt line as a 'good' response, when it should behave like the '# direction' one does.

OK, first I'll describe how the automapper works, then we can argue about whether there is a "better" way of doing it. :)

Adding to mapper list

In the "send to MUD" routine, directly before text is sent to the MUD, if mapping is enabled the text is sent to the mapper routine. By hooking into this place we catch things like directly-entered commands, aliases, macros, keypad commands, and scripted sends.
In the mapper routine, the line is broken up into individual lines (in case you sent: east <newline> north ) and each line is considered.
If the line is exactly one of the following:

"north", "n", "south", "s", "east", "e", "west", "w", "up", "u", "down", "d", "ne", "nw", "se", "sw"

then it is considered a moving instruction.
If "remove reverses" is enabled then a "reverse" direction is removed from the map list (N followed by S for example).
Otherwise, the direction is added to the mapper list.
The status line is updated.

Mapping failure

During the processing of each line from the MUD (after the newline as been received, and immediately prior to checking for triggers), the line is scanned for the "auto-map failure string" (eg. "You can't go that way").

If there is a match (on the regular expression, or the fixed text) then the most recently entered mapping direction is removed from the list, if any. The idea here is that if you enter:



north  <--- You

You can't go that way  <--- MUD

Then "north" is removed from the list.

Your comment that a prompt line is taken as a "good" response is incorrect. There is no interpretation of good responses. MUDs vary in so many ways in the way they respond to a movement command that the only thing we detect is a failure, not a good response.

If it is not catching the negative because of the prompt you may need to rework the failure string. eg.

^.*What?$

However be warned that if "What?" is your failure string, and it replies "What?" when you type in a bad command, then each bad command will also remove the most recently mapped move.

The mapper is intended as an aid, not something that will work perfectly under all conditions. For instance, these things would throw it out:

Fleeing - "You flee from combat" - which sends you off in a random direction.
Following someone. You move from room to room without the mapper knowing it.
Teleporting or transfering (or spells that do that). That will change your location without the mapper knowing it.
Other commands (eg. "enter house", "leave shop") that the mapper doesn't process.
Entering commands quickly. If you enter moves quicker than the MUD responds, it may remove the wrong one from the list, as I said earlier.

Quote:

I don't entirely agree with this one since it fails to take into account odd rooms where the entrances don't match.

This is an option you can turn off. Usually it will apply, and you don't want to clutter up your speedwalk with "dead ends" but if you are mapping a strange area, turn it off.

Shadowfyr USA Sun 09 Jun 2002 11:53 PM #8

Hmm. Ok.. Then the ability to add direction commands, including something like ([[:numeric:]])\sn for '# n' would be a help. Sadly you are correct about the What?, some areas of the mud from the early days didn't correctly set the fail to something less generic. I was also assuming that it was looking for the response only after the last move and somehow reseting itself to not look after that. A simple switch like I suggest would work better since it wouldn't look for a fail unless it was actually supposed to, so a spoof caused by an invalid command and some twit not setting the fail message correctly on the mud shouldn't cause an incorrect deletion. As for why moving too fast failed... It is that stupid prompt again... Since unless the 'wait for prompt' thing is set in the client (and it bugs me when it is on, since it makes it harder to judge things in combat), the in-coming text from some things will be on the same line as the prompt, this would royally mess up the mapper for most people and for me causes some of the responses to arrive with a leading space. Now why I thought this wouldn't happen... Knowing this unfortunately only lets me fix the ones that can't be spoofed. Sigh..

It would definitely be helpful if it was more distinquishing. True it doesn't deal with following, teleports or fleeing, but what it does do makes a lot of assumptions about how other things on the mud 'should' work that are questionable imho.

At the very least, something like I suggest (the counter I is probably not needed) where it ignores fail responses after you or the client sends a non-map related command would solve half the problems, the other half would likely vanish with customizable matching. This would, if later allowed to call a script, provide a very good base for more complex user designed code, including a graphical add-on.

P.S. I 'knew' you where the one that suggested the ^([ ]*) thing that is causing me so much trouble with my other triggers... '^.*What?%' indead... Try '^\s?What\?%'. Tsks, tsks.. Trying to mess us all up again I see. ;) lol

Nick Gammon Australia Forum Administrator Mon 10 Jun 2002 12:19 AM #9

Quote:

'^.*What?%' indeed... Try '^\s?What\?%'. Tsks, tsks.. Trying to mess us all up again I see. ;) lol

Well, not really. I thought you might have got this ...



<31hp 100m 110mv> What?

Shadowfyr USA Mon 10 Jun 2002 12:32 AM #10

Perhaps, but your version would probably also match on
'         What?', which is what is going wrong with the other 
triggers I tried to fix. ;) Those extra spaces.... Not a good 
idea to be that inspecific.

Hmm. Almost forgot about that extra 1%, since the mapper is not 'prompt' aware it can't tell if the response is recieved on one. This is slighly odd, since the client can tell the difference somehow or you wouldn't have an option to only send commands on prompt lines... How hard would it be to automatically ignore the part that is in the prompt if it is known to be a line that has one?

Nick Gammon Australia Forum Administrator Mon 10 Jun 2002 01:47 AM #11

OK, what I am doing this very instant is adding extra support to plugins to let you do your own thing. :)

Then you can demonstrate how it is done.

What this new support is:

Plugin can capture all commands sent to the MUD, both before and after alias etc. processing
Plugin can capture all output from the MUD, prior to any trigger matching etc.

Effectively this gives you "hooks" into the very place that MUSHclient uses to implement its mapper. (This sort of feature has been requested in the past). Effectively it gives you an alias on "*" and a trigger on "*" but a bit more powerful.

For one thing, by matching on commands *after processing* you get the output of any mucking around, eg. speedwalks, numeric keypad, "world.send" and so on.

However by matching on commands *before processing* you can implement your own features (like auto-say) by capturing the text that is actually entered.

Finally by matching on incoming text from the MUD you can filter every incoming thing, prior to it hitting the trigger evaluation routines.

Plus, by writing multiple plugins you could make one (say) log everything, another do auto mapping, a third do your own speedwalking, and so on.

Anyway, that's the idea. ;)

Shadowfyr USA Mon 10 Jun 2002 06:29 PM #12

Hmm... Interesting.. I still would have preferred something that ran from the existing mapper, but allowed more flexibility. The reason? It is less confusing for a new user and would fix an obvious problem with the existing one, but yes letting the plugin preprocess things like that would technically solve the problem, even if it is not really a very eligant solution. A simple solution would for now be something that treated the following different:

inbound>
^([[:prompt:]]?)(.*) <--- This assumes that you can really
detect the prompt, but is not technically part of the
regular expression types. It may require 'setting' a
regular expression to detect it.

commands>
([[:digit:]]+) (.*) ----> convert to #command, then process.
and the normal
(.*)

the main reason it doesn't work now is because you are only correctly seeing the second form of the command recognition and * as the inbound. This is also not POVRay, so even if I built one that did work better, how likely would it be for you to add it into the existing program as a feature?

Sorry to beat a dead horse, but I consider this to be a big enough annoyance that having to rely on someone elses less user friendly 'patch' (and I am too lazy to friendly something that works well enough for myself) to fix it is not really the 'best' solution.

Hmm. Also... Your suggestion of using the plugin doesn't deal with the command problem. It means that all commands get pre-processed by the plugin even if they where supposed to be aliases -

Alias north
Script doit
[code]sub doit...
if climb then
world.send "climb north"
else
world.send "swim north"
end if
end sub[/code]
Expected behavior -
>north
alias
-script
existing mapper processes

Real behaviour -
>north
plugin mapper pre-processes
alias
-script
plugin mapper pre-processes new output?

This would not be desirable and could potentially be very common, it also can't be 'fixed' short of disabling an removing the plugin causing the problem.

Nick Gammon Australia Forum Administrator Mon 10 Jun 2002 09:37 PM #13

Quote:

This assumes that you can really detect the prompt.

All this talk about detecting the prompt is confusing me. First, people configure their prompts in all sorts of ways, for instance ">" is hardly a very reliable prompt. Second, some servers, like PennMUSH, don't have a prompt at all, so it is hard to detect it. That is why the mapper doesn't try.

Quote:

Your suggestion of using the plugin doesn't deal with the command problem. It means that all commands get pre-processed by the plugin even if they where supposed to be aliases

As I tried to describe, there would be two hooks for commands ...

Before any pre-processing (so you could implement your own alias system, for instance)
After any pre-processing (after aliases etc. are processed).

The second place is the logical one for the mapper, which is where it is at present. So, if your alias changes "north" to "swim north" then "swim north" is what the plugin will get.

They are two different routines, so you can tell the difference.

I also don't see what is not elegant about a plugin mapper. Install the plugin and you have a mapper. What is not elegant about that? You could "talk" to the mapper by providing suitable aliases (eg. mapperon, mapperoff).

I could reproduce the current mapper behaviour in a plugin easily enough, and then you can tell me (show me, preferably) what needs changing.

Shadowfyr USA Tue 11 Jun 2002 01:03 AM #14

Hmm. Ok... That makes sense then.

Now as to the prompt thing.. You have an option that says in effect 'send commands only on prompt', this obviously both works and detects when a new command is ready to be recieved. I assumed it could thus also be used to 'trap' the prompt when it arrived and thus make it easy to ignore without testing for it specifically. However... It may not be necessary to do this when the option is turned on, if off though you then have to test for the prompt (if it exists), or new in-bound info that isn't on one, and that, unless the prompt is 'very unique', can seriously complicate matters. And frankly I hate leaving it on anyway. If it can't be detected in some fashion it just means things are slightly more complex than I assumed.

Nick Gammon Australia Forum Administrator Tue 11 Jun 2002 05:09 AM #15

The option is actually "keep commands on prompt line".

What that really does is allow you to mix different "types" of data on one line.

Prior to that, MUSHclient always kept the following three types of output data on separate lines:

Output from the MUD
Commands you type
World.note output

Thus, if MUSHclient had a line with (say) 30 characters of world.tell on it (without a newline) and got some MUD output, then the MUD output would commence a new line, as you would expect it to (because they are different things).

Similarly, if you had a prompt, and then typed a command it used to start a new line, eg.



<31hp 100m 110mv> north

Using identical logic, it started a new line - so you actually saw:



<31hp 100m 110mv>

north

However some people complained that the commands should really be on the same line as the prompt, hence that option. Now what it does is, if it is about to switch from:



MUD output ---> Your command

It doesn't start a new line.

However, that is not really detecting a prompt as such. It is detecting some MUD output that hasn't finished with a newline. eg. you might have:



-- 10% read -- [more] ---

Or even, just a partially-received line (because TCP/IP breaks data up into packets).

Thus, I don't think that I can say that if I have MUD output, that doesn't have a newline after it, that it is necessarily the prompt, and thus I can't detect a prompt particularly reliably. Let's remember this whole thread started because you wanted the mapper to be more reliable, so trying to add to the reliability with something that itself is not reliable, is not really going to help.

Shadowfyr USA Tue 11 Jun 2002 07:03 PM #16

Ah.. Well not being clear on what it did I made an obvious error. It simply means that the mapper needs to be able to ID the prompt to work. I am not sure what I thought, except that maybe telnet had some sort of special packet for 'this is a prompt', but obviously not. ;)