Zugg Software :: View topic - cMud 2.37 slow/choppy to enter longer commands

Beginner Joined: 17 Jan 2010 Posts: 20

I just recently experimented with upgrading from zMud7.21 to cMud 2.37.

When I enter a short command, 1 or 2 letters, lets take "gr" for instance...
I can hold down enter and the command spams pretty smoothly.
When I enter a longer command, such as "whois ardath", and I hold down enter,
the commands go through slower and choppier.
There seems to be a delay for longer commands.

(I am not even talking about the Muds response to such commands being choppy
I am just referring to the commands themselves showing up delayed/choppy).

I have tried it with no settings installed whatsoever (triggers/aliases/etc).
I have looked through all the settings and options.
I am using Windows XP.

I may be forced to stay with zMud if I cannot make spamming commands go smoothly.
Any help would be appreciated.

Beginner Joined: 17 Jan 2010 Posts: 20

bump...

I uninstalled CMud, deleted my CMud directory, and reinstalled, and without adding any settings, it is still slow. I thought CMud was supposed to be fast :p

I have 2.8 GHz cpu and 1GB ram, that should be enough to enter commands into a text program, I don't think that is the problem.

My theory is that when I installed the first time, and I imported by old settings zMud settings, there were compatibility problems, particularly the way I did my colors in zMud... because upon opening cMud for the 2nd time, it gave me some weird "limegreen is not an integer" error. I had changed my colors around in a sort of strange way in zMud, because zMud's color options were more restrictive than Cmuds.

[Edit: There is a forum thread about 'limegreen is not an integer', it is because I tried CMud 3.x and then went back to 2.37. So it looks like that is not the problem.]

Somehow, the compatibility problems must have survived my uninstall and deleting the directory, the way the 30 day evaluation timer did. Well, thats the only theory I can come up with...

Anyone have any ideas?

Posted: Thu Jan 21, 2010 7:36 pm

Somewhere there are a few posts about this, check to make sure you have latest drivers, thats kindof important for... "old antiquated" technologies like lots of scrolling text. Make sure you don't have any programs running in background that are eating a lot of CPU time.

You might also check your refresh rate, Tools>General, then click on the session, and scrollback tabs. i think smaller == faster refresh, but more cpu intensive maybe?

Beginner Joined: 17 Jan 2010 Posts: 20

I tried raising/lowering the Refresh Amount. That didn't help.

I just re-installed the latest video card drivers, that also didn't help.

It's not that the screen isn't refreshing or updating properly. It seems more along the lines of CMud spending a long time to parse/process each command I input.

The response text I get back from the Mud is perfectly fast and smooth. There just seems to be a small delay between pressing enter and having the command that I inputted show up on the CMud screen. Which is noticable and annoying for a single command, but especially bad when Im holding down enter to spam a command, then it becomes pretty choppy.

I couldn't find any old threads about this (its hard to know what to search for).

I believe I was having the exact same problem when I tried the 3.x beta version, so it looks like waiting for an upgrade will provide no hope for me :P I really like CMuds features and interface, I hope I don't have to stick with zMud.

Are there some drivers other than video card drivers I need to update?

Posted: Thu Jan 21, 2010 9:00 pm

Try checking your Anti-Spam settings is about the only other thing thats coming to mind.

And yeah Video drivers were the only drivers i was thinking about.

I just checked what it was like on my machine and it's pretty smooth, maybe a lil lag between first command and second but even if i hold the enter key down i can only get maybe a dozen commands spammed in before i get a return from the mud server, and it all scrolls fairly nicely.

Maybe someone else has some thoughts about this?

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

What scripts do you have? Doing a lot of command-line processing could likely create these conditions.

Posted: Fri Jan 22, 2010 1:26 am

Every time you press a key, CMUD is checking for macros that might be assigned to the key. When you press Enter, CMUD is checking for OnInput triggers. So definitely check your scripts. You can run the Script Debugger window and turn on the Show All Scripts message to see what might be running. You might want to export your scripts to XML and reimport them into a clean package file in case there is something wrong with your package causing the slowdown. Also run the #THREADS command to see if you have lots of background scripts still running.

