Zugg Software :: View topic

Enchanter Joined: 10 Oct 2000 Posts: 698

This has been discussed briefly in several topics and I thought some additional discussion might help resolve some issues that Zugg has raised with regard to parsing in CMUD.

Anyone who has used zMUD for a lengthy time know that there are between three and twenty ways to accomplish any given scripting task and in fact, many recent questions on these forums deal with which way is best or optimal. What I'd like some thoughts about is the actual syntax structure itself. What follows, is what I believe based on the majority of posts to these forums. I do not have knowledge of bug reports and support issues sent by email, only what I read here.

I believe there are three types of client (zMUD/CMUD) users, broadly speaking.

1. Most people who use zMUD do very little actual scripting of their own. The majority of users create solitary triggers, aliases, macros and maybe a button or two. These users do not typically read or post to these forums. If this type of user has an intricate script, it was created by someone else. This type of user wants to mud, not write code.

2. Technical people who want to learn/create something new, people who want to beat/cheat and corrupt the balance of MUDs, and people who have become burned-out, or tired of mudding, but still want to stay involved. This group starts most of the new topics in these forums.

3. Hardcore programmers-gamers/gurus and old-timers. This group typically closes the topics started by the second group by offering amazing scripts, solutions and suggestions.

If this breakdown is correct, then what impact will a strict parser have on each of these groups? If the breakdown isn't correct, what other groups should be considered? I believe the syntax should be altered and tightened in CMUD to optimize the performance of the program and clarity of the scripts, even if it breaks compatibility with zMUD.

I believe the first group may or may not buy CMUD. Most will probably be happy with whatever triggers/aliases/macros and borrowed scripts they already have if the pizzazz of CMUD doesn't convince them to change clients.

The second group WILL buy CMUD, and WILL modify their scripts because they enjoy scripting as much as/more than mudding.

The third group... well there aren't many in this group so they won't impact sales much, but their understanding of scripting concepts and evolution of the language will still be available to offer instruction on the forums.

Why should sloppy and/or legacy syntax be supported in a new application? Will support issues really become too burdensome?

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

Hehe, I think you're just about spot on there.
I fall squarely into the 2nd group - I'm pretty much/completely bored of the game I'm playing, and tends to be that I like figuring ways to beat the game far more than actually playing now. I'm also looking forward to CMUD so that it'll let me rewrite my old scripts in shiny new CMUD code. I'm pretty sure the benefit overall will be minimal but that's not really the point, it's more that I enjoy the making of it more than actually using it at the end. I'll happily spend hours on something that really doesn't help me much ingame, just because it looks flash and there might be some obscure situation that nobody has ever come across where this script might come in handy. And yes, I'll come up with cool ideas I have no idea how to fix, so the 3rd group of people will then fix it for me Twisted Evil

.

But anyway, I'm all with the "just fix it all, forget about legacy support" group.
The people who will make use of the extra features will be competent enough to figure out the changes, and those that aren't will have the forums to help them. Long term I think that a CMUD running as close to perfect as it can be will be more beneficial than CMUD written with a few quirks to make it seem more familiar to ZMUD users.

Posted: Tue Apr 18, 2006 6:45 am

This is a good discussion to have, and I think I agree with your breakdown of the 3 classes of users.

Here are my thoughts on these groups (going in reverse order):

3) I agree with you that the "guru" (whether official or not) group will likely buy CMUD. If anything, just to support Zuggsoft. Also so they can play with CMUD and become "gurus" of the new program. These people are active in the forums and will adapt to whatever is done in CMUD.

2) I agree that these people will also probably adapt and will probably buy CMUD and be active in the forums.

1) This is the group I worry the most about because this is where the majority of zMUD users are. When I released zMUD v7.20 and got rid of the eLicense copy protection, over 4,000 zMUD users upgraded to 7.2x within a couple of months. There are only a couple of hundred of active forum users. So, obviously the vast majority of people who upgraded are not posting to the forums. Also, the majority of these people upgraded only after zMUD reported the new version via the auto-update feature. They did not upgrade based upon the announcements in the forum.

The success of CMUD is dependant upon this (1)st group of people. I've drained our savings account and put bills on credit cards to hold out as long as possible so that I can get CMUD released and get the upgrade income for CMUD. If a large fraction of zMUD users do not upgrade to CMUD then Zuggsoft will fail. We've been hanging by a thread for a couple of years and bad product decisions haven't helped. This is out last chance.

