Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD Beta Forum
gamesover
Novice


Joined: 06 Jun 2007
Posts: 30

PostPosted: Tue Apr 27, 2010 2:08 am   

CMUD/ZMUD is powerful but unstable
 
Zugg, thanks for your artworks of CMUD/ZMUD seriers software.

It is really amazing software with excellect powerful function. However, I have one suggestion. Please pay much more attention to CMUD's stable/robustness.

When opening 4-5 sessions or running one session a little long time, CMUD/ZMUD is very very easier to be crashed. That's why so many of my firends start to use Mush, even Mush is much more complex than CMUD.

All of us admit that Mush is not easy to use and need a lot of programming basis by Lua language compared to CMUD. But Mush has one big advantage to Zmud/Cmud. Mush is very stable/robust, I never meet Mush's crash before.

Please imaging, after taking a lot of time to one mud games with a lot of settings, one day, CMUD crashed and every setting is gone. What an awful day:(
Reply with quote
GeneralStonewall
Magician


Joined: 02 Feb 2004
Posts: 364
Location: USA

PostPosted: Tue Apr 27, 2010 2:29 am   
 
When was the last time you used Cmud? I'd say the latest (beta) versions are very stable.

On the note of losing all your settings, I wrote something a while ago that may help. It's a simple .bat script that backups -all- of your packages and saves them in a separate directory, organized by date and time. Normally cmud's automated backups are enough to save you, but this is more or less a fool-proof solution: http://forums.zuggsoft.com/forums/viewtopic.php?p=152493
Reply with quote
gamesover
Novice


Joined: 06 Jun 2007
Posts: 30

PostPosted: Tue Apr 27, 2010 2:57 am   
 
I am using 2.37pro cmud now. Basically speaking, every version of Zmud/Cmud has robustness issue, more or less. The most stable version I've used is zmud 4.62 version.

Till today, Zmud/CMUD is very powerful with excellenct function. But, it seems you did not solve or improve its robustness issue. It always crash time from time. I understand probably it has ways to save the data from its crash. However, what I expect is that CMUD won't crash, instead of saving the data after crashing.

To be frank, most of my mud's players are programmers. They can use any kind of language to code, to use Lua, JSP, XML or other language is not an issue to them. But, robustness is an issue to them. They are very smart and they can reslove any programming issue but they cannot slove robustness issue.

For example, in cmud, I only need one simple command #wait to wait some time, #capture to open an new window. But in mush, you have to code tens of hundreds of lines to acommplish the same function by Lua language.

I try to focus that Mush only has one advandage to CMUD, strong robustness. But this advantage has already beat CMUD's everything else.
Reply with quote
charneus
Wizard


Joined: 19 Jun 2005
Posts: 1876
Location: California

PostPosted: Tue Apr 27, 2010 3:36 am   
 
While the public version may seem unstable, the Beta versions have fixed many of the bugs in that were present in 2.37.

Hopefully, there will be a public release soon, but if you feel like helping test for bugs in the Beta versions, feel free to download it. Just remember that Beta versions, while they may be a bit more stable, the goal is to actually TEST them for other bugs so that Zugg can release a public release sooner.

Charneus
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Tue Apr 27, 2010 4:27 pm   
 
The biggest cause of stability issues in CMUD is importing badly written zMUD scripts or zMUD scripts that have not been properly updated for CMUD. If you are importing zMUD scripts, be sure to run the Compatibility Report to find potential issues. If you have stability problems with a specific script, then post the specific script so we can help.

As you mentioned, CMUD is a *very* complex program. Because it's basically a programming language, you can do almost anything you want with it. That makes it impossible to debug issues without specific scripts that show the problems. It is possible to make *any* program crash when it includes a full programming language, even Mush.

Quote:
CMUD crashed and every setting is gone.

That is nearly impossible in CMUD. This happened a lot in zMUD, but that's why zMUD was rewritten. CMUD was designed from the ground up to make loss of your settings very difficult.

Also, think about what you are calling a "crash". In CMUD we use exception handling to proper trap problems and crashes. This allows you to click a button in the crash dump to send the details to us so we can look for common crashes happening to more than one player. However, you'll notice that the crash dump also has a "Continue Application" button that generally allows you to continue with CMUD, then get to a good spot to exit and then restart CMUD without any data loss.

Some other programs trap these errors and do not show a crash dump. They simply continue running the application, just like if you click Continue Application. By not displaying an error message, this can make some programs *seem* more stable. Even in zMUD many problems were trapped and ignored like that. CMUD took the alternative approach and reports every possible problem with the crash-dump/bug-report popup. Very few applications are brave enough to report every possible exception and allow you to send the crash dumps somewhere where they are actually used.

Stability is one of my highest priorities in CMUD. As people have said, the Beta version of CMUD is more stable than the current 2.37 Public version. And the 2.37 Public version is far more stable than any version of zMUD. And as others have also said, the only way to improve the stability is to provide specific bug reports or show us the specific scripts that are causing problems.

I personally use CMUD with many different windows and packages for extended periods of time on Aardwolf without any crashes at all. So for me it is very stable.
Reply with quote
killergate
Novice


Joined: 16 Feb 2009
Posts: 38

PostPosted: Tue Apr 27, 2010 10:36 pm   
 
Hi,

I'll just report that losing settings and window-layouts etc. has occured several times with both stable and beta versions of CMUD for me and friends of me.

/kg
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Tue Apr 27, 2010 11:15 pm   
 
Losing a window layout is not the same as losing settings (scripts). Settings/Scripts are stored in a database that is transaction processed. It is extremely difficult to lose settings from this database. While it is possible and some people have reported it in the past, no reliable way to track this down was ever reported, and I haven't seen any reports from recent Beta versions.

The window layout corruption was a common problem in the Public version because of how the command line was handled. It was very easy to accidentally drag/drop the command line and mess up the layout. The window layout is stored in a flat text file (*.xly) and can easily be corrupted if the layout is saved after getting a severe error elsewhere in CMUD that corrupts memory.

This problem has been greatly reduced in the recent beta versions because of the changes made to the command line.

So, issues with window layouts and settings are completely different. And if you are still experiencing any problems like this in the latest beta version, then you need to post details on the problem and when it occurred so that I can look at your files to determine the cause.

But just saying that "some version in the past" lost some settings without more details is not helpful to anybody.
Reply with quote
Fizban1216
Apprentice


Joined: 03 Feb 2007
Posts: 170

PostPosted: Tue Apr 27, 2010 11:59 pm   
 
As charneus already stated the beta version 3.16 is far more stable than 2.37 despite it being counter-intuitive (no one expects a beta release to be more stable than an official release).
Reply with quote
killergate
Novice


Joined: 16 Feb 2009
Posts: 38

PostPosted: Wed Apr 28, 2010 7:07 am   
 
Hi,

I've only had window-layout issues with the 3.12+ betas (dunno about latest, as I downgraded because of the keypad-issue), a friend of mine lost all scripts with the 2.37 stable version. And as this is not occuring every now and then, its extremely had to post anything about.

/kg
Reply with quote
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: Thu Apr 29, 2010 6:41 pm   
 
I still continue to get occasional exceptions/crashes even years after having converted my code from Zmud. But I have never lost my settings. I've had them slightly corrupted due to a bug that is now fixed, but never lost.

Zugg will perhaps understand that the fact that 'He' doesn't experience any crashes is small comfort for those of us that experience them on a regular basis. Of course I understand that being the owner of the code has its perks, one of which is that you've probably long ago fixed the bugs that would affect your code.

You mention here about how you can submit crash reports, but you've stated in other threads that the vast majority of these reports can't be acted upon. And that unless there are quite a few with similar characteristics, they aren't acted upon because of the time and extra information that would be needed.

I personally have submitted quite a few from my crashes and I have yet to personally see any difference from submitting them.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Thu Apr 29, 2010 8:02 pm   
 
Quote:
Zugg will perhaps understand that the fact that 'He' doesn't experience any crashes is small comfort for those of us that experience them on a regular basis.

Come on. All I am saying is that if I don't see the problem here, then I cannot correct it. Without a procedure for reproducing a bug, there is no way for me to magically fix the problem.
Quote:
You mention here about how you can submit crash reports, but you've stated in other threads that the vast majority of these reports can't be acted upon.

Where did I say that? Most reports cannot be acted upon because they do not include any comments to tell me how to reproduce the problem. Again, I can't read people's minds nor do I have some sort of magic wand that I can simply wave to fix a bug. Yes, a crash dump without an explanation of how it occurred just gets dumped into the database and is only used if other people report the same bug. But crash dumps with a procedure to reproduce it go into my bug database and get fixed. And a single isolated crash dump gets a lower priority than a crash that is reported by many people. The crash dump system uses a CRC hash of the stack dump so that I can group multiple reports that point to the same spot in the code. That is how I determine crash priority...based upon how many people are reporting the same issue.
Quote:
I personally have submitted quite a few from my crashes and I have yet to personally see any difference from submitting them.

OK ReedN, now you are just pissing me off. I have fixed *dozens* of bugs that you *personally* reported. In many cases you were the only one experiencing the problem. Do you really have such a short memory and such little appreciation of what I have done for you in the past?

Just goes to show that there is no way to please everybody. No matter what I do, some people will whine and complain. I'd bet thousands of dollars that even if every last bug in CMUD was completely fixed that some people would still call it "unstable" and continue to pass misinformation.
Reply with quote
wrym
Magician


Joined: 06 Jul 2007
Posts: 349
Location: The big palace, My own lil world

PostPosted: Fri Apr 30, 2010 1:14 am   
 
There are always 2 sides to every story.

Is it possible that some users experience a constant stream of error messages, while others have seamless performance? Yeah.
Can bugs be a pain in the rear to track down and fix, even with detailed reproduceable error reports, and forum posts? Most definitely.
Does Zugg's bug list have hundreds if not thousands of bugs, errors, and other oddity? probably.
Does each of them takes time to reproduce, track down and fix? I'm fairly sure it does.
Do I have bugs I wish were fixed? Everyone does.
Have I see mine and others bugs fixed? Many many MANY times.

That being said, there is rather significant difference between error handling/reporting, and crashes, Cmud's error handling/reporting is NOT very common, the only time firefox or opera and many other programs show an error is when they completely screw up. i'm not sure most people understand the difference, or even care. I'm fairly sure that some of the "buggy unstable" rumors are because of this. I have even caught my self swearing at cmud over an annoying report or two.

I know it was talked about in another thread to automatically trap and handle many of the docking system errors, maybe thats not a bad idea, maybe even expanding it, and add an option for MINOR errors to automatically handle them or post a report.

anyway, just my 2 cents.
_________________
"To the engineer, all matter in the universe can be placed into one of two categories: (1) things that need to be fixed, and (2) things that will need to be fixed after you've had a few minutes to play with them" - Scott Adams, The Dilbert Principle
Reply with quote
Dumas
Enchanter


Joined: 11 Feb 2003
Posts: 511
Location: USA

PostPosted: Fri Apr 30, 2010 1:31 am   
 
I read the OP, and the first thought in my mind was "Zugg basher". I don't know why, but when you make a post just to comment on an issue and then immediately talk about how great another similar product is, you aren't providing any useful conversation.

It would be like going to a Microsoft forum and stating how Windows always crashes but Mac OS doesn't.

I find that the reason most people experience slowdowns/crashes/etc tends to be that they run very complex systems. And in the same sense that a complex program like CMUD may contain some performance issues or bugs, these complex systems do to. I personally have had very few instances of CMUD crashing no matter how long I've been playing, and they few times I have it was typically soon after an update and it was a common bug that others also reported.
Reply with quote
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: Fri Apr 30, 2010 1:40 am   
 
I freely acknowledge that you've fixed many bugs that I've reported. However, I wasn't talking about those, because those were by and large not bugs that randomly crashed the system and this topic is about bugs crashing the system. Regardless of how many of the non-crash bugs I report on and are fixed, I still see crashes from time to time. As they happen randomly there is nothing I can do about giving a repeatable procedure.

The portion of my post which really seemed to rile you up is factually accurate despite all the other bugs that you have graciously fixed. I have submitted dozens of these random crashes as crash reports (albeit without a procedure as noted above), and I still see the same crashes happening in newest versions of CMud.

So I don't quite understand what pisses you off about that statement. I hope you aren't saying that just because you've fixed bugs I've reported in the past I have some obligation based on gratitude to be silent about the crashes I still routinely experience. If it's a matter of time spend on the bugs I have many examples of bugs I've spent 10+ hours on each. So in terms of total time spent on 'my' personal bugs, I'm pretty sure I have you beat.

This topic is about random bugs that crash CMud. Everyone is responding to the guy like he's an anomaly to be experiencing this because its so stable for everyone else. I thought it very relevant to the topic that I too see this random crashing (albeit without the loss of settings). I'm happy for those that have found themselves in a position in which they never get Cmud crashes. I am unfortunately not one of those people. Why the vehemence when post that I see crashes just like this guy? These aren't rumors of crashes and instability, I see them with my own eyes first hand. Nobody is telling me via misinformation that Cmud crashes a lot, I see it myself.

Perhaps you are correct, and I am an ungrateful whiner because I posted in a topic about crashes that I too see this same crashing. Or perhaps I crossed the line when I pointed out that submitting crash reports most likely will not result in the cause of the crash being fixed.

Whatever arbitrary line I crossed, my apologies.
Reply with quote
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: Fri Apr 30, 2010 2:43 am   
 
wrym wrote:

That being said, there is rather significant difference between error handling/reporting, and crashes, Cmud's error handling/reporting is NOT very common, the only time firefox or opera and many other programs show an error is when they completely screw up. i'm not sure most people understand the difference, or even care. I'm fairly sure that some of the "buggy unstable" rumors are because of this. I have even caught my self swearing at cmud over an annoying report or two.

For my part I'd like Cmud to continue if it can and not pop anything up. In various situations having that crash pop up will cause death in the Mud and many hours of work to restore the lost experience. The error is also phrased like if you continue you might hash your data because things are unstable. For me at least that has ensured that every time it pops up I close Cmud regardless of whether it can continue or not. I'm not willing to risk all my scripts being screwed up just so I can continue after the error.

Dumas wrote:
I read the OP, and the first thought in my mind was "Zugg basher". I don't know why, but when you make a post just to comment on an issue and then immediately talk about how great another similar product is, you aren't providing any useful conversation.

I honestly took it the opposite way. Perhaps because I'm approaching it from the perspective of someone who has the same crashes. To me it seemed like a plea for the issue to be taken seriously....
Reply with quote
Rahab
Wizard


Joined: 22 Mar 2007
Posts: 2320

PostPosted: Fri Apr 30, 2010 2:27 pm   
 
I believe the problem is this sentence:
Quote:
I personally have submitted quite a few from my crashes and I have yet to personally see any difference from submitting them.

It gives the completely inaccurate impression that none of the bug reports you have ever reported have gotten fixed. The average reader will not understand that you are only talking about some of your random crashes, when you did not have enough information to provide a method of reproducing the problem, not all of your bug reports. It is not even accurate to say that none of your crash reports have been fixed, so this statement cannot be completely "factually correct", as you claim. I believe that some of your crash reports that _were_ reproducible have been fixed.
Reply with quote
Taz
GURU


Joined: 28 Sep 2000
Posts: 1395
Location: United Kingdom

PostPosted: Fri Apr 30, 2010 4:51 pm   
 
ReedN wrote:
For my part I'd like Cmud to continue if it can and not pop anything up. In various situations having that crash pop up will cause death in the Mud and many hours of work to restore the lost experience.
The crash report module can allow the program to continue but the thing is it shouldn't, the reason the crash report has happened is because an illegal operation has occurred most likely referencing an incorrect memory location which is not good. The alternative to not displaying the crash report would be to automatically close the program which is exactly what would happen if the crash module was not included in the program in the first place.

ReedN wrote:
The error is also phrased like if you continue you might hash your data because things are unstable. For me at least that has ensured that every time it pops up I close Cmud regardless of whether it can continue or not. I'm not willing to risk all my scripts being screwed up just so I can continue after the error.
Absolutely correct this is exactly what you should do once you get the pop up. Zugg has been very agreeable in allowing the continue button to be enabled. I personally wouldn't have the continue button enabled the program would close as soon as the crash report was submitted or closed.
_________________
Taz :)
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Fri Apr 30, 2010 5:27 pm   
 
