Zugg Software :: View topic

Posted: Mon Jan 29, 2007 8:24 pm

I'd like to find out what the top issues are for people who have not yet upgraded to CMUD. What are the main reasons stopping you from upgrading right now? Are you just waiting for it to be a bit more stable? Or is there a specific feature that you are waiting for? Or, do you just never plan to upgrade?

Feel free to post comments to add more specific comments.

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

I went for multiplaying fixes, though I'd put that and general stability in the same boat really.
IMHO current features need to be made stable before SSH, zApp, zChat and the mapper are introduced. That may not make sense from a business pov though.

Wizard Joined: 14 Aug 2004 Posts: 1269

From a personal perspective, Mapper bug fixes (not features) and other bug fixes related to scripts (e.g. compile problems, rather than GUI issues) are my two things. Actually I'd like to change my vote from Mapper bug fixes to General stability, I guess. Although of course I do have a registered copy of CMUD - I haven't yet converted to using it as my main client as lots of my scripts don't work. Sure, I could spend a day or so converting them and testing my workarounds to CMUD bugs/issues. But I don't have time right now, and for me, part of the point of CMUD was not to have to keep experimenting with scripts until I find a syntax that works. CMUD is not there yet IMHO. Sorry, but that is my positive feedback. I'm still excited by CMUD though.

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

