Zugg Software :: View topic

Magician Joined: 23 Jul 2005 Posts: 334 Location: Chicago

well... as time goes on, i am adding more and more triggers. i've got it narrowed down TO the triggers, but to go thru and enable and disable ALL triggers... grrrrrrr.... below is a screenshot of how it looks. i can click on the window, and it refereshes it and it goes away. my auto refresh time is set to 3 seconds (any lower and it becomes 'laggy'). any help in this would be GREATLY appreciated as this is just really annoying the (insert bad word) outta me.... thanks in advance everyone!!!

Posted: Thu Jul 03, 2008 7:16 pm

As you said, it depends upon the exact triggers that you have. I'm not sure anyone is going to be able to help without using your triggers. You might want to drag them into different class folders so that you can enable/disable entire class folders at once to make it a bit quicker to track down. My guess is that it is a combination of #SUB or #PSUB triggers. But I'd love to fix this if you can narrow it down to something I can test here.

Posted: Fri Jul 04, 2008 1:10 am

from time to time iIhave had very similar situation with my main mud window. from what I can tell I don't think it has to do with triggers, 99% sure infact. because of several observations i've noticed:

1) greater tendancy to shift at an unmatched > } or )
2) i've had this happen in a sessions with less than 2 dozen settings, mostly aliases, a few varibles and 2-3 triggers, no sub/psub
3) large scroll back buffers seem to increase the chance, I was running with a buffer of 100k, but I dropped down to 10k lines and now rarely if ever experience this problem.

and it always clears up for my by page up page down, page down, or sometimes just clicking in that window

hope this helps and doesn't muddy the waters anymore.

Magician Joined: 23 Jul 2005 Posts: 334 Location: Chicago

Huh... After rebooting, and starting cMUD again, I'm not see'n that. I'm liking the buffer fix. I had mine at 1000000, and drop'd it down to 100000, and if I see it appear again, I"m going to drop it down to 10000 and so on and so forth. Thanks Wrym. That might be it... LoL!

Posted: Fri Jul 04, 2008 4:38 am

hahahah 1kk lines of scrollbuffer, my excessive 100k lines doesn't seem so bad now. I'm just too lazy to open a log file to check stuff... too addicted to #scroll.... It has still happend for me with 10k lines but very rarely. Even with 100k lines it takes me several hours to fill that up and then I don't get this problem right away. If that fixes you thats great, but I think a bugg still exists in there....

Zugg, is there a limit of some sort we should be paying attention to on the scroll buffer?

Magician Joined: 23 Jul 2005 Posts: 334 Location: Chicago

well, dropped it down again. it came back again this morning. definatly seems to be a bug when the buffer max's and its set so large. *shrug* if its available, figure why not, right? that and i like to scroll back at any time, and see what happened. either that, or if there was a good logger.... that'd work for me too, and i wouldn't need the huge scrollback. *tear8

Posted: Fri Jul 04, 2008 4:00 pm

There is a good logger. It's already built in. :P Preferences -> Session -> Logging and choose your options. Then just type #LOG filename.txt on the command line. :P

Charneus

Magician Joined: 23 Jul 2005 Posts: 334 Location: Chicago

hrmmm... cannot i do a "#log LOG-%date.txt" ?? And just have that onConnect or something to start logging everything?

Posted: Fri Jul 04, 2008 5:38 pm

Well, %date isn't a valid function.

#LOG %concat("Log-",%time("mm/dd/yy"),".txt") should work, though. And yeah, you can do it on onConnect.

Charneus

Sorcerer Joined: 13 Jan 2006 Posts: 715

I prefer to include the MUD title in the logname.

#ALIAS onconnect {#LOG %concat(%title, "-", %time("mm/dd/yyyy"), ".log")}

This also saves it as a proper textual log file.

Magician Joined: 23 Jul 2005 Posts: 334 Location: Chicago

well... i've got the buffer down to 5000... gonna knock it down to 1k but, i REALLY don't wanna go any lower. zugg, this gonna be a fix in the next release? or, is there something i can give ya to recreate this issue, cuz its really frustrating...

