[Home] [Downloads] [Search] [Help/forum]

Gammon Forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Bug reports
. . -> [Subject]  EvaluateSpeedwalk imposes a limit the mapper does not.
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?

EvaluateSpeedwalk imposes a limit the mapper does not.

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page


Posted by WillFa   USA  (525 posts)  [Biography] bio
Date Sun 28 Jun 2009 11:50 PM (UTC)
Message

for i=1,200 do
  AddToMapper("w")
end

print(GetMappingString()) -- --> 200("w"/)
print(EvaluateSpeedwalk(GetMappingString())) -- --> *Speed walk counter exceeds 99
[Go to top] top

Posted by Nick Gammon   Australia  (21,322 posts)  [Biography] bio   Forum Administrator
Date Reply #1 on Mon 29 Jun 2009 12:59 AM (UTC)
Message
The bug (or inconsistency) is really in AddToMapper.

Speedwalks have a documented limit of 99 on the multiplier, see:

http://www.gammon.com.au/scripts/doc.php?general=speed_walking

However AddToMapper does not check whether that limit is reached. In fact, the mapper directions are held as a list (not a speedwalk string), and all AddToMapper does is add to the tail of that list.

It is possible, as you demonstrated, to make a mapping string that then cannot be evaluated. I suppose I thought when I wrote AddToMapper that in a real-life situation, you are unlikely to walk (say) 100 times north, without some intervening direction change.

Since AddToMapper is a scripted function, the person who writes the script really has the responsibility to make sure the mapper string is not ridiculous. I notice also from the code you can probably use the internal mapper to also generate a string that will not work (by walking in the same direction 100 times), but again this is unlikely to happen in a real-life scenario.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by WillFa   USA  (525 posts)  [Biography] bio
Date Reply #2 on Mon 29 Jun 2009 01:14 AM (UTC)
Message
There's a few areas on 3k that are greater than 100x100 (like the abyss, elemental plane, loops in ravenloft). I was able to walk south 110 times and the mapper made 110s as well.


while (isdigit (*p))
      {
      count = (count * 10) + (*p++ - '0');
      if (count > 99)
        return MakeSpeedWalkErrorString (Translate ("Speed walk counter exceeds 99"));
      }   // end of having digit(s)

The loop there will handle more than a 2 digit number. While it's unlikely, and Stupid User Tricks might make a speedwalk for 10000s... is Stupid User Tricks the only reason for the 99 limit?

I agree it's unlikely you will, but what's the reason you can't?
[Go to top] top

Posted by Nick Gammon   Australia  (21,322 posts)  [Biography] bio   Forum Administrator
Date Reply #3 on Mon 29 Jun 2009 02:08 AM (UTC)
Message
Well the main reason was I was worried that, due to maybe mistyping, or maybe if you got a bit annoyed with someone, you might type:


# 555 w
# 2000 (say go away you pest)


Now with the 555w, expanded that would be 555 * 5 bytes (including the newline) sent to the MUD, which is quite a bit of text for only 5 or so characters typed. And I think the abuse of the "say" is another obvious example.

I suppose the limit could be increased a bit to, say, 150. I think this is a theoretical issue for most people rather than a practical one.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by WillFa   USA  (525 posts)  [Biography] bio
Date Reply #4 on Mon 29 Jun 2009 02:47 AM (UTC)

Amended on Mon 29 Jun 2009 02:48 AM (UTC) by WillFa

Message
The main thing that I'm concerned about is that the mapper can make speedwalks that can't be evaluated.

I haven't looked at the source of func/routine that compacts the list into a string, but how difficult would it be to put in something that while concatenating the string turns i.e. 150s into 99s f 51s

No matter what limit you choose, it'll be arbitrary. I just think it should be implemented consistently. :)




And if you want to send #2000(anything) that's what LPEG is for :D
[Go to top] top

Posted by Fadedparadox   USA  (91 posts)  [Biography] bio
Date Reply #5 on Mon 29 Jun 2009 05:52 AM (UTC)
Message
Why not leave the default at 100 but let it be changed somewhere in the options?
[Go to top] top

Posted by Shadowfyr   USA  (1,783 posts)  [Biography] bio
Date Reply #6 on Tue 30 Jun 2009 02:28 AM (UTC)
Message
Hmm. For some muds, converting those commands from like 5w to 'west west west west', doesn't make sense anyway. Would be better to have a flexible system, which let you define a) how many to allow at all, and b) if you can send the "raw" command, or c) if you can use the original commands, but not with such large numbers, where to "split" them, so they will work. I.e., if the mud only allows up to say 10w, and you give it 100w, split it into 10 cases of 10w.