But you can see the problem that I face: the vast majority of people that I depend upon to buy CMUD are not posting to these forums. The opinions in this forum really only represents group (2)nd and (3)rd group. And those are the most flexible people. So while I rely on these groups to help guide me in technical decisions, this isn't the group that will make or break the product.

That is why I'm so concerned about zMUD compatibility. This (1)st group likely doesn't have the programming experience to "fix" their scripts. And they are not as likely to post their problems on the forum. Unless the friend who wrote their scripts in the first place convert them to CMUD, they probably won't upgrade unless there are some really compelling reasons. If zMUD doesn't work with Windows Vista, that might provide a reason to upgrade, but I can't wait that long, and my guess is that zMUD will mostly work on Vista in some sort of compatibility mode anyway.

I *DO* want to fix as many "wierdnesses" from zMUD as possible and there are many topics about things I've already changed for the better (like how evaluation is done instead of expansion, how %1..%99 work, getting rid of the need for [] and <> syntax, etc). But each time I make a decision to change something, I need to carefully wiegh the potential impact.

If the initial impression of CMUD is "this is totally broken crap" then the word will spread and sales will suffer horribly. Even though many people won't use the first few beta versions, I need the initial impression to be very positive.

Just look what happened to zMUD in the past: a couple of slow, buggy versions got released back in the early 6.x days and zMUD suddenly got this reputation of being slow and bloated even though the later versions are many times faster than anything ever before. It can take a long time to overcome negative impressions.

Even though most people here probably fall into the 2nd and 3rd categories, I'd still be interested in comments on this topic. Thanks for posting it Mr_Kent.

Posted: Tue Apr 18, 2006 8:28 pm

I'm squarely a 2/3 guy and I have a sense of the challenges you are facing. (Even when I wasn't actively mudding I'd check in on zMud and Zuggsoft just to see what gee-whiz developments you've made. I think some of them are part of the reason why I started mudding again.) So I believe you do need a compatibility mode in CMUD that the users in group 1 will know that in the absolute worst case their code will run. What I think will be the draw for them are the enhanced GUI options, even better MXP support and packages. GUI for obvious reasons a few well place gauges and button make all the difference and a few sample scripts for CMUD will wow many. Gauges, buttons and to a lesser degree prompted me buy me first copy of zMud.

The other two I think will drive sales especially if the larger MUDs (like Achaea for example) come up with good packages. With skinning support and zApp scripting they can potentially come up with "custom" packages for their MUDs. The advantage to you is of course greater CMUD sales and the the MUDs themselves they avoid the development costs/hassles of a full blown client. Cross promotion advantages etc.

To sum up what I'm saying I think you should definitely give the gee-Whiz features that groups 2/3 request because, much like PC enthusiasts we ultimately lead the broader market. However it's imperative you offer 95%+ compatability other wise you may lose your broader base (or worse) before we get a chance to let the greater MUDding population know how great CMUD is.

As an aside, you may want to build in a feedback or poll feature into CMUD as way to get feed back. Participation would be totally optional of course. You can transmit info when the new version check is done. This would give you the opportunity to get feedback from at least a few of those from group 1.

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

I'm a 3 guy myself, and I can also see the difficulties you face in the upgrade. Legacy support is always a very difficult problem, and many would say it's a necessary evil. Sometimes, you can get around the problem by having an intermediary to convert the old to the new, but still keep out the old code in the new program. That will make things tough on the beginner/intermediate users, obviously, so you want to keep it simple and that means integration of the old parser, unfortunately.

I can say for certain that the scripts I've developed for zMUD, to be used in Achaea and Lusternia primarily, have been responsible for selling a few copies of zMUD. People have purchased the client for the purpose of being able to use my scripts, which I think is pretty cool. I intend to take advantage of CMUD early, and to develop all new scripts, which will help compel some people to upgrade, maybe.

Wizard Joined: 14 Aug 2004 Posts: 1269

This may not be practical, but, as Tech touched on, how about adding a flag to packages (and classes): "Operate in zMUD compatibility mode?" If set, the zMUD scripting language applies to that package, but another button is available - "Convert to CMUD syntax" - which will attempt to do that. However it won't be saved permanently at that point, so the user can revert the conversion if it didn't work out. Upon reversing, maybe a box could come up and say something like "We noticed you reverted this package - if the CMUD syntax converter didn't convert your zMUD script properly, you may wish to help us improve the converter. Press Yes if you want to send the package to Zuggsoft for analysis, press No not to send it, or press Never not to send it and not to be prompted in future."

If this helps improve the converter, it may help people to upgrade to CMUD.

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

