Zugg Software :: View topic

Wanderer Joined: 11 Mar 2002 Posts: 93

Back in version 2.25 I had an incident where the the more scroll/faster the scroll the more my command line would lock up until such a time as the spam/scroll virtually halted, allowing me to once again enter commands.

In version 2.27 and 2.28 this issue seemed to have gone away. I originally had thought it a case of finally tweaking enough settings that the problem resolved itself, but when I installed version 2.29 the problem returned once more.

To verify that this was CMUD and not myself I rebooted my computer so that everything was fully loaded in the background from startup once more, installed version 2.29 in one folder and 2.28 in another, then proceeded to install all my packages into both versions and make sure all settings were the same.

I then entered my spam test:

#50 look

and tried to enter commands on the command line.

In version 2.28 I had a slight delay which was expected and reasonable, but I could still enter commands and have things happen.

In version 2.29 I could not enter a single character until the series of look commands had finished. The command line was locked up completely.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I have serious trouble entering commands during large group fights because of all the spam-scrolling, but it happened in previous versions of CMUD, too.

Disabling my ATCP (not even turning off the messages or triggers, as I just unchecked the option in the preferences and didn't even restart right away) made a noticeable difference in my ability to play Lusternia. It may have been a slight coincidence, but I'm inclined to believe there may be an issue somewhere there. I know there are issues with lots of extra ATCP packets in Lusternia right now, so maybe that's the real cause (again, except for the fact that I didn't restart after disabling the option).

Wanderer Joined: 11 Mar 2002 Posts: 93

Posted: Fri Jun 27, 2008 9:22 am

Yeah - my command bar locks up in huge fights as well, and I don't use ATCP. *sigh* It is rather annoying, and without "Required System Specs" to run CMUD, it's hard to determine if it's my low-end computer or CMUD itself.

I will say that zMUD never had this problem.

Just for kicks, here's my computer specs:

800 mhz Celeron
256 MB RAM
80 GB HDD1
20 GB HDD2
NVIDIA 128 MB Video card

*shrug*

I'm glad I'm not the only one dealing with this problem. It'd be nice to not have my command bar lock up on me just because I have 200 lines of text scrolling past me every second.

Charneus

Posted: Fri Jun 27, 2008 5:05 pm

If someone can point me to a relatively safe way to reproduce this with a new character on a MUD, then I might be able to test it. However, the problem is also related to the triggers and scripts that you are running. The more scripts that you have running at a time, the slower the response will probably be. You might try turning off the option in the Preferences called "Use threads for command line" to see if that helps.

Nothing that was changed from 2.28 to 2.29 should have effected this. So I'd really need some more definitive evidence that 2.29 caused this to get worse so that I could look at the specific changes made in 2.29.

Unfortunately, the MUD that I play doesn't spam that much (Aardwolf). Even if I speedwalk a long path I don't see any problems with the command line speed. Nor does it lock up during combat.

I'm not sure I can see how ATCP would have any effect if the triggers for it are disabled. If you don't have any triggers and you don't have the mapper open, then ATCP messages are just stripped and ignored. If the mapper is open, then several ATCP messages will be sending #TAG commands to the mapper, but even that shouldn't be causing this kind of problem.

But it sounds like I'll need a test package and a test character on Lusternia to reproduce this. I don't have any characters on that MUD and have never played it, so I'll need good instructions on what to do to try and reproduce it. If I can reproduce this when Delphi is running, then I might be able to pin down where the problem is.

Also, as usual you can run the Script Debugger to see exactly what scripts are running and how long they are all taking. That might help pin down the script that is causing the most slowdown.

Specific advise for Charneus: The 256 MB of RAM is going to be a big part of the problem. Even Windows XP is going to run really slow with only 256 MB of RAM. Memory is really cheap these days...going to 512 MB will be dirt cheap and easy and you'll see a huge speed improvement in Windows from that. Yeah, the 800mhz processor will ultimately be the limit, but adding more RAM should still help a *lot*.

Solaras: I'll try the "#50 look" test myself to see if I can reproduce it with that simple command.

Posted: Fri Jun 27, 2008 8:57 pm

Posted: Fri Jun 27, 2008 11:56 pm

It's quite ironic that you need to spend more money to be able to spend less money Confused

Posted: Sat Jun 28, 2008 5:33 am

Hmm, I should look in my storage room in some of my boxes. I probably still have some old SDRAM laying around from some old computers. I never throw that stuff away. Email me more details on the speed and number of pins and any other information that might help and I'll see what I can do. I'm certainly never going to use it for anything.

Btw: Did you try turning off the "Command line uses threads" preference option?

Posted: Sat Jun 28, 2008 7:07 am

Email sent.