Quote:
For my part I'd like Cmud to continue if it can and not pop anything up.

And then I'd never know that there was a problem that needs to be fixed. Clicking the Continue button really doesn't take that long, and death on a MUD is unfortunately a fact of the game regardless of whether you get a popup in CMUD, or a popup in Windows, or somebody distracts you in person, or whether you just typed something incorrectly or not fast enough.
Quote:
I have submitted dozens of these random crashes as crash reports (albeit without a procedure as noted above)

Exactly. And it's good that you submitted these. But without a procedure, then these reports are just statistics without any way for me to reproduce them. Only when these statistics show that multiple people are experiencing the same crash does it rise in priority in my bug list. As I said, the crash dumps use a CRC algorithm so if multiple people are getting the same crash from the same spot in CMUD, then they get counted and raised in priority. If something you reported didn't get fixed, then it's usually an indication that you are the only one getting that specific crash, which usually means it's related to something very specific about your scripts and settings.

Or it just indicates that I have hundreds of issues on the list and can't possibly fix every problem that is reported.

If you are consistently getting the same crash across multiple versions of CMUD, then it is your responsibility as a Beta Tester to try and mess around with your scripts to try and track down the cause of the crash. Maybe it's a problem in your own script that you can fix. Maybe fixing the problem in your script will actually make your script faster or better? If it's not something you can fix in your script, then maybe you'll come up with a way to reproduce it so it can be fixed. But just blindly clicking "Send bug report" or "Continue application" when you get the same crash across multiple versions of CMUD isn't Beta Testing.
Quote:
I hope you aren't saying that just because you've fixed bugs I've reported in the past I have some obligation based on gratitude to be silent about the crashes I still routinely experience.