I was going to suggest much like what Seb said - with the addition that perhaps it could be sent to a 'help me' library where guru's or cmud-pro's (approved by zugg of course) could look at the packages and fix problems (with a CVS-style change history so you could undo). The only issue with having a guru-fixit is finding enough willing guru's to keep up with the demand.

Probably just having the 'operate in zmud compatibility mode' and 'submit to zuggsoft' options is enough, but having a 'help me' ticketing system within the client might be worth consideration.

Posted: Wed Apr 19, 2006 2:16 am

Collect a sampling of the more complex scripts that are likely to have conversion problems to test efeciancy.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

*cough* There is a huge sampling over in the Finished scripts section */cough*

Seriously though that would provide a pretty fair base for guessing just how much compatibilty issues there will be upfront. While some of those scripts are not truly complex, there are also a number of very complex things. Most won't provide any sort of live testing to assure proper behavior, but they will provide a more robust test of compiling issues.

I actually think I probably would make the worst test case in terms of useful data. I have all my scripts syntax checker happy, don't trust implicit concatenation ever, and use unnecessary delimeters all the time because they are right for things like "#ADDITEM List {@value}". However, I am one of those who will likely be able to fix incompatibilties in a matter of hour or so on my lean 300k .mud and other 20k .mud for secondary window. I am actually even thinking I may have to force myself to write some truly horrifically sloppy scripts just to do beta testing.

Posted: Wed Apr 19, 2006 5:24 am

I'll take a look at the script forum. As you said, it's hard to actually test most of them, but they would be useful for compile tests. My master test script is also quite good since it has all sorts of interesting syntax that I've collected over the years.

But adding a way for people to send me scripts that don't compile is a useful idea, so I'll try to add that. I don't think I'll get as fancy as having a way for Gurus to review/fix scripts or anything like that, and I don't want to tie it to the shared script library. The shared script library is only for CMUD scripts (no compatbility mode scripts here).

The compatibility mode is in CMUD already, although as I've said, it's something that I'd plan to phase out during the beta period.

Wanderer Joined: 30 Dec 2001 Posts: 66 Location: USA

What, no group for me?

I may have not read close enough but I can't seem to find a group for people like myself. Those of us that do use other peoples code but would like very much to build our own up from idea to working model.

As for purchasing CMud, I plan to. I would get in on the beta when it happens even if it meant paying at that time.

Just an observasion from someone that hovers between groups 1 and 2.

EDIT: I would have to echo Seb and Rainchild.

I'm always late on these things. :(

GURU Joined: 10 Oct 2000 Posts: 873 Location: USA

There's one quote from another thread that seems relevant here:
http://forums.zuggsoft.com/phpbb/viewtopic.php?t=23084&start=0

Posted: Tue Apr 25, 2006 3:22 am

I know that on the Aetolian mud forums, there are several posters/players who have been vocal about the coming of cmud and how excited they are. Whether people are benevolently excited about offering free scripts to everyone, or thinking about charging game-credits for a subscription to their curing system - they are not just excited about the new features and speed, but about the site based sharing of scripts with their fellow mudders.

So I know that at least among the people I still mud with (and its really only Aetolia these days) the people in (3) should convince many of the 1s and 2s to upgrade both by offering cool scripts and simply because they are saying even now how cool CMUD is/will be.

