Zugg Software :: View topic - Poll: What urgent problems still need to be fixed?

Posted: Sat Nov 25, 2006 3:37 am

OK, I released 1.16 tonight. It fixes a *lot* of problems. So please upgrade and start using it.

We are now about 2 weeks away from the Public Version deadline. So my question is: What critical problems still need to be fixed before the Public Version?

It is impossible to fix *all* bugs for the public version. zMUD is over 10 years old, and it still has some known bugs. There is no such thing as bug-free software that does anything non-trivial. So it's not an issue of fixing *all* bugs, it's an issue of fixing the most important and most critical bugs.

My current list of "critical" problems to be fixed are:

Buttons in settings editor are still not finished
Scripts in different languages do not work
Need to add zMUD Import Wizard to allow files from zMUD to be copied into CMUD directory and to handle putting CMUD files into My Documents/My MUDs by default.
Go through the crash dumps and identify any serious crash problems that multiple people are experiencing

Please let me know what issues you think need to be added to this list. Remember that I'm not adding any additional features (other than what I've already listed here). We are talking about bugs that prevent a large number of people from playing MUDs with CMUD.

Newbie Joined: 25 Nov 2006 Posts: 2 Location: Solvang, CA

I realize that for practical and business reasons, cMUD is not to officially be considered an upgrade to zMUD, but rather a new product. However, I would like to point out that whatever it is considered, your primary target clientele is going to be existing zMUD users...

For these reasons, your first priority (imo) should be to enable a smooth transition from zMUD to cMUD. I know since I tried to original versions of cMUD, I've spent the past 6 months or so progressively rewriting scripts to work under cMUD's new formats. After hundreds of hours of coding, I'm still nowhere near done (prior settings file consisted of about 8500 aliases, 2800 triggers, 700 vars, and 50ish multi-purpose macros).

Granted, my settings file is FAR larger than most people's... on the flip side, I am also more capable of rewriting all of the things that don't work than a lot of people, too.

For myself, I intend to upgrade to cMUD as soon as I can feel sure that the transition will be seamless and comfortable for me. From the talk I have heard from others on my MUD, I believe that this (in addition to, of course, wanting a stable release) is the general consensus amongst those who plan to make the switch.

The point? Imo, your top priority is two-fold; eliminate all actual crash bugs, especially those that can corrupt settings files, and work on anything and everything that precipitates a smooth transition for all mudders from zMUD to cMUD, up to and including comprehensive script conversion utilities. I believe you'll get the most sales (and the quickest ones) by focusing on those things first *shrug*

Posted: Sat Nov 25, 2006 7:20 am

I think your case is one of the exceptions Atreides - I'd never dream of running that many settings at once.

Regardless, I don't see how upgrading from zMUD to CMUD can be seamless, as you put it, since the whole system has been changed. The only way I can think of to solve that problem would be to have a "compatability mode" for zMUD scripts that allowed them to work in CMUD - but fact of the matter is, some of those scripts are going to be slower (thanks to CMUD's increased overhead) or even useless until you actively change them to take advantage of the new features. What would be the point of upgrading if you weren't going to do that? CMUD can't change all your syntax for you, and it can't change your scripts to use local variables and Events and all the other new features. I can't see why you'd want to upgrade at all if not to take advantage of these new features.

Newbie Joined: 25 Nov 2006 Posts: 2 Location: Solvang, CA

There's a difference between being able to slowly update your scripts to a maximized performance level, and having to totally wipe and restart. While a lot of the syntaxing will be different, most of the old commands will still exist in one form or another, and can thus be updated through things such as global replacement. However, with some of the unsupported features, to even get to the level of being able to globally replace requires that all scripts be written in a universal style of sorts.. and for most of us who steadily learned and improved as we wrote our scripts, the oldest ones look nothing like the newer ones...

That said, I realize that to hope for a totally seamless transition for most people is extreme. But zMUD has been around for a long, long time. And many of us have played the same MUDs for many years, having steadily built up our settings to our tastes over that time. Forget for the moment that I've heard many, many mudders express the above sentiment.. from a simple common sense standpoint, the majority of zMUD users don't have a clue of how use even a small percentage of the existing features (I certainly don't know everything). As exciting as the new features are, common sense dictates that most people will want to make the change only if the process is simple, and the end experience is more enjoyable for them... and again, common sense dictates that people (especially those who run scripts they didn't write and have no ability to re-write) will not find it enjoyable to lose their entire settings file...

There's an excellent shot that this sentiment is that of the minority of those who actively read the forums, because (for the most part) the forums are for the more advanced users... but for the average mudder (and that is the vast majority of the registered users)... their primary concern will be the effort to effect ratio.

