for i=1,200 do
AddToMapper("w")
end
print(GetMappingString()) -- --> 200("w"/)
print(EvaluateSpeedwalk(GetMappingString())) -- --> *Speed walk counter exceeds 99
EvaluateSpeedwalk imposes a limit the mapper does not.
Posted by WillFa on Sun 28 Jun 2009 11:50 PM — 13 posts, 55,223 views.
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.
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.
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.
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?
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?
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:
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.
# 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.
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
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
Why not leave the default at 100 but let it be changed somewhere in the options?
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.
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.
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)
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)
@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.
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.
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.
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.
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.
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.
Currently AddToMapper and AutoMapping will add anything to the list, whether EvaluateSpeedwalk will expand it later or not.
Hmmm- GetMappingString was introduced in version 3.03 on 9th August 2000.
I must admit that the documentation for GetMappingString says:
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:
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/)