The limitations of the mapper/speedwalk built in to the client led me to just not use it at all, and feed my commands out in my own code instead, since I could adjust for what the mud "allowed", while still using the #<direction> system the mud allowed, and, in my case, add in a "brief" command at the start and end. (The mud's room description functions overloaded when needing to do long "fast" walks, even if you slowed them down a bit, so by 'briefing' I could switch to "room name only", then restore the full room "just before" the last action, which was always a single move.)

The built in.. just can't handle real world cases very well, at all. A bit more flexibility would help a lot.
[Go to top] top

Posted by Fadedparadox   USA  (91 posts)  [Biography] bio
Date Reply #7 on Tue 30 Jun 2009 03:03 AM (UTC)
Message
I'm not sure I understand the problem.

You can include a 'filler' command such as look, and use it with f in the speedwalk, like so:

#10w f 10w

You can also put in a delay in milliseconds.

If you mean actually sending #10w to the MUD, you could easily do something like:

#5(#10w)
[Go to top] top

Posted by Shaun Biggs   USA  (644 posts)  [Biography] bio
Date Reply #8 on Tue 30 Jun 2009 04:15 AM (UTC)
Message
@Fadedparadox Although those are good workarounds for creating the speedwalks in a way that gets properly evaluated by EvaluateSpeedwalk, the issue is in how they are entered vs. how they are output.

The mapper will allow you to enter in a speedwalk that cannot be evaluated properly. Whatever limits would be placed on the speedwalks, I agree with WillFa, in that they should be exactly the same on input as they are in output.

It is much easier to fight for one's ideals than to live up to them.
[Go to top] top

Posted by Fadedparadox   USA  (91 posts)  [Biography] bio
Date Reply #9 on Tue 30 Jun 2009 05:49 AM (UTC)
Message
Shaun, I was replying to Shadowfyr when is said "I don't understand the problem" and offered solutions to what I thought it might be.

I agree with WillFa on the idea that it should allow more than it does, and be consistant, hence my post "Why not leave the default at 100 but let it be changed somewhere in the options?" That idea is under the presumption that both input and output would respect whatever limit you place.
[Go to top] top

Posted by Shadowfyr   USA  (1,783 posts)  [Biography] bio
Date Reply #10 on Tue 30 Jun 2009 07:09 AM (UTC)
Message
Was just giving an example of what I ended up doing in a certain case. My understanding, which could be wrong, is that when you evaluate it, (based on Nick's comment about 555 w), is that it "breaks up" the mapper input into individual commands, or sends individual commands, not the "#<direction>" you originally entered. On many muds this is really not the sort of thing you want to do. So, if you are changing the setup to honor a "setting" for how many repeats, why not a setting that allows you to say, "here are the number of allowed repeats, but *keep* the existing syntax." In other words, if you mud can use them, don't waste time, once you are sure they are in the allowed range, feeding out unneeded commands.

Wonder though.. If the client fails to add the step, does AddToMapper return an error code? So, if you tried 100, and it was set to only allow 20, it would return a code specifying that it "didn't" add them, or truncated them to the allowed range? If not, then that is already a design flaw. It should be possible to tell "if" the thing being entered to the mapper "is" what you intended, or it failed, and why.
[Go to top] top

Posted by WillFa   USA  (525 posts)  [Biography] bio
Date Reply #11 on Tue 30 Jun 2009 07:17 AM (UTC)
Message
Currently AddToMapper and AutoMapping will add anything to the list, whether EvaluateSpeedwalk will expand it later or not.
[Go to top] top

Posted by Nick Gammon   Australia  (21,322 posts)  [Biography] bio   Forum Administrator
Date Reply #12 on Tue 30 Jun 2009 09:52 PM (UTC)
Message
Hmmm- GetMappingString was introduced in version 3.03 on 9th August 2000.

I must admit that the documentation for GetMappingString says:


Returns the speedwalk string generated by the auto-mapper. This is a string that can be sent to EvaluateSpeedWalk to convert it into appropriate commands for sending to the MUD.


Thus, it should work consistently, Willfa is right. (I thought I almost got away with it for 9 years, phew!) <evilgrin>

In version 4.42 GetMappingString will break up the returned string so that it is batched into groups of 99 or less. To use his example at the head of the thread:


print(GetMappingString()) --> 99(w/) 99(w/) 2(w/)


- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


9,239 views.

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page

Go to topic:           Search the forum


[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

[Home]


Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at FutureQuest]