Anyway... take it for what it's worth :P I personally will upgrade either within a couple of months of public release... but for the sake of the product itself, from a sales perspective... I just don't think it's wise to totally overlook the fact that many people *can't* recode their settings... be they as extreme as mine, or even as simple as a few downloaded scripts and some random triggers written by a friend.

Posted: Sat Nov 25, 2006 7:39 am

As far as compatibility, that's pretty much done. The Compatibility Report was the last feature to make conversion from zMUD easier. As I said above, the only other feature that I will be adding is an import wizard to copy your zMUD files for cases where you don't install CMUD to the same directory as zMUD.

We've had a lot of discussions on this topic over the past several months. And I think your post re-affirms what we decided.

1) You are an advanced zMUD user (8500 aliases, 2800 triggers? ouch)
2) You have the knowledge needed to convert your scripts to CMUD (and are already doing this)
3) You will convert your scripts to CMUD primarily because of the huge speed benefits you will get from using local variables in your complex scripts.

As Fang said, there is no way to make this seamless for you. But you should find that all of the changes needed to make your scripts work in CMUD are all for the better and probably get rid of a bunch of kludges that you needed in zMUD and will end up with more readable scripts.

But you don't represent the "typical" zMUD user. The typical zMUD user isn't using that kind of complex script, and the existing Compatibility Report should be all that they need. If they use more complicated scripts, they probably got them from someone else (an advanced zMUD user) and will convert to CMUD once their advanced friend has converted their scripts.

Novice zMUD users who don't do any scripting at all will move to CMUD easily just for the user interface and speed improvements.

But there just isn't any way to make an "automatted" or "seamless" script conversion. Mainly because of the loose and kludgey syntax that zMUD allowed. All CMUD can do it point you at some common issues and tell you which scripts don't compile.

Posted: Sat Nov 25, 2006 7:43 am

Wanderer Joined: 25 May 2006 Posts: 88

Magician Joined: 09 Oct 2003 Posts: 459 Location: USA

The package library also helps with the novice users who are taking advantage of other people's scripts. That in and of itself is worth the upgrade, because of all of the problems that can arise from trying to import some settings from another person's zMud files.

Posted: Sat Nov 25, 2006 1:35 pm

Yes indeed slicer. And if .mud files don't work you're down to trying to get complex expression trigger scripts to export to TXT. Yummy :D

SubAdmin Joined: 18 Nov 2001 Posts: 5182

The only critical problem I see that was not mentioned is finallizing the behavior modules, which we have been discussing in another thread. If the NoTrig option was used as I suggested there I would also add the suggestion that it should likely be set that way as scripts are imported. This will likely be an important thing to have right since one of the most commonly used scripts is chat capturing. A new CMud user has to be able to import that kind of script and have it work correctly without having to find and tweak anything about windows, modules, and packages. That is going to be one of the things that many 'novice' zMud users see first.

Wizard Joined: 14 Aug 2004 Posts: 1269

Vijilante, any changes to scripts on import should be confirmed by the user. Other than that, I don't have a problem with your suggestion. Although importing a *.MUD file results in only one package and one window. The problem with modules from the other thread is when you have more than one window, more than one package, and more than one module. So it is not a problem initially. Therefore, when moving triggers from one package to another, the user could be asked "Do you want to switch on NoTrig?" (or something a lot clearer!) when it is not already enabled. This might solve the problem without messing up other triggers.

GURU Joined: 26 Jul 2001 Posts: 1958 Location: Canada

The package library will solve most of the issues with those 'novice' zMud users for the more complicated calculating, combat, curing, making and ecetera scripts.

Novice Joined: 14 May 2001 Posts: 33 Location: USA

One thing that I would think to be important for the public release would to try to get the help files as complete as possible. Even after using Cmud as much as I have been there are things I don't know completely.

Novice users may have diffucult time without the use of help files or tooltips (which are absent in some places) to figure out some of the interface usage.

Posted: Sat Nov 25, 2006 6:26 pm

Wizard Joined: 14 Aug 2004 Posts: 1269

I agree with everything you just said Zugg, except that I wouldn't insist on maintaining 100% backwards compatibility between major public releases, e.g. v1.x and v2.x. If possible: yes. But often, software, in general - even "Public" versions, does not maintain backwards compatibility between major versions. However, for public releases, I would expect compatibility between v1.25 and v1.36.

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

I've already sent feedback on this but. The user defined functions still are not working properly. They do not work in the value of buttons, do not work inside other pre-defined functions, and they work, but not properly inside If statements.

#if @staget(bal) {Do this} {Do That}
Compiles

#if @staget(bal)) {Do this} {Do That}
Compiles

#if (@staget(bal) and (1=1)) {}
Syntax Error