Also, I tried turning off the "Command line uses threads" option, and it did nothing except cause CMUD's RAM usage to skyrocket from 25MB to 75MB. Not to mention my command line was still locked up.

I know I've got a lot in my package, and I'm actually wondering if half of it could be eliminated for that matter - or rather, condensed. I've used a lot of gag triggers, and wound up making a gag database so I wouldn't have to make a trigger each time. I'm still trying to find ways to clear my triggers. I've wound up dropping them down from 388 to 204 (simply by using regexes), but wouldn't mind getting them even lower! :P

Charneus

Posted: Tue Jul 01, 2008 10:51 pm

Still have not reproduced this. On Aardwolf I did a "#100 look" and while all of the text was spamming my screen, I was able to type on the command line without any problems. I have a Prompt trigger that extracts the hp, mana, etc and puts them into gauges, and I have about 50 active triggers that gag various lines and moves the ascii map information into a separate capture window.

Of course, my computer is pretty fast. So if it's an issue with a really slow computer, it's going to be hard for me to determine the problem. But if anyone else has any way to show this problem, please post details.

Charneus: received your email and will take a look at what ram I've got and let you know.

Posted: Tue Jul 01, 2008 10:55 pm

Btw, something else to try...

CMUD uses a completely different command line component than zMUD. The CMUD command line is a 3rd party rich text control (zMUD used the standard Microsoft rich text control, which had various problems with it, like not being able to set the highlight color). One of the things I've noticed about the 3rd party rich text control in some other applications is that it only seems to repaint itself when the system is "idle" (a complex detection done by the Windows message loop routines).

So, I'm curious as to whether it's just a problem with the command line updating itself or not. So what I want you to do the next time this happens is go ahead and typeahead a command and press Enter without waiting for the command line to echo your text. Then, look in your Script Debugger output to see when the command was sent.

Posted: Tue Jul 01, 2008 11:05 pm

Also keep in mind that if you have any loops in your scripts, CMUD gives priority to those loops and is blocking any other Windows messages during those loops (to prevent other lines from the MUD from being displayed in the middle of a loop). Blocking network input during loops also blocks any other windows input, such as mouse and keyboard input. So it might heavily depend upon exact what scripts are running (which you can see in the Script Debugger output).

Apprentice Joined: 11 Aug 2006 Posts: 100

I am experience this very annoying issue as well.

Due to a bug in 2.18-2.20, I stuck with 1.34 for longer than most. I did not notice this issue untill I upgraded from 1.34 to 2.20+ I run multis, alot of triggers, and use the mapper. The mapper does not update during this lockup either. Also, commands typed during this lockup are entered AFTER the lockup clears, and cmud is able to catchup with the spam I do not play a mud with ATCP.

My computer is not bleeding edge, but not a slouch Athlon 64+ 4000 (2.1GHz), 2GB RAM, running Windows XP Professional SP2

Is anyone experiencing this issue using the mapper?

In my experience, there is a difference in the behavior of the mapper when comparing 1.34 to 2.20+ (please remember that I held off on the 2.X upgrade untill 2.20)With 1.34, I could run around my mud, while in "fast" walk mode, using the keypad, and the map would update very quickly. My position would be updated before my character arrived. It was quic and responsive. Now it seems sluggish, and the position marker seems to jump from my starting position to the end position. The lockup feels the same, only a larger span of rooms and time.

VERY annoying.
Sorry for the rambling post, slightly sleep deprived.

Posted: Wed Jul 02, 2008 8:24 pm

As I mentioned above, please use the Script Debugger window to determine what script CMUD is running during the "lock up". This problem is VERY dependent upon your exact scripts that are running and without more details, this problem will be impossible to fix.

If the keyboard/command line isn't responding, then nothing else (like the mapper, etc) is going to respond either. If the keyboard is blocked, then that means Windows messages are being blocked somewhere, so no other window is going to be able to respond during the lockup. So it doesn't matter about the mapper. And it doesn't really help to say that this worked fine in v1.34 because thousands of changes have been made since then.

What I need is for someone with patience who can make this problem happen easily to start disabling parts of their triggers and scripts to pinpoint exactly what script is causing the problem.

Also, everyone with this problem should also be sure to try turning off the "Use threads for command line" preference to see if that makes any difference. Turning off this option turns off the usage of threads in CMUD, which was the major design change between v1.x and v2.x.

Apprentice Joined: 11 Aug 2006 Posts: 100

"Use threads for command line" makes no difference.

While I do not have alot of time to play with CMUD, I will try to narrow it down to a single problem script.
I have already found which package causes this to happen.

Apprentice Joined: 11 Aug 2006 Posts: 100

I was never able to take the time and narrow it down to one setting, but this problem has disappeared. I am using 2.33.

Very Happy