Zugg Software :: View topic

Newbie Joined: 12 Nov 2007 Posts: 9

Running cmud pro 3.34, I now have an issue I haven't seen before.

On long fast speedwalks (over 250) or long series of commands (probably the same), I get disconnected from the mud if I don't break them up with some delays.

I'm told the mud hasn't added anything new to throttle, so any ideas would be most welcome.

Posted: Wed Mar 30, 2016 4:59 pm

Have you tried it with the mapper in safe or slow mode?
The scripting tab in prefs allows you to throttle your own speedwalks.

Newbie Joined: 12 Nov 2007 Posts: 9

Yes, and it is fine with either of those. However, it is not just speedwalking, it is any long series of commands without artificial breaks inserted by me.

Posted: Mon Apr 04, 2016 7:14 pm

Is that an issue that crops up regularly?
Speedwalking is the only time when I would ever send that many commands at once.
For throughput of game grinding, I find many commands could never be processed if all sent at once because of the various pauses games put into place to represent doing the activity, and to slow down character progression.
As such, triggers based on success/fail messages work better, and keep the queued command count down to reasonable numbers.

Maybe if you insert a few #WAITs in there, even if only for 0 milliseconds, it would give the impressions they are not all sent at once.
What exactly are you doing anyway?

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I am going to hazard a guess that the problem is a router some where between you and the MUD viewing the many packets being sent as a DOS attack. You can try a few things to see if this idea is correct. First try to get disconnected by entering the following in the command line:
#LOOP 300 {#CR}
You may have to adjust the count of the loop. If that does a disconnect then the next test is to use the same count needed to disconnect:
#SEND {%repeat(%cr, 300)}

Only do the second test if you get a disconnect with the first one. If you can't get a disconnect with the first then you will have to try again with some harmless command, and you should suspect the MUD as being responsible:
#LOOP 300 {#SEND {harmless}}
#SEND {%repeat(%concat("harmless",%cr),300)}

If the first disconnects and the second doesn't then it is a router issue, you might start by testing to see if your own router is the cause. Assuming a cable modem, you would do the test by plugging your computer directly into the modem. If the disconnect goes away then you might look to adjust your router settings.
If both disconnect then it is the MUD responding to having too many commands at once.

The way to block it is to create an input queue that checks how fast your sending commands. Start with an #ONINPUT to capture everything. You will have to record the last time that a command was sent, for that you want the higher precision Predefined Variable %secs and you may want to allow some number of command to all go through so a sent count. If your count is at the limit you choose for the amount of time then you would put the command into a list using %additem, enable an #ALARM with #T+ to send the next group of commands, and finally #GAG the command to stop it from being sent at this time. In the #ALARM you have to bypass your queuing #ONINPUT, this is done using #SENDRAW. You would use %pop to grab the first item off the list however many times is safe, and then update your record for the last time a command was sent. If the queue is empty then the #ALARM should turn itself off with #T-.

If you use other #ONINPUTs then you would set the priority of this one to be last so that all those others can do there work. I hope my description is thorough enough, I can't write it for you since my machine Windows machine is currently down.

Newbie Joined: 12 Nov 2007 Posts: 9

The CRs worked, but a mud cmd disconnected me. Also, oddly, cmud thinks I am still connected (session timer keeps ticking.

Thanks for the troubleshooting advice. Looks like it is the mud.