#if (@staget(bal)) {Do this} {Do That}
Does not compile, syntax error Evil or Very Mad

#show %num(@staget(bal))
Parse Error Unmatched parenthesis.

#show %eval(@staget(bal))
Parse Error Syntax Error

Ect ect with the pre defined functions.

I was unable to get them to work in the Value of buttons. Or of gauges as well.

Posted: Sat Nov 25, 2006 7:16 pm

Create a new topic on the user-defined function problems. I have added this to the high-priority list. It looks like something that I tried to fix in 1.16 made this worse. But this is definitely the kind of critical error that I'm talking about that I need to fix for the public version.

Posted: Sat Nov 25, 2006 8:00 pm

Wizard Joined: 14 Aug 2004 Posts: 1269

This needs to fixed IMHO (just rechecked on 1.16 even though it is not listed as being fixed):

#SUB compile problems
http://forums.zuggsoft.com/phpbb/viewtopic.php?t=25357

Also, a similar issue I just discovered with parentheses in an #ECHO statement that does not have {} at the beginning and end of the echo statement. {} was not a requirement in zMUD for #ECHO, and if it is now, it should be automatically changed on converting *.MUD files.

EDIT 13-Dec-06:
I created a thread for this #ECHO issue (which actually affects #SAY and #SHOW too) here: [1.16] Compile problems with comma within parentheses.
Both issues still exist in v1.23.

Apprentice Joined: 12 Mar 2005 Posts: 195

I agree with everything you have said zugg. But in comparison to seb i think compatability is important.

Between major versions there certainly should be absolute compatability (but between beta versions i understand that there can be as major changes makin compatability hard). If I used release 1.x and had to recode my system every 2x 3x etc i would eventually not update my system, and stick with the old version. Which means that when my free updates run out after a year, i wouldnt buy again to continue to get the updates.

As for the help files, your very lucky zugg, you have some amazing people that help people on the forums. No matter how simple the problem is. Vijilante,mattlofton, and nexela to name but a few. So i think the community will come together in the initial absence of the help files.

Zugg, my only hope is that the release goes well. So you can enjoy your xmas like most other people.

Wizard Joined: 14 Aug 2004 Posts: 1269

I never said that compatibility was not important. I believe it is very important. I just said the *I* would not expect 100% compability between 1.x and 2.x public versions - there would almost certainly have been beta versions in between. And you yourself, adamwalker, said that you would not expect compatability between beta versions. So it doesn't really make sense to expect 100% compatibility between two public versions when there are beta versions inbetween.

Posted: Sat Nov 25, 2006 10:47 pm

Actually, although I agree with adam on the compatibility, the actual reality is probably closer to what Seb is saying. I think compatibility is *very* important, but I can't predict the future and if it turns out that there is something in the 1.x public version that absolutely had to be changed even if it broke compatibility, then I'd probably still do it. After all, it's still the "first" public release. But I would only do this if absolutely necessary. I had this same policy with zMUD, and it was pretty rare to have a new version that wouldn't import and run your old scripts. So I don't really expect this to be much of a problem at this point.

Seb, I've increased the priority on the #SUB issue. I think it's related to the problem with user-defined variables. You might want to create another post on the #ECHO issue. But it's important to keep in mind that parenthesis have a new function in CMUD: they perform expression evaluation, kind of like the old [] syntax in zMUD. I'm still working on improving this so that parenthesis can be used normally, but the idea of leaving out {} just because you could in zMUD is something that needs to change.

On the help files, I should also mention that the Gurus actually have read/write access to the help topics, so eventually I'm sure they will be improving some of them too. I know that right now they are afraid to touch anything and getting in my way, but eventually we'll get things coordinated. This is an important feature that zMUD didn't have. Even though the Gurus could change the *online* zMUD help files, there was no way to get these updates transferred into the installed help files. Since CMUD has the Get Updates feature for the help files, it should be a big improvement as time goes on.

And don't worry, I'm not planning to ignore the help files. It's just a matter of priority and the fact that there are only so many hours left between now and the public release deadline.

Apprentice Joined: 11 Aug 2006 Posts: 100

Events

Novice Joined: 14 May 2004 Posts: 37

I thought that before CMud went to public beta, suport for the zChat plugin was going to be enabled. I'm really waiting to do much of anything with CMUD until that is available, since the majority of the scripts I use tie directly into chat.

Posted: Mon Nov 27, 2006 6:34 am

kernighan, that changed. zChat (and other plugins) won't get handled until after the public release. There are lots of issues with plugin compatibility that need to be looked at, so it turned out to be more complicated than I had time before the public release, sorry. My guess is that rather than just porting zChat, I'll be putting built-in chat features directly into CMUD.