Of course not. Don't be silent about them. Feel free to click "Send bug report" so I can continue to gather statistics. But unless you include a procedure to reproduce the issue or more details about it, then it's just a statistic and nothing more. There is no way for the crash dump system to "connect" a crash in Version 123 with the same crash in Version 456. The CRC values are usually different between different versions. So I'll have no way to know if there is a single bug that you are reporting again in each version of if it's different bugs unless you tell me in your comments.

And if you "routinely experience" these problems, there is no reason for you to not come up with a procedure for them. Again, that's the purpose of Beta Testers. If it is some random "only happens every few weeks" kind of problem that is impossible to track down, then I completely understand that all you can do is report the crash without any additional information. But if it's something you "routinely experience" then that sounds different.

Want to know the most common "comments" I get attached to crash dumps?

"Closing CMUD"
"Playing my mud"

Yeah, like those kind of comments are really going to help me at all.

As far as statistics go, since the command line was removed from the Layout and fixed to the bottom of the session window, the crash dumps have dropped by 80%. So I think that is at least some evidence that I am trying to fix the most common stability problems.

When I look at the old crash dumps that have gone away, they all had different CRC values, but were all related in some way to the 3rd party window or toolbar docking components. I couldn't reproduce them myself and they were usually buried very deep into the 3rd party code. So while I couldn't fix the exact problem, it all pointed to some sort of issue in the docking system. The command line toolbar was the most complex part of that, so that's what caused me to change how the command line was handled, even though it meant removing some customization options from CMUD.

Imagine how the people who write the 3rd party docking system would react if I just sent them a bunch of bug reports that said "having a command line in a docked toolbar causes lots of crashes and unstability". They'd just ignore me unless I provided them a way to reproduce the problem.

Bottom Line
The bottom line of all of this discussion is that I'm doing the best that I can. I certainly don't "ignore bug reports" and stability is always very high on my list. But I am balancing a *lot* of different needs and priorities. If you think you can do better, then feel free. If you want to be constructive and actually help instead of just complaining, then join the Beta Testing and spend time trying to track down the crashes.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD Beta Forum All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net