One way to test this is to click the Edit Session action and go to the Files/Packages tab and rename your primary package to something new. This will cause CMUD to create a fresh, blank package. Then log into your MUD and see if you still have the lag. You won't have any of your scripts, so it's a good way to determine if a problem is related to your scripts or not.

Finally, I remember an obscure issue with the spellchecker used in CMUD on non-English computers that can sometimes cause command line lag problems.

Beginner Joined: 17 Jan 2010 Posts: 20

Posted: Fri Jan 22, 2010 5:39 pm

Sorry I missed your comments about this happening even without any settings. I'm really stumped on this one. Windows XP should be the fastest of all (Windows Vista and Windows 7 both have slower screen scrolling than WinXP). 1GB of RAM is *plenty* of memory for a small program like CMUD. I have a 7-yr-old WinXP computer downstairs that only has 1GB and it runs just fine.

Even though you say someone else on your MUD said CMUD was slow for them, I really haven't gotten any reports like that (except yours) that we couldn't track down to scripts and stuff.

Have you tried looking at the Windows Task Manager to see what else is running on your computer? You might try rebooting your computer into Windows Safe Mode (I think you press F8 at boottime, then select "Safe Mode with Networking"). That will turn off most background software. Because it's really sounding like something very specific to your computer.

Finally, does it only happen when connected to the MUD? If you just run CMUD and close the Session window, then enter a long line of text on the command line and hold down the Enter key, does it still appear to be choppy? That would help determine if it's a network issue or not.

I just can't think of what difference between CMUD and zMUD could possibly cause this.

Novice Joined: 28 Jan 2010 Posts: 34

I have had the exact same thing happening... a delay in command line display of the commands that I am typing by a half second or so, and thus, a delay in sending to the MUD. When I type a long string (one command line entry) to the MUD, the command line will "catch up" to what I'm typing after that initial hesitation. zMud 7.21 certainly does NOT show any signs of hesitation. Very disconcerting, knowing I'm typing (I can type 60 wpm), but not seeing my input to the command line, especially when I send multiple shortcut commands - i.e. s <cr> e <cr> s<cr> l <cr> (that's a lower case L for look).

Once the command line "catches up" the return info from the MUD is smooth and crisp back to the session window.

Pertinent Info:
XP sp3 2.0GHz
1GB Ram
(normal boot AND safe mode w/ networking)
cmud v2.37
have NOT tried the newer beta.

REALLY interested in solving this to move to cMUD - love the packages and other newer features. Let me know if there is any further info / testing I can do / provide to help resolve these issues.

Posted: Thu Jan 28, 2010 5:14 pm

Here is a procedure that I need everybody experiencing this problem to follow and post results:

1) Run CMUD
2) Close the Sessions window (do not load any of your sessions)
3) Click the Prefs button in the toolbar
4) Click the Session tab on the left side of the prefs window
5) Click the Scrollback tab along the top of the prefs window
6) Check the "Show timestamps" and "Show Delta time" options
7) Click OK to close the Prefs window
8) Click on the command line and type a short command, like "test"
9) Hold down the Enter key and spam this to the screen until the screen is full
10) Calculate the average delta-time being shown in the timestamp column (in my case, it is 0.064)
11) Now enter a long command, like "this is a really long command line to test to see if cmud is slower with really long commands"
12) Calculate the average delta-time shown in the timestamp column (in my case it is 0.077)
13) Post your results here

Now, as shown with my numbers, longer commands *are* a bit slower in this test because the CMUD screen scrolling is optimized to only scroll the minimum number of columns needed. So when scrolling a short command there is less text to scroll than when scrolling a large command. But as you can see, the differences are pretty minor.

Also confirm that you are talking about lag/delay of the command showing up on the screen when you press Enter and that you are NOT talking about any lag/delay within the command line itself showing the characters as you are typing them.

