Was wondering if anyone was making a curing system for Cmud. thanks!

To be honest, CMud is not really ready for building a stable system just yet, or at least last time I was brave enough to try.

I really wish people would stop saying this! Yes, it is. It was as of the December release if you were patient enough to deal with the odd behavior. There were just two rapid releases this month as well that fixed most of the bigger issues. I built a system for it with the December release and have never had it crash on me during a fight. When messing around in the settings editor, yes, it had some isses. Possibly I'm an anomaly though.

So yes, you can build a complex and stable system in CMUD. However, if you don't have the time to build the system from scratch (as importing from zmud is a nightmare) I wouldn't recommend using it.

I have a cmud related question, and I'll spare Catarin from having to read a new thread about it. In Lusternia, lots of messages will have the line break be in a completely random part, based on the description of the weapon used. Does cmud have a feature to identify text for triggers across multiple lines in such an instance? Because if not, I have been using zmud long enough and am competant enough with c++ (whyte's mudbot) that I would have no reason to upgrade to it.

I don't know about cmud specifically, but with zmud you could have your wraphwidth IG set to 250 and have zmud wrap back to 80 per line, or however many you want. That way you'll only have to worry about line breaks after 250 characters and to be honest I can't think of many relevant game messages that are longer than that. I assume you could do something similar in cmud.

I can match those lines in CMUD exactly the same way I do in zMUD, so it's not a problem in either client.

I do agree that Catarin is the anomaly, however, in getting a combat system to work in CMUD. I've found that even some basic script commands don't behave as they should, but mostly it's the complex stuff that is quirky. I suppose it's possible that if you use only simple variables and basic triggers for tracking and curing to make a system that runs without crashing.

I'm not only waiting for some of the "quirks" to be ironed out, though. I'm also waiting for the mapper to be re-designed and for the zApp GUI code to be added.

I think you've earned the right to have your avatar(I just finished the 2nd season and working on the ova's now). I didn't understand half of what you just said.

Even when I got something to actually work in CMud it was godawful slow. 1-2 seconds per prompt slow. That was every prompt, so it can't have just been slow compiling.

Then again I haven't put a huge amount of effort into it. I'd rather wait and do the job properly once than chip away at it, needing to workaround everything. Especially when I have a stable client that does what I tell it.

You know, I am really not sure what version of CMUD you have been trying. I'm not trying to be an advocate or anything but I find that people open it up, do something, it crashed on them and now they state it doesn't work. I'll list some of the things off the top of my head that work stably that I use in my system:

1. Triggers - Multistates, Expression, and normal triggers all work fine. A note though, if you are running triggers and you are connected to the mud, a lot of times when you try to update a setting in the settings editor, it will not take unless you turn off triggers before trying to edit it.

2. Variables - Functions, stringlists, normal variables all work fine. There is/was a bug where sometimes you would set a variable to have a certain default and it would not actually reset to that default when you reset the variable or the class until you restarted CMUD. You also have to set more options on the class if you want to be able to successfully reset all variables in it to their start ups.

3. Alarms - Named and unnamed work as intended. Sometimes CMUD will not clean up the alarms if you turn off triggers and they haven't fired yet. This is indeed a pain to clean up if you use unnamed Alarms but it's a matter of a few seconds work deleting them all.

4. Database - All database functions work smoothly. The database GUI is kind of screwy though and the views you set up can be unstable if you are getting a ton of information in at once. It has trouble keeping up.

5. Math - #ADD had some bugs in it. It worked fine most of the time but sometimes would just come up with bizarre numbers. It's been fixed. The normal math functions work fine.

6. Predefinied Functions - I haven't yet come across a predefined bunction that did not work. I haven't tried them all of course.

7. Buttons - Buttons are less user friendly than they are in zmud but they have the same functionality. A key thing to remember is you set the position of your bars in the options menu, not in the individual button interface.

8. Switch statements - Besides the speed the most useful feature I've found in CMUD. Work beautifully.

So given that I am not just using basic triggers and simple variables even remotely and my system runs fine without crashing could one of the individuals that confidently states that it is not possible please point out where exactly they are encountering the problems and in what versions rather than making a blanket statement as to the usability of the application?

It makes more sense to give people advice to not use the system if they utilize x,y, or z features that CMUD still has issues with and they cannot adjust to something else than to just say that because you are unable to code a stable, complex system in the application then it is something that no one can or should bother trying to do.

I am sorry I am so defensive about it. I just find it very frustrating that people will continue to state things that are untrue based on limited experience without actually giving people concrete examples of what does not work for them so that they can make an educated decision whether to use CMUD or not. It's not like I have stock in Zuggsoft or something. I have no reason to be lying about my experiences with the product.

