Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Entire forum
➜ MUSHclient
➜ Bug reports
➜ EvaluateSpeedwalk imposes a limit the mapper does not.
EvaluateSpeedwalk imposes a limit the mapper does not.
|
Posting of new messages is disabled at present.
Refresh page
Posted by
| WillFa
USA (525 posts) 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
| Top |
|
Posted by
| Nick Gammon
Australia (23,122 posts) 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 | Top |
|
Posted by
| WillFa
USA (525 posts) 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?
| Top |
|
Posted by
| Nick Gammon
Australia (23,122 posts) 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 | Top |
|
Posted by
| WillFa
USA (525 posts) 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 | Top |
|
Posted by
| Fadedparadox
USA (91 posts) 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? | Top |
|
Posted by
| Shadowfyr
USA (1,788 posts) 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. | Top |
|
Posted by
| Fadedparadox
USA (91 posts) 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) | Top |
|
Posted by
| Shaun Biggs
USA (644 posts) 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. | Top |
|
Posted by
| Fadedparadox
USA (91 posts) 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. | Top |
|
Posted by
| Shadowfyr
USA (1,788 posts) 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. | Top |
|
Posted by
| WillFa
USA (525 posts) 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. | Top |
|
Posted by
| Nick Gammon
Australia (23,122 posts) 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 | 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.
39,503 views.
Posting of new messages is disabled at present.
Refresh page
top