Once you have the above results, then you can open your session Offline and try it again there. Now the speed numbers will be dependent upon any scripts that you have running. You can open the Script Debugger window to see what scripts or triggers are running when you enter short and long commands into the command line.

Finally, keep in mind that CMUD gives priority to displaying incoming text from your MUD. If you have a lot of text arriving from the MUD, you might not see the command that you type echo right away. In the script debugger you will be able to see exactly when the command is sent to the MUD (if you turn on the Raw Input/Output message in the script debugger). Then you will also see when the command is echoed to the screen. The timestamp values in the Script Debugger can be very useful to help learn more about this problem.

Novice Joined: 28 Jan 2010 Posts: 34

[quote="Zugg"]
Also confirm that you are talking about lag/delay of the command showing up on the screen when you press Enter and that you are NOT talking about any lag/delay within the command line itself showing the characters as you are typing them.

Zugg -

Thanks for responding so quickly!

I guess I was unable to express myself clearly enough. I'm not sure if user ARDATH is having the same issue as myself (sounded like it, but your tests don't seem to address it), but my issue is EXACTLY as you describe above (quoted). There is a delay in the command line itself, not the command showing up on the session screen. SPAMMING for me responds even better than your stats (avg 0.056 & 0.058 for long lines). But that is not changing the command line. Everytime I change the command line (no repeating commands), there is a delay in the command line itself with catching up to my typing.

As a point of curiousity, since we are possibly talking about SPAMMING a line to a mud, I tested the command line with & without the auto clear command line option (Options - General - User Interface - Command Line - Autoclear command line checkbox). I found some amazing results:

When autoclear was ENABLED, using just the key strokes "s" and <ENTER>, in a trial of 20 repetitions, I could get an average delta of 0.19xx.

When autoclear was DISABLED, using the same 2 key strokes, in a trial of 20 repetitions, I could only get an average delta of 1.04xx at best.

THAT's 5x's SLOWER! And it was a full second delay, longer than I even thought. That's the issue! cMUD seems to have a delay in trying to remove the previous command line data, then inserting the new data into the command line, prior to a user even pressing the ENTER key.

This does not happen in the older zMUD 7.21 version that I have been using. Please advise if this makes sense. I am very interested in your feedback regarding above reproducable issue.

Have a great day,
Celerra7

Posted: Fri Jan 29, 2010 7:45 am

I cannot reproduce your results at all. And I'm a bit confused. You first said that you got 0.056 and 0.058 for spamming short and long lines, but then you say that spamming just the "s" command gives a delta of 0.19xx??? That doesn't sound right at all. Are you sure you are doing this in a blank session? Sounds more like you have an alias or something.

When I spammed "s" in a blank session, I got an average of 0.030 both with Autoclear enabled or disabled. No real difference.

Be sure you are testing in a blank session. As I said when talking about the command line typing lag: every time you press a key on the command line, CMUD is checking to see if it matches a macro. So if you have corrupted settings with a bunch of bad macro definitions, that can cause problems. So when you run CMUD, close the Session window to get a blank session for testing. You might also remove any DEFAULT.PKG file that you might have in your CMUD, Data Files, or Packages directory since some older beta versions could cause a corrupted version of that file to be created.

Novice Joined: 28 Jan 2010 Posts: 34

Let's take the word and the action SPAMMING right out of this equation:

My test was not spamming - I pressed the "s" key, then I pressed the <enter> key, then I pressed the "s" key, then I pressed the <enter>, and so on, as fast as possible. Tap 2 keys alternately as fast as possible, and you should be able to see information hitting the session screen in about 0.2 delta.

Yes, I am using a blank session, no packages, no MUD connection, just as you suggested to see what the client was able to produce for delta's.

In Autoclear Mode ON, the delta was 0.2
In Autoclear Mode OFF, the delta was 1.0

cMUD cannot clear the command line and feed the new input fast enough to keep up. Atleast that is my experience.