CMUD works for me at the moment because I'm not playing MUDs a great deal, so I'm not relying on trusting the client to run 24 hours a day (I'd often just leave myself running on scripts overnight), and I'm also not multiplaying. I think if I was playing anywhere near as much as I was a year or two ago then I'd still have to use zMUD unfortunately - so basically echoing Seb, I'm excited about CMUD but I don't trust it not to crash (and obviously things like #ALARMs not working when CMUD doesn't have focus means it's impossible to rely on scripts).

To finish on a positive note though, zMUD already feels old in comparison to CMUD and once the bugs are out then zMUD will probably be uninstalled and CMUD will become king.

Magician Joined: 23 Nov 2004 Posts: 364

i havent converted to cmud yet, although i have bought it, simply because the mapper in its current state doesn't operate my scripts well enough because it is choppy, and some of the disabled features.

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

Oh, I didn't read that properly and voted for zapp forms, you can discount one of those votes since I've already converted to CMUD and anything you implement now isn't going to convert me any further ;)

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

I'm with Seb on this. I've purchased a license for CMUD, but I'm not yet using it as my client. I'm re-writing my scripts to work more effectively in the CMUD way of doing things, running into several little problems along the way. I voted for general stability because I think scripts and GUI bits should work as intended before moving on to other features.

Posted: Tue Jan 30, 2007 9:50 pm

I just don't have use for CMUD. ZMUD does everything I need for one, and equally importantly, CMUD won't be supported on Windows 2000 which is what I use when I'm not using linux. I've gone to some effort to get ZMUD working in linux acceptably, it does now for me, and I'm not going to screw with that again with a different client.

The only way I anticipate using Vista is as a guest OS to test things, much like XP is for me now.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

I voted for general stability. I already am using cMud for what little mudding I do these days but I do support a large number of people who are still using zmud. And I wouldn't feel comfortable telling them it would be safe to upgrade when I'm having difficulty with things like multi state triggers for example. Another big issue for turning novices loose on cMud is the lack of a pattern tester tab.

Wanderer Joined: 25 May 2006 Posts: 88

Beginner Joined: 17 Nov 2004 Posts: 12

Personally, as a codebase developer who would love to exploit more of MXP's capabilities, my priority would be certain MSP/MXP bug fixes.

One I've been able to live with, though ZMUD users suffer, and that is the URL corruption on MSP tag definitions. It prevents players from seeing each others uploaded images.

The other is MXP frame support, which appears to not work remotely like it is described in the spec. I'd love to add some features to use it, but ...

- Bo Zimmerman

SubAdmin Joined: 18 Nov 2001 Posts: 5182

My main thing is not being able to use #ADDKEY, #ADDITEM, etc. with local variables. The mapper needs to at least be completely stable, I have seen a fair number of questions that seem to indicate it isn't quite perfect; but I never got to testing it, mainly because zMapper didn't quite work right with CMud yet. My scripts in part rely on that interaction.

Posted: Wed Jan 31, 2007 8:06 pm

Vijilante: please create another post with more details on the problems with zMapper and CMUD. I'm not aware of those bugs at the moment, and even though I haven't done much testing with the mapper, it's something I'll be working on and examples of what doesn't work will help.

The issue with #ADDKEY etc and Local variables wasn't on my list because that's really an enhancement to a new feature in CMUD and not really a big issue for people upgrading from zMUD. I understand that it will be useful to better utilize local variables, and it's on the list.

The "Stability" item is getting a lot of votes, which is amusing, although not surprising. The thing about "stability" is that it isn't something specific that I can just fix. It's an ongoing issue and just improves over time. It took many years to get zMUD stable. CMUD should get stable more quickly because of the crash dump reporting. For, for example, the crash dumps from v1.24 are about 20% of the crash dumps from the previous beta versions. And it's about 2% of the crash dumps from the bad 1.13 version. I always work on fixing the most common crash dump issues in each new version, and as more people use CMUD, more problems get uncovered and fixed.

But "Stability" is not something that will suddenly get fixed in the next 1.25 version. It's something that will improve over time no matter what other features I'm working on.

So far it looks like the other priorities (other than Stability) are the mapper fixes and the multiplaying fixes. Although it would nice to get more responses to this poll from zMUD users who haven't bought CMUD yet.

Posted: Wed Jan 31, 2007 8:07 pm

bozimmerman: Please create another post topic and give me more details on the MSP and MXP problems that you are having. The more specific test cases that I can get, the quicker and easier it will be to fix those issues.

Wizard Joined: 14 Aug 2004 Posts: 1269

Zugg: I think you should interpret the results of "General stability" as "General bug fixes". In other words, also including bugs that don't cause crash dumps, or indeed any crash at all. i.e. including the wierdnesses, the scripting problems people have raised.

Posted: Wed Jan 31, 2007 11:13 pm

True, Seb. But its the same as for the Stability I mentioned... the Bug Fixes will also get done over time no matter what. The bugs on my list already have priority values assigned to them and I always try to fix as many high priority bugs in each release. So that won't change no matter what the results of this survey are. I realize that each person might have their own "favorite" bug that they might be waiting for before they switch to CMUD.

However, some of that will just be getting people to learn the new way CMUD does some things. What some people might think is a "bug" might really be a fix to a "wierdness" in zMUD.

Posted: Wed Jan 31, 2007 11:20 pm

Or be a quirk of CMUD itself that's simply different to what they expected - like the %left and %right versus %leftback and %rightback thing that was talked about a while ago. I talk to a lot of people who don't understand what packages are for too.

Posted: Thu Feb 01, 2007 2:37 am

Wanderer Joined: 25 May 2006 Posts: 88

This post is pure conjecture which is defined as 'the formation or expression of an opinion or theory without sufficient evidence for proof'

All tables are contrived and based solely on my often warped perspective.

Posted: Thu Feb 01, 2007 9:07 am

The problem with those statistics is that there's no base to them. You have no reason whatsoever for those numbers other than personal observation. If gurus, as you call them, only make up one in every five thousand users, as you suggest, then going by Zugg's previous sales statistics there are only actually 12 of them in existence. Going by forum signups (since the Finished Scripts forum and the Shared Package Database both require a forums account) there are only four or five. That's obviously ridiculous. You've also left out a key group - people who want to use those scripts created by gurus, who will be forced to upgrade if they want to continue using them after the guru has.

I also think you're way off with modules and packages being a turnoff for the "middle 15%" as you have it there. The people I speak to about packages and are confused by them fall somewhere in that group, but my response is simple: Are you intending to give any of your scripts to anyone? (answer is usually no) Then stop using packages!

But the answer isn't ALWAYS no. The fact that creating scripts for distribution is so much more accessible now (thanks to not having to jimmy your settings in with the user's by merging .mud files or through .txts which sometimes fail horrificly) means that more people are looking to distribute their scripts, simply because they can do so very easily. Not only is your 0.02% for gurus a bit small, but it's also not as clear-cut as you're implying.