Is it ready for a novice user? Probably not unless they want to become more than a novice user which is always a good thing. Is it ready for a system that you would feel comfortable selling to people? Most likely not though it has very nice features that will support this once all the quirks are hammered out. Is it ready for a person pretty comfortable in zmud that is flexible in their scripting style to try their hand at makign a system for it? Most definitely.

It does NOT like zmud scripts. If you want to just convert one over, you're better off sticking with zmud. Cmud is much much stricter about scripting conventions than zmud was. Something that worked fine in zmud will not in cmud if it is not set up the way cmud likes. This is something you will have to overcome if you were used to using "sloppy" scripting style in zmud.

You've stated several things I find frustrating in CMUD with your first few points. There are workarounds for some of the quirks, but the quirks are more noticeable than the ones in zMUD.

#RESET doesn't work for me, and I'm not going to play with class settings or restart CMUD just to make it work the way it should. I know it'll be fixed one day, but not today.

#EVENT has issues firing things reliably, especially when more than one is receiving notification and especially when events are in separate packages.

Pasting my larger scripts into the command line for import causes the compiler to choke and nearly die. The command line is the best parser for scripts that I write, and there's no way that I'm going to manually create everything in the Package Editor. Text editing scripts has always worked best for me, and it's the way I'll continue to script in CMUD.

Using #T+/- will disable the wrong class folder if I have more than one class with that same name. It doesn't search the current hierarchy or package first. It seems to scan through all packages for a match, starting with the first package installed. The workaround for this was simple (rename the class folders to be 100% unique), but shouldn't be necessary.

Nesting #FORALL loops inside multiple aliases (alias A has a loop that calls alias B which has its own loop) creates problems because of the overwriting of the %i variable. It should be a simple parser fix to make %i a local variable, but Zugg hasn't figured this one out yet, so it must be more complex than that.

Until 1.25 the multiplaying capabilities were horrible. Opening multiple windows caused a real mess and there was no workaround for it. Zugg insisted that we just had old layout files that got corrupted and re-installing would fix everything. He was wrong, and he ended up completely re-writing his code for loading/saving layouts.

I only use the very latest version of CMUD for my testing, and I always completely remove my previous CMUD before upgrading to the new version. Zugg is a fine coder, but he doesn't always consider the ramifications of his changes or unit test everything as well as he could.

From the comments you have made the impression I get is that because CMUD is not as polished as ZMUD at this time and does not support how you wish to script and requires a few workarounds in order to get some of the features to work, you are uninterested in using it at this time. That is perfectly valid and indeed many people may be just like you and feel the same way.

However, there is a difference between you do not wish to make the changes necessary to script a stable, complex system in CMUD and the statement that it can not be done. Hopefully you can see the difference. It is unfair and untrue to state that a stable system cannot be created in CMUD at this time. But you have outlined what specific problems you have for it and others have laid out what problems they encountered so hopefully those who are up for the challenge will be more wlling to give it a try rather than believing that it is unuseable.

I've been saying this a lot lately, but... fair enough. It's possible, if you want to work within the limitations of the current CMUD. Personally, my only reason for switching to CMUD now would be to make use of these great new features Zugg has added (packages, events, etc), but it's those features that are frustrating me the most. I'll come back to it in a few months because I'm hitting the ceiling in zMUD, too, with the number of triggers I have matching for all my various subsystems.

The core of my CMUD system is nearly 5,000 lines (including blank lines, multi-line commands, etc) and pasting it works except that I think the compiler is still running through it all in the background or something when I try to use it. I haven't found a workaround for it other than to do as you suggested and break my script up into tiny, bite-size pieces, which makes things less pleasant for me. I want it to work more smoothly, so I spend less time working around things like this.

Events, local variables, strict parsing, real compiling, and all that is great, which is why I'm really hoping Zugg can track down and eliminate the remaining problems soon. It's still not easy or straightforward to include WSH languages into a system, but the CMUD scripting alone is very powerful and adequate for most tasks.

Catarin , is your reflex system for sale and would it be flexiable for mages?

Fraid not. I'll be happy to work with you to set one up though!

excellent

At least you people HAVE reflexes. I have to hand-type just about everything except a few things I have aliased, mainly because I'm using Nexus and I'm not getting much help scripting things and secondly because I've never had need to. Until my wrists start hurting from hand-typing every single command.

Put more aliases in then. Manual curing via alias is perfectly feasible, if you can get good enough at doing it.

Do it well enough and choke will never be a problem for you either!