Hello everyone,
I've been working on translating a script for walking from monster to monster that I have written for tiny fugue into Lua and using it with Mudlet. It basically relies on following a path, detecting monsters and comparing the monsters to a table of kill-names to determine if it should stop or not. It moves to the next room on a prompt trigger.
The issue I am seeing is let's say I start in an area that's mostly cleared. With Mudlet, I'll move maybe 2 rooms a second, almost as if something is throttling my input/output. Normal commands go through fine, and using an alias to get to an area is super quick. Once I start combat, commands go through like normal. Looking in the bottom right corner, my "S" number never seems to go over 0.001. I've tried optimizing my nasty regex triggers by doing a multiline AND, using a start of line trigger as the first condition and the regex as the second.
For a speed comparison, when running the same logic in Tiny Fugue, it's extremely fast, and I don't see any reason why Mudlet wouldn't be just as quick. Even a similar walker written in zScript for Cmud was about as fast as Tiny Fugue.
Has anyone ran into anything like this before? I'm on a Windows 7 X64 machine, and I did set Mudlet's priority to "real time" to see if that helped, but it didn't seem to.
Any help would be appreciated, thank you.
Mudlet slow sending commands
Re: Mudlet slow sending commands
I've been playing with this some more, and if I send an empty command while in the middle of walking, it will sometimes speed up to the speeds I was seeing with Tiny Fugue, if not faster. Still not sure why it moves at a snail's pace while walking normally.
Re: Mudlet slow sending commands
One more interesting thing to note. When I'm moving slow, I see the following pattern:
Room 1 (n,e,w)
>
Room 2 (n,e,w)
>
Room 3 (n,e,w)
The prompt is always by itself after the room name. When I started moving at lightspeed, I saw the following:
>Room 1(n,e,w)
>Room 2(n,e,w)
The prompt was on the same line as the room short description.
I'll have to mess around with my prompt trigger; I'm guessing it is the culprit somehow.
Room 1 (n,e,w)
>
Room 2 (n,e,w)
>
Room 3 (n,e,w)
The prompt is always by itself after the room name. When I started moving at lightspeed, I saw the following:
>Room 1(n,e,w)
>Room 2(n,e,w)
The prompt was on the same line as the room short description.
I'll have to mess around with my prompt trigger; I'm guessing it is the culprit somehow.
Re: Mudlet slow sending commands
If your MUD doesn't send a GA (go ahead), then you should disable that option in settings, as I find that seems to speed things up for most Windows users.
Re: Mudlet slow sending commands
Is that the "Force telnet GA signal interpretation off" option?
Also, when I changed my mud prompt to have a newline at the end (it normally doesn't), then updated my prompt trigger to have ^>$, then it sped up drastically. I'll try that option, and see if I can get something working with no newline in the prompt.
Thanks!
Also, when I changed my mud prompt to have a newline at the end (it normally doesn't), then updated my prompt trigger to have ^>$, then it sped up drastically. I'll try that option, and see if I can get something working with no newline in the prompt.
Thanks!
Re: Mudlet slow sending commands
That is the option you are looking for. And the reason a newline speeds up trigger processing, is that the line is complete, so it isn't waiting for possible additional ways to match your pattern. You can achieve something similar by having the prompt terminate with a character that is specifically excluded from any pattern based matches, so there is no way to include that character in anything else, essentially acting like a new line does.
Re: Mudlet slow sending commands
That makes sense. I must have had something slightly different with my TF setup, or it is the way that TF handles prompt hooks that was making it faster. I don't really have any issues having a newline in the prompt, and then I can even deleteLine() on it so it cleans it up.
Thanks for the help.
Thanks for the help.