Posted: Mon Jul 07, 2008 7:56 pm

I've still never been able to reproduce this bug. So no, it's not going to get fixed anytime soon unless I can find a way to make it happen here.

How much memory do you have on your computer? You definitely shouldn't set the scrollback lines too high since I don't know what happens when Windows starts to run out of memory. But that's the only limit to the scrollback lines setting. You might want to monitor the CMUD memory usage from the Windows task manager to see how high it is getting when you see the problem.

Magician Joined: 23 Jul 2005 Posts: 334 Location: Chicago

i'll check the memory usage tomorrow. i've noticed, that after i restart it, its fine, or the next day, coming back (and the laptop goes into hibernation) its fine. but it seems to build up over time. as far as memory, i've got 2GB, and i'm down to only 5000 lines in the scrollback. =[ could it be a problem with the mud that i play? i never had this issue with zmud and my mud...

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

I have definately experienced this before but I don't recall what caused it, probably excessive use of Alt+Tab while receiving over a page of text... this is an old bug, it was in zMUD too. It never really worried me because when you clicked the window, the buffer fixed itself.

What event do you run "on click" of the buffer do you repaint the screen? Maybe it's something obscure like when a MSN window has popped over that portion of screen then it doesn't get the invalidate message for that section of screen so it thinks it's still OK and doesn't paint the area and when it fades out it doesn't get sent a repaint message because it 'faded'... something odd like that.

In that vein - if it is a repaint problem - perhaps if you create an option to "paint entire window when asked to repaint a region" rather than just the invalidated region we would be able to see anecdotally if the display corruption would just "go away"... and if it did, you could possibly look at reasons why the region wasn't being invalidated/painted properly at a later date, or just put the option on by default if it doesn't take too much extra overhead.

I personally don't believe it has anything to do with scrollback size except for a coincidental "because there's more in the buffer, it takes a few extra milliseconds to paint which increases the chance of it occuring slightly". I always ran with 10k lines in my buffer.

Magician Joined: 23 Jul 2005 Posts: 334 Location: Chicago

there is two instances of cMUD.exe is that normal? pid 2924 is using 139000k with a peak of 140000k vm size of 155000k and paged pool of 156k, pid 3240 is using 2000k with a peak of 2600k vm size of 9000k, paged pool of 101k

i don't ever use alt+tab, but i do alot of other windowed workings, if you will. however, tonight, only other window i've had up has been ie7. its weird because its not the full main window thats getting messed up, but just a small section on the screen.

also, i'm down to 1000 lines... =[

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

Is the "messed up" part of the screen in any way aligned with IE7? If you move IE7 a little to the left does the messed up region get bigger/smaller?

Alt+Tab is just a short cut for clicking on another program, so when I say Alt+Tab I mean using a program other than CMUD at the same time as CMUD.

Posted: Tue Jul 08, 2008 4:54 pm

It is normal to have two instances of CMUD. One of them should remain small, but one of them should grow as it uses more memory to store your scrollback.

Rainchild: clicking on the window just does an Invalidate method call, which causes a new repaint of the whole screen. Normally CMUD scrolls the screen and then repaints the bottom section of new text. It calls the Windows ScrollWindowEx routine and then invalidates the new lines. Clicking on the window Invalidates the entire window. So maybe it's a problem with the ScrollWindow API somehow?

Unfortunately, with something as obscure and hard to make happen as this, it's very difficult to debug it. Windows itself is supposed to be invalidating any part of the window that had another application over it. If it was really a bug in CMUD, then you'd think that it would be pretty easy to make it happen by just moving other application windows over CMUD while CMUD is scrolling. The fact that it is so hard to reproduce makes me wonder if it's more of a Windows problem or something.

The larger scrollback doesn't have any effect on the repaint time. The repaint only looks at the lines currently on the screen and is independent of scrollback size. The scrollback is a large circular buffer, so there isn't any performance issues with making it larger. Scrolling text just involves changing the "top of screen" pointer (points to the line in the queue that is at the top of the screen). Once the scrollback is full, CMUD only reallocates new memory if the new line from the MUD is larger than the previous line that was stored in that location in the queue. If the new line is smaller, then the memory space of the queue is reused. So it's possible that there is some bug in this memory reallocation routine. But again, I've looked for it and can't find any problem.

Posted: Mon Jul 21, 2008 3:31 am

I had a little time this weekend and did some testing on the large scrollbuffer.

Started with a blank session, 1 million line scrollbuffer, and set about watching memor ussage using the reliability and performance monitor in windows vista.
Cmud started out for me at about 50mb memory allocated. after several minutes of fairly random spam generation, I noticed the first glitch in the screen update, checking the memor usage it was just over 90MB. I continued to generate more spam, sent from the mud untill cmud reached a memory usage of 190mb. At this point screen glitches were very common, I Saved the buffer and checked it's size 7.55mb. Now I realize that there is also color i'm sure several other things that are stored but, raw text to memory ballooning there is almost 1 to 20?

I then closed cmud, started second blank session, and looped 650k and echoed to the screen 51 characters + line number. I did notice occasional screen glitches but must less often because of the less random nature of the lines, after this test cmud memory usage had passed 380mb.

I have also noticed that as the scroll buffer gets larger, it takes a longer time to resize cmud/main mud window, (even to point that after 10 minutes I used taskmanager to end cmud). Not entirly sure what this is indicating besides the fact that it must be triggering some calculating on lines far in buffer and not just those in/near what needs to be displayed.

Realize that this is not gonna get fixed, don't want it fixed, can't wait for the new mapper *weee*, just wanted to post what I had found before I forgot it.

Posted: Mon Jul 21, 2008 5:40 pm

Thanks for the extra info. Did you have your triggers turned off during this, or were the triggers still on?

It takes longer to resize the MUD window because you have the Auto-Word-Wrap option enabled. So yes, CMUD has to go back through the entire scrollback buffer to resize each line to word wrap every line for the new window size.

Posted: Mon Jul 21, 2008 11:14 pm

Triggers were turned off (from command line button), in case of mud spam, or blank session in case of the cmud generated spam. As for the resizing I wasn't sure if you were starting at bottom and re-adjusting the auto word wrap untill the window was full.. tho I suppose that will leave scroll buffer unadjusted.

As for determining if this is a windows problem, I doubt cmud would have such a drastic memory usage on linux and WINE? Anyone using Linux and cmud care to test?

Adept Joined: 24 Aug 2004 Posts: 277

I don't know what's going on with this, but I've had this problem for quite some time now.

I made a video capture of it. It's 23.5megs, but it's only about 30 seconds long.

If you'd like it Zugg, please let me know.

It doesn't seem to matter with/without triggers, because I've turned them off, and it still happens.

I think it makes more of a difference with a larger scrollback buffer, mines at max and it seems to happen when it fills up. NEVER after I close/reopen CMud to correct the problem. However, I've tried clearing the scrollback, and that doesn't fix it for the current session.

It doesn't do it for any other program but CMud, not even Zmud.

Posted: Tue Oct 28, 2008 10:50 pm

A video capture isn't actually going to help me with this. It's very dependent upon the actual ANSI codes being sent by the MUD, which you can only get via the Script Debugger output.

Adept Joined: 24 Aug 2004 Posts: 277

I sent you those a long time ago. Figured with a video capture you could see how it acts.

Posted: Wed Oct 29, 2008 10:32 pm

Woot! Actually, I just tracked down this long-time problem.
There was one variable in the scrolling routine that was still allocated as a "Word" instead of an "Integer".
This was causing problems with the line count exceeded 65536.
This bug would have also been in zMUD.
Fixed for the 2.37 CMUD version.

Adept Joined: 24 Aug 2004 Posts: 277

A lot of happy mudders love you right now Zugg!