While I'm on the topic of packages and people not knowing how to use them, though, I'll respond to Zugg's earlier comments about people not reading the help files. This is precisely true; it's the whole body of the problem. People in general don't know how to use help files. If they did, the people who run those Learn Microsoft Word courses would be out of a job, because the students would know that all they have to do is ask the nice friendly paperclip and question and, hey! There's an answer!

Jadedness aside, I myself didn't know there were any help files on packages until a couple of days ago. Now my response to people with questions about packages (when they say yes, they are looking to distribute their scripts, which happens more often than you'd think) is to read the help files on packages, and to read all of them. I don't think the help files need improving so much apart from having a giant text prompt when you try to File->New Package: "ARE YOU SURE YOU KNOW WHAT THIS BUTTON DOES? HAVE YOU READ THE HELP FILES ON PACKAGES?"

The only thing I can think of is that one of the key points about packages (that the module inside is an ENTIRELY DIFFERENT concept to the .pkg file of the same name) isn't contained in the first package help file, but the second, the one about copying. I can see people reading the first, going "buh?" and stopping reading there.

I suppose it's the curse that comes with packages being much more accessible than the previous method which was either "organise your .mud file right, pray, and send it off" or "export to .txt, pray, and send it off and spend six hours jiggling it when it doesn't work". With packages it's just File->New and create some settings. People are bound to click it not knowing what they're doing, and once they've created their settings across seven different packages all being interdependent and held together with duct tape and a complicated system of levers and pulleys it's incredibly hard to help them fix it without being at their workstation.

EDIT: Wow, that turned out bigger than I thought it would! Apologies for length.

EDIT2: I was thinking about this just now, and it makes me wonder just how many people are turned off by apparent bugs in CMUD that are actually them just getting things wrong. There was always a culture in zMUD (I thought) of asking someone if you were doing it right when something didn't work the way you expected. Will CMUD's users really just go OMG BUGS and drop the software entirely rather than asking like they always used to? I still seem to get the same number of people asking me questions.

Wanderer Joined: 25 May 2006 Posts: 88

Nice rant

I would like to reitterate that I did conclude my post by saying it was pure conjecture which is defined as 'the formation or expression of an opinion or theory without sufficient evidence for proof' as well as stipulate the groupings I have less affinity for.

I am not interested in packages because I will only share my code with a very select few fellow Mudders. This is because on the Mud I play most of what I code would be just cause for deletion of my characters.

I love your rant in regards to the help files and that somehow it is the Punters fault for not wanting to spend time studying them.. I'll even agree with you..

However that doesn't help sell more licences of CMUD does it..

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

In my (humble) opinion, fixing things like the local variables used together with #ADDITEM or #ADDKEY falls under the "General Stability" category. It's not an enhancement to a new feature so much as it is getting the commands to work as people feel they're intended to work. There are other scripting problems that have been pointed out as needing to be fixed, so I'm still hoping to see them corrected, if at all possible.

We're not asking for 100% stability in the next version, either. We'd just like to see bug fixes and cleanup made a priority over new features.

1. #RESET doesn't reset variables back to their default values properly.
2. #ADDITEM $var.keys blah doesn't add "blah" to my "keys" key in the variable name stored in $var (say that $var is "test" then the behavior I expect is the same as doing #ADDITEM test.keys blah), and no combination of brackets has been able to make this work for me.
3. The use of %i, %j, etc in loops when calling one loop from another, especially from one alias to another, needs to be re-thought. The variables should be treated as local to the scope in which they are created, so that an alias with a loop calling another alias with its own loop should not interfere with the values of %i, %j, etc. Right now, the only workaround I can manage is to unwind the loop and call things in long form, but that doesn't work for every situation.

All in all, I'm having great fun re-writing my zMUD scripts in whole new ways using the fun features introduced in CMUD. I'm really looking forward to having a few of the quirks worked out and some of the little bugs removed. I do appreciate the work you're doing on the software, and I apologize if I seemed to be ranting at all in this post.

Posted: Thu Feb 01, 2007 3:08 pm

Posted: Thu Feb 01, 2007 7:17 pm

Ceres: Fang covered most of the issues with your post, but I have a couple more:

Wanderer Joined: 01 Jul 2002 Posts: 81 Location: USA

I purchased CMUD because it will eventually have a new improved mapper. Until that mapper is available, I will probably keep using zMud.