Also, people on IRE rarely post to the general forum here asking for help anymore. They post to the forum for their mud, and people like myself (who enjoy the problem solving) answer their questions. This is actually the primary reason why I rarely look at the zuggsoft general forum anymore. So my point is that while there may be only a few hundred active posters on the zuggsoft forums, there are (at least in the circle I'm part of) still people asking about and indirectly promoting the product elsewhere.

The two most important things for CMUD then, is:

(1) Initial stable release, even if sparse on features
(2) Do not get too complex. I actually disagree with the description given of group 1. They are definately the majority, but they do actually make scripts more complex than just the odd trigger/alias. There are people that want to play well, that both cannot script and do not fall into group 2. These people will benefit hugely from the features that aid the sharing of code, but also from anything that keeps things simple for them.

The most commonly asked question I see on the Aetolian forums about zmud is: "I want to create an prioritised auto-curing system, how do I do it?" These people often have very little clue about scripting, but so long as they have a brain that is slightly logical, with our help they end up with a reasonably first-time attempt after just a few months.

Some of the suggestions made in the various wishlists (actually, quite a lot of them) will actually make this sort of process easier for these people. I guess you could call them "group 1.5" - but the thing is that in IRE at least, the majority of group 1 that doesn't get into PKing wishes they could get into it. The only reason they don't is because they feel they can't, and if CMUD really does offer them the ability to do this, then those people -will- upgrade.

Posted: Tue Apr 25, 2006 3:27 am

That may have been a little ambiguous. An example though, of a feature that will appeal to people, is the #FUNCTION expansion you mentioned at one point. I actually use #FUNCTION in a few places even now, in zmud.. for the simple reason that when writing a script, if I can hide a few lines of string manipulation code in @funcvar(x,y) - then this makes the debugging of the main script so much easier just for myself in the initial writing of the script.

I've always wanted to create a 'library' of functions useful to the people that play my specific mud, but just never got around to it.

Posted: Tue Apr 25, 2006 5:04 am

Wizard Joined: 14 Aug 2004 Posts: 1269

It might be an idea to restrict the first few (or most unstable) betas to selected people. Either people you know, Zugg, or perhaps people registered on the forum for at least X months. This way perhaps most people without the patience to try the beta, or understanding of what a beta is, won't be able to try it and thus be disillusionned with the bugs that will perhaps annoy them.

Posted: Tue Apr 25, 2006 3:37 pm

That a good point about the beta release. Of course the beta releases will all have bugs. If they don't I predict google will hire you away from us before june :d

And thanks.. Embarassed

Posted: Tue Apr 25, 2006 7:23 pm

Seb, unfortunately I've tried that with zMUD in the past and it was a failure. When I release a Beta version, I've usually already fixed all of the obvious bugs myself. In order for a beta to be successful, I need a larger number of people looking at it. Just having a handful of selected beta testers doesn't really help much. Over the years I have found that having an open beta is more useful. It's worth the extra support load of dealing with people who didn't realize it was a beta in order to get feedback from a larger population.

Wizard Joined: 14 Aug 2004 Posts: 1269

OK. I seem to remember one has to go through a few extra clicks with some beta warnings to download a beta from Zuggsoft anyway, so that should be sufficient, in theory.

Posted: Wed Apr 26, 2006 12:33 am

In this magical compatibility mode, would CMUD be smart enough to say 'I see you're using X feature, in CMUD you can use Y feature in Z manner, and this will result in faster execution'?

Posted: Wed Apr 26, 2006 2:10 am

No, unfortunately not...the changes are too low a level for that. Also, the only way to handle the old parser is with a "global" flag (that is global to a particular character session). So, different characters can have different compatibility flag settings. But, for example, packages cannot. So if someone has the compatibility flag enabled and then loads a package that requires it to be disabled, then things won't work. This is unfortunately because of the poor design of the old zMUD parser, so there isn't much I can do about it.

I know this is a pain, but that's why I intend to get rid of this flag entirely pretty early in the beta process.

Also, it's not a matter of "X feature" being faster. *All* features are faster with the new compiler/parser. There is no script feature that is faster using the old parser.

Right now I'm using the flag to test compatibility and to test speed differences. But that's about all that it's good for. But the time "normal" users start using CMUD, this compatibility flag should be gone and either scripts will get converted when imported, or will be notified some other way about how their script needs to be changed. In the early beta versions, problems that prevent a script from being compiled will display a prompt allowing the user to send me the failed script, as some other people suggested.

Also, some changes to CMUD, like storing settings in the database, are uneffected by this flag. The flag only effects the parser. So, there might be other bugs that cause things to fail even with the flag turned on.

Posted: Wed Apr 26, 2006 2:16 am

Thats a pity, yet when I said 'faster' I was using it as a codeword to hint at 'better' in all kinds of ways.

What if you take a %function in the script editor and leave it as hoverable in compat mode, so the CMUD helptopic for that word is loaded? Flatly importing scripts into cmud may be undesirable, I'd want something to say 'we be changing this function into this one, heres a link to help on why'.

Posted: Wed Apr 26, 2006 5:07 am

I think you are overestimating the changes needed for CMUD. None of the %functions are any different. So far the main issues will be with %1..%99 expansion, and with more evaluation vs expansion to get rid of unneeded %evals and [] syntax. None of this is stuff that any sort of "mouse-over help" will help with.

Also, actually, the new script editor doesn't yet have the mouse-over command and function help. That was part of the old zMUD syntax checker and the new editor uses more traditional syntax "highlighting" rather than strict syntax checking. It's something I plan to add again once the new compiler/parser is working well enough. The F1 help is there, just not the mouse-over stuff.