Zugg Software :: View topic

Wanderer Joined: 21 Jan 2008 Posts: 62

For some reason or another, my command line becomes extremely unresponsive, with about one keystroke per .75 seconds or so response time.

This usually happens after leaving cmud in the background for some time and coming back to it...

activity from the mud, (receiving) is not impaired.

i can send macros / speedwalk aliases and they go quite fast (AFTER they leave the command line...) but say if i'm typing on command line and hit a macro to 'look' the 'look' will be delayed until command line has caught up.

In the end this makes the cmud session unusable.

Close cmud / reopen temporarily resolves the problem until it creeps back up...

Vista, Core2Duo 2.4ghz, 4 gb ram.

I've not been playing muds much at all lately, but I think this has only cropped up on version 3.12 and I don't recall seeing it before then.

~A

Wanderer Joined: 21 Jan 2008 Posts: 62

hrmm... this seems to happen 99% after having locked windows... much like the past problem
http://forums.zuggsoft.com/forums/viewtopic.php?p=151339

(However I no longer have the ctrl-f crashes like I had before.)

Wanderer Joined: 21 Jan 2008 Posts: 62

This extreme laggy / slowness seems to always show up immediately after coming back from a locked windows state.

Today I also noticed that it started directly after doing a ctrl-f find for searching text.

Wanderer Joined: 21 Jan 2008 Posts: 62

hitting ctrl-t bringing up the 'trigger wizard' also kicks my cmud into 'extremely laggy mode'.

Just tried this on both muds I play ** completely different packages/config files.

able to be reproduced on both.

The mud with the most settings / triggers / alias seems to have slower response than mud that only has a scant few.

However both are noticeably lagged, specifically on the command line (( typing in text )), if not more.

Posted: Tue Jan 05, 2010 5:34 pm

Not sure what to suggest on this as I cannot reproduce any of this. I've never been able to actually reproduce the issues with the Windows Lock feature myself and we've never really determined what was causing the problem. It's definitely something related to your specific computer, but I don't really have any idea what it might be. All I can suggest is the standard stuff like making sure you have the latest Windows updates, and the latest driver for your video card and stuff like that. Vista just has so many issues that it's hard to tell what might be causing it.

You might try creating a new, blank session and see if that still shows the problem. If it works with a blank session, then you can start importing your triggers and scripts to see if one of them is causing a problem. Each time you press a key on the keyboard, CMUD searches for Macro settings, so maybe you have some corrupted Macro that is causing problems. I don't see how this would be connected to the Ctrl-F or Ctrl-T screens, but it would be good to start in a clean session first to see if the problem is with your computer or with your session scripts.

Wanderer Joined: 21 Jan 2008 Posts: 62

Did some more testing.

Started brand new blank pkg.

Ran super fast, ctrl-t ctrl-f remained running fast.

closed, reopened, rinsed repeated,

still running fast.

Opened 'broken' mud setting (mud#2, with very little settings).. poke around there for awhile.. 'closed' my session (instead of cmud completely, like I normally do)... Opened testPKG (the previously brand new empty one)...
it ran in 'super laggy mode'.

closed cmud,

reopened testPKG. ctrl-F. ctrl-T.
'Super laggy mode' is back.

testPKG still contains zero settings, not even autologin scripts.

One thing I did notice... which I was unsure was related, but appears it could be now. My 2 broken mud's take about 25-45 seconds to actually 'startup' (after double clicking their icons). It is something that had gotten really frustrating as of late.

Anyway, Before testPKG broke, it took less than 1 second to establish the connection. (startup)
After testPKG broke, it took about 20-25 seconds.

To me, this appears related.

Posted: Tue Jan 05, 2010 6:49 pm

Yes, I would say that is definitely related. No package should take 25-45 seconds to load. I mean, sure, it will depend upon your computer. But I've got some pretty large packages and they load in less than 10 seconds. Something is definitely seriously wrong with your packages. My guess is that your testPKG isn't really empty but is corrupted somehow. I suggest deleting it and creating a new package from scratch. If you come up with a procedure for creating a new blank package that reproduces the laggy results, then post the step-by-step procedure on how to reproduce it from a blank session or fresh install.

Wanderer Joined: 21 Jan 2008 Posts: 62

Well, I completely uninstalled / reinstalled cmud (fresh) (( after exporting to xml my main mud's package )).

So far, most is well. Speeds are normal.

on an unrelated note... When I created this new package, I named it something different than my last one.

So when I imported the XML it created 2 other packages with names I previously Used.

I had copied everything out of my 'ZT' package to my new, 'Z' package, and went to delete the 'ZT' package (empty) and each and every time I tried to do it it crashed cmud. (( close / 'continue' )).

I tried closing it like 4-5 times to try to get the package deleted other ways, but eventually clicked 'continue' and then immediately closed cmud and reopened (package is gone now).

Not sure why it was doing that...

Posted: Tue Jan 05, 2010 8:03 pm

Not sure, but that just reinforces my idea that the supposedly empty ZT package wasn't really empty and was corrupted in some way. When you delete a package, CMUD has to go through memory and delete anything in the memory tables for that package. If settings were deleted in the database, but not in memory, then the memory pointers could be pointing to unknown memory and can cause crashes when CMUD tries to remove the memory settings.

As I said, if you can come up with a procedure to reproduce this problem with fresh packages, then I can look into it more. But it's more likely something specific to the packages you were working with.