 |
sav
Wanderer
Joined: 09 Jan 2006
Posts: 86
|
 Posted: Tue Oct 19, 2010 8:32 pm
Speed issues.
|
Does anyone know what's the fastest way to send a huge number of commands(2000-3000) to the mud as quickly as possible?
I've tried just putting all the commands into 1 single alias, then i have to sit and wait for like a minute while the commands just scroll past. Is there anything else i can do or is this the only way?
Also, when i'm using #WALK to travel through many rooms(maybe 500 or so) is it normal that cmud doesn't seem to send all of it in 1 chunk, but seems to send the commands 1 by 1 relatively quickly? Is it possible for cmud to calculate the shortest path, then dump all the directions to the mud and let the mud handle the rest?
I hope i'm making sense. Basically, i'm just looking for ways to speed up my gameplay. So even if you don't know the answers to my specific questions, any general advice on how to speed up triggers and aliases would also be much appreciated.
Thank you!! |
|
|
|
|
coriandergrass
Beginner
Joined: 07 Oct 2010
Posts: 15
|
Posted: Tue Oct 19, 2010 8:40 pm
|
Looks like you're using slow walk method, swith it to speed walk.
|
|
|
|
|
sav
Wanderer
Joined: 09 Jan 2006
Posts: 86
|
Posted: Tue Oct 19, 2010 9:30 pm
|
nope, i'm in fast mode. i still find it slow though.
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Oct 19, 2010 10:14 pm
|
In fast mode, CMUD sends all of the commands in the speedwalk to the MUD in one chunk. Any delay that you see is a delay imposed by the MUD, or just a delay in echoing the commands back to the screen. If you turn on the Raw Input/Output message in the Script Debugger window you will see CMUD send all of the commands to the MUD in one packet.
The only general speedup advice is to disable un-needed triggers. Any active triggers will try to match each line from the MUD and slow things down. Certain wildcard trigger patterns are slower than others, so without seeing your triggers I can't really offer any specific advice.
The other tip that might speed this up is to set the Refresh Amount in the Scrollback preferences to zero. That will prevent any lines from the MUD from refreshing the screen until no more output is received from the MUD. So CMUD will only refresh the screen at the end of the speedwalk (or at the end of any partial network packets sent from the MUD). But it's usually not the screen I/O speed which is the problem...it's using your triggers.
You can also use the Script Debugger window to see which triggers, if any, are firing on the text. Maybe you have a trigger that is firing on each line by accident or something.
Finally, keep in mind any MUD-specific rules about spamming that many commands. Sending 2000-3000 commands to the MUD all at once causes extreme server load, and if the MUD has a rule against that, you might get banned. |
|
|
|
|
Rorso
Wizard
Joined: 14 Oct 2000
Posts: 1368
|
Posted: Tue Oct 19, 2010 10:24 pm
|
| Zugg wrote: |
Finally, keep in mind any MUD-specific rules about spamming that many commands. Sending 2000-3000 commands to the MUD all at once causes extreme server load, and if the MUD has a rule against that, you might get banned. |
Say a command is 20 bytes including newline, wouldn't that be just 40 KB? That's less than the Zugg Software logotype on this website. I don't say it is good to send that many commands, but I am curious about how extreme server load it actually could cause.
Most MUDs likely have a command delay so that it doesn't matter how fast you send the commands - you still have to wait.
Why is there a need to send that many commands? You're doing some kind of sorting of your inventory bags?  . |
|
|
|
|
sav
Wanderer
Joined: 09 Jan 2006
Posts: 86
|
Posted: Tue Oct 19, 2010 11:17 pm
|
thanks for the quick responses.
what do the numbers to the left of the debugger mean? can't seem to find an explanation anywhere. |
|
|
|
|
Rahab
Wizard
Joined: 22 Mar 2007
Posts: 2320
|
Posted: Wed Oct 20, 2010 12:39 pm
|
It causes server load on the mud because it suddenly has to _process_ all of those commands. On some muds that could cause lag of several minutes.
|
|
|
|
|
sav
Wanderer
Joined: 09 Jan 2006
Posts: 86
|
Posted: Wed Oct 20, 2010 1:55 pm
|
| Quote: |
| If you turn on the Raw Input/Output message in the Script Debugger window you will see CMUD send all of the commands to the MUD in one packet. |
How do you see that its one packet? It seems to just send everything one by one, albeit faster than slow mode.
The next 2 are triggers to capture info that the mud outputs to me every 2(?) seconds or so. They're regex triggers, and the #GAG and #VAR under both patterns are what i have in each individual trigger. I use the variables captured and output them to a status bar. but it might be these triggers that are slowing me down. Is there anyway to streamline this process?
| Code: |
\[M:(\d+)?\/?\]\[J:(\w+)?\]\[G:(\w+)?\]\[X:(\d+\.\d+)%?\]\[Y?:?(.*)?:(.*)?\]
#GAG
#VAR m %1
#VAR j %2
#VAR g %3
#VAR x %4
#VAR y %5
#VAR ys %6 |
| Code: |
\[Hp:(\d+)\/(\d+)\]\[Sp:(\d+)\/(\d+)\]\[Stam:(\d+)\%\]\[Ham:(\d+)\%\]\[C:(\d+)\/(\d+)\]\[Cl:(\d+)\/(\d+)\]\[(\d+)\%\]\[H:(\d+)\]
#GAG
#VAR hp %1
#VAR maxhp %2
#VAR sp %3
#VAR maxsp %4
#VAR stam %5
#VAR ham %6
#VAR crit %7
#VAR maxcrit %8
#VAR cl %9
#VAR maxcl %10
#VAR clres %11
#VAR h %12 |
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Wed Oct 20, 2010 5:10 pm
|
| Quote: |
| How do you see that its one packet? |
Sorry, I mis-spoke. They are not actually sent in a single network packet, but they are sent all at one time. For example, when I used a #WALK command, I got this in the Script Debugger Window:
| Code: |
3.2795 |
0.0007 | c Aardwolf | [1] Aardwolf Comline : start :
0.0034 | ---
0.0009 | a Aardwolf |s
0.0020 | i Aardwolf >s<CR><LF>
0.0454 | a Aardwolf |s
0.0020 | i Aardwolf >s<CR><LF>
0.0464 | a Aardwolf |s
0.0020 | i Aardwolf >s<CR><LF>
0.0489 | a Aardwolf |s
0.0021 | i Aardwolf >s<CR><LF>
0.0470 | a Aardwolf |s
0.0017 | i Aardwolf >s<CR><LF>
0.0497 | a Aardwolf |w
0.0020 | i Aardwolf >w<CR><LF>
0.0134 | a Aardwolf |n
0.0016 | i Aardwolf >n<CR><LF> |
All of that was sent before any data from the MUD was received. So it shows that the MUD is receiving all of the speedwalk commands at once.
For your triggers, you might put them into a class and then disable that class during your #WALK command. Create an alias for walking like this:
| Code: |
| #ALIAS walk {#T- PromptTriggers;#WALK %1;#WAIT 5000;#T+ PromptTriggers} |
Adjust the #WAIT delay as needed. This will turn off your prompt trigger, send the #walk commands, then wait 5 seconds and turn your prompt triggers back on again. Put any triggers that you don't need during speedwalking into the PromptTriggers class folder.
And yes, if you are doing a #GAG for your prompt, that could cause a screen refresh and could slow down the processing. Since speedwalking is going to spam the screen with a ton of text anyway, you don't really care if the prompt is gagged or not while walking.
Of course, if the delay is being added by the MUD itself, then there really isn't anything you can do about it.
| Quote: |
| what do the numbers to the left of the debugger mean? can't seem to find an explanation anywhere. |
The numbers are the timestamp values. It shows the number of seconds that passed since the previous line. The letter after the | character refers to the Message Type and matches the letters in the Message menu in the Script Debugger window. The "i" message is raw input/output. For the "i" message, the character after the window name is > if the packet is being sent from CMUD to the server, and is < if the packet is being received FROM the server. It is * if the packet FROM the server is compressed using MCCP. |
|
|
|
|
sav
Wanderer
Joined: 09 Jan 2006
Posts: 86
|
Posted: Wed Oct 20, 2010 10:11 pm
|
Ok thanks, i'll do that.
Is the way i'm capturing my the prompt and displaying it on my status bar the fastest way already? |
|
|
|
|
|
|
|