I have now tested this on cMUD, cMUD pro (both trial versions and clean/default installs in blank/non-connected session) on XP sp3, Vista, and server 2003 (all OS's on different hardware). All produce the same results.

Thanks, and have a great day.
Celerra7

Posted: Fri Jan 29, 2010 5:57 pm

Can anybody else try to reproduce this? I consistently get around 0.2 no matter whether Autoclear is on or off. Same on Windows 7 and Vista and WinXP (all different hardware). Also in a blank/non-connected session. So I have no idea what is causing the difference on your systems. Also no difference between v2.37 and the 3.12 beta.

So I'm completely perplexed on this one.

Wanderer Joined: 21 Jan 2008 Posts: 62

Zugg, Celerra's problem sounds similar, but maybe not the same (( it sounds like Celerra's speeds up at some point and mine was quite consistantly slow (on super long command line texts )) as the problem I had when I would hit ctrl-f (or almost any other 'wizard' ctrl-shortcuts).

As you may remember... the only way for me to 'solve' this for myself was export settings to xml, reinstall, import from xml (into brand new session).

possible session corruption was my problem, but really unknown.

Novice Joined: 28 Jan 2010 Posts: 34

Zugg -

I've found the cause - outright processor speed is affecting how quickly cMUD can clear the command line and insert the newly typed information.

I had a buddy install cMUD and run the same tests as I did, but he had no problems either (frustrated the heck out of me). Until, I asked him what he had "under the hood". He was running an AMD Extreme processor.

I went back to start checking my hardware, since I had nothing close to his power:

Case 1 - my workstation with a 2.0GHz single core processor, XPsp3 - slow at 0.8
Case 2 - my server with a 1.8GHz single core proecessor, 2003R2sp2 - slow at 1.0
Case 3 - my laptop with a 2.2GHz dual-core processor, Vista Bus - slow at 0.9

Case 3 is what really perplexed me, since I was sure that cMUD didn't need that much power to run (who would be able to afford a new rig with quad-core extreme processors just to MUD/MUSH). Until I realized, it was running on battery, in power-save mode, so the processor was really pulled back. Once I put it on AC in performance mode, cMUD showed no noticable difference between commandline clear options - no slow response on the command line what-so-ever.

It seems to me that cMUD should have a hardware requirement. You wouldn't think so, with the small footprint that it has, but it certainly looks like a 2.5GHz single-core processor or better is called for. I checked zMUD on all these configurations and never had an issue. I just know now that I need to run cMUD on my laptop to get the performance that I'm looking for.

I am very appreciative of your time and your testing procedures. I was able to use your clean test case suggestions to isolate my issues. I am looking forward to really getting into cMUD.

Thanks and have a great day.
Celerra7

Posted: Sat Jan 30, 2010 4:18 am

No, I'm afraid that's not it either. It's still more likely to be a specific piece of background software or computer-specific setting. My Vista machine is a 3Ghz dual-core, but my XP machine is a 2.0Ghz single core (same as your Case 1).

The command line is just a standard Windows RichEdit control. I'm not doing anything weird with it. CMUD is not even "removing the old line and inserting the new line". When Autoclear is Off, CMUD just does a SelectAll to select the entire command line. This is done by sending a message to the Windows API that is handling the edit control. The only other "unusual" code running on the command line is the spellchecker. Since the command line is not cleared, the spellchecker will try to run to check the command line for spelling problems. But I think you already tried disabling that in the past. The spellchecker has some known problems on non-English computers, but I don't think that would cause this problem.

In any case, even if we tracked down something, I don't even know what I would do in my code to change it.

Beginner Joined: 17 Jan 2010 Posts: 20

I've tried installing CMud on a new machine, with Windows 7, now. Same problem, spamming commands is very slow. Not sure what part of your code is going so slow, but there is something wrong.

Its true enabling auto-clear makes it faster, but then there is no command there to spam.

Posted: Wed May 19, 2010 5:19 pm

For what it's worth, following Zugg's procedure above on a Windows 7 Machine with 2GB RAM and a 2.0Ghz processor with several applications (including another instance of CMUD) running, my average time on both short and long tests came out to be about 0.035.

This is also with a wireless keyboard and low batteries. I'm guessing it has to be something on their system (anti-virus software, maybe?).

Charneus

Beginner Joined: 17 Jan 2010 Posts: 20

I have identified the problem a bit more...

The "longer" commands that give me a delay are 3 letters or more.

2 letter commands go through without any delay (delta time: 0.03 seconds).

3 letter commands are noticably delayed (at least 0.12 seconds, on the default file with no settings)

Interestingly, 3-letters also seems to be the minimum for a command to be stored in the command history. However, setting the "Number of commands to save in history" to 0 did not help, the slow code is being executed either way.

edit: changed the delay times after re-testing

Beginner Joined: 07 Sep 2012 Posts: 20

Hello,
I'm digging up this topic because the same thing just happened to me. I was using CMUD 2.37 PRO, with no problems. But at some point, while drawing map, it crashed. Because I was standing in dangerous place I closed the remains with Task Menager. After that when I restarted CMUD, the command line was taking input slowly, letter after letter, as if i was writing with one hand.

When i checked debug window it seemed like this:
0.0020 | c arkadia | [1] arkadia Comline : start :
0.0025 | a arkadia |> test
0.0068 | j arkadia >test
0.0035 | d arkadia | [1] arkadia Comline : stopped
0.0528 | a arkadia |
0.0008 | a arkadia |Slucham?
0.0007 | a arkadia ]>
0.3492 | ---
0.0005 | c arkadia | [1] arkadia Comline : start :
0.0014 | a arkadia |> test
0.0066 | j arkadia >test
0.0007 | d arkadia | [1] arkadia Comline : stopped
0.2300 | ---
0.0006 | c arkadia | [1] arkadia Comline : start :
0.0021 | a arkadia |test
0.0075 | j arkadia >test
0.0014 | d arkadia | [1] arkadia Comline : stopped
0.0300 | a arkadia |
0.0007 | a arkadia |Slucham?
0.0007 | a arkadia ]>
0.1755 | ---

average latency on --- line was 0,25, while other person who i asked to check had results like 0,1 in that line. And I did it holding the Enter key, not pressing it time after time! It seems like crash has damaged sth there. But I have no idea how to repair it. Reinstalling Cmud didn't help. Reinstaling, removing all directories, repairing register with ccleaner, defragging drive, none of these helped.

If I was playing only with macros and one letter commands it wouldn't be a problem, but everytime when I start writing sth longer, aplications 'hangs' until all the letters appear, what in case of more complex speeches or commands can take dozens of secs. I can use buttons, click on menu as fast as i wish, i can even 'spam' moving through menu options with arrowkeys like a wind. But when I write, until all pressed keys are resolved one by one, everything freezes. I can move cursor, but it didn't even change his look when I move it on menu or sth and doesn't react on clicks, on the other hand, if I ctr+tab to other app I can use that app normally, only that visually cmud freezes and I cannot ctr+tab back to it - until letters are written (as I wrote - whole app is hanged up).

I tried communicators, IRC, java mud client, windows cmd - cmud is the only place where such problem occurs.

It's been 2 days now, and I wonder if I must say bye bye to my awesome scripts and look for other client or there is any way to repair it? (other than reinstalling whole system - with a shred of hope it'd help).

Sorcerer Joined: 15 Apr 2011 Posts: 809

Sounds like something got corrupted when cmud crashed. There's a sticky thread in the cmud forum on how to un-corrupt your settings.

Beginner Joined: 07 Sep 2012 Posts: 20

Wizard Joined: 22 Mar 2007 Posts: 2320

Reinstalling only replaces the software itself. Corruption does not happen in the software, it happens in your own settings which are in your scripts, packages, sessions, etc. To fix those, you should follow the instructions in the sticky thread.