Zugg Software :: View topic

Newbie Joined: 21 Jan 2006 Posts: 2

pretty sure i can speak for my entire mud. if there's no chat cmud is useless. our entire game rotates around the need to communicate in real time while inputting other commands to the mud. i would love to purchase an up to date client, but zmud will have to suffice until this issue is fixed.

Newbie Joined: 11 Dec 2002 Posts: 9 Location: USA

Posted: Sun Jun 10, 2007 3:08 am

I just realised that the CMUD help file on multiplaying hasn't been updated since zMUD, and it's definitely very basic. You're right, it needs improvement. One other thing is that CMUD's manual does have a tutorials section, but unlike zMUD's article system (which was pretty well-hidden and so not extremely useful), there's no way for the average user to add more advanced examples.

And you're saying that when you disconnect one character from the MUD, they all disconnect? I didn't see this - I double-clicked on a session to open it, then pressed the sessions button to open the session select dialogue again. From there I double-clicked on another session to open it. I typed #dis in one window and the other stayed connected. What're you doing?

And I see what you mean now! Botting and scripting are two very, very different things. In my mind (and on the MUDs I play) "in control of your character" extends to scripts as well - you need to be in control of the scripts that're in control of your character. I always saw it as a stipulation against leaving the keyboard and having your client fight on for you. I once wrote a simple AI to control all my attacks, and provided that I was sitting at the computer while using it - and thus still in control in that I could start and stop my character at will (and that I had made the choices that programmed the AI) - there was no problem. Is your MUD stricter than that?

That short digression aside, what is it about CMUD's multiplaying as opposed to zMUD's that you think is constrained at the moment and forcing you to create illegal scripts?

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Posted: Sun Jun 10, 2007 5:33 am

If you were having trouble with crashes and stability, then you should submit crash dump reports or post the problem to these forums. The v1.33 version has been very stable for the vast majority of people. I'm getting less than 10% of the crash dumps that I got for versions a couple months ago. The 1.33 version is only about a month old, so it wasn't clear if that was the version you were complaining about.

In any case, I can't fix something that I don't know about. If you report the problems, then I can add them to the bug list and get them fixed. If you don't report them, then I can't help. And in many cases the crashes are caused by something in your files or on your computer that can be fixed.

Novice Joined: 01 Jun 2003 Posts: 32 Location: USA

Why am I not useing CMUD? Things that work in ZMud, don't work in CMud. %btnenable, only turns it off not on. I was Told that was a bug. What was the work around? Use %btnimage. Well, I have tried many times to not have the caption show on the button. It keeps comming back. I've removed the name, and put set the ID. The ID always becomes the name again, and the caption shows back up in the button. At this point in time, that is just my biggest agravation with CMud. I go back to ZMud, because CMud is buggy. ZMud isn't. Does that make any sense?

Wrens

Posted: Sun Jun 10, 2007 5:08 pm

It would be nice if people would actually use the new version instead of complaining about old bugs. The %btnenable issue was fixed in the 1.33 version of CMUD. Whoever told you it was still a problem was wrong. If you think CMUD is "buggy", then post a new topic in this forum to discuss the specific problems you are having and someone can help you. But don't just rely on information that you are getting that is coming from old versions. I've done 33 versions of CMUD in the past year. That's almost 3 versions a month. Some people can't keep up with that.

If you want a blank caption for a button, use a caption like: @blankvar where the @blankvar variable has a blank value.

You also have to remember that zMUD is 10 years old. It actually still has bugs too. All software will always have bugs. Since CMUD is only a year old, it is bound to have more bugs. So I'm not saying that CMUD doesn't have some bugs, but before you call something a bug you should post a new topic to the forums and find out for sure before making false accusations.

Novice Joined: 09 Oct 2003 Posts: 40

Without reading the entire thread I just want to know if there is plans to put the old trigger tester in like Zmud has? I love that thing. I recently tried Cmud with the idea I was going to rebuild my scripts so I could have a "new version" of my scripts. Well I went to do my first trigger and the mud I play on uses special characters a lot and I got tired of trying to build the pattern then having to go to the mud and test the trigger and then go back to the package editor. I miss the old trigger tester where I could copy the line I am trying to match and put it in the tester and lock it and test it. Put that in and I'll be sold.

Phanku

Posted: Tue Jun 12, 2007 3:32 am

It will be added. It says so right here at Status of New Features in CMUD

Posted: Tue Jun 12, 2007 4:33 am

For now, Phanku, you can comment out the script part of your trigger and just add "#say Fired!" - then use #echo to display whatever text is supposed to fire the trigger. You could also use #fire. If your script is very long and commenting it out would take too long, just disable the trigger and create a new one.

Magician Joined: 25 Oct 2000 Posts: 461 Location: USA

If you're willing to switch to using regular expressions, you can also use any of the available online regex testers (http://www.quanetic.com/regex.php, just as an example)... ohh, or even as a Firefox plugin (https://addons.mozilla.org/en-US/firefox/addon/2077).

Beginner Joined: 07 Sep 2005 Posts: 12

One of the largest reasons that I haven't changed to CMUD yet is because scripts need alot of work to be converted, like my spellup script that I haven't got to work at all. Everyone around me still use zMUD and what I really miss is the feature to edit whole classes again so I can share and use (import/export) scripts in the same way as they do.

Another thing that's bothering me alot in CMUD is that it's harder to read the commands when scripting, because CMUD puts them all like

#ADDKEY bla bla;alias1 %db();#IF () {bla bla}
#ADDKEY bla2 bla1;alias2 %db()

instead of

#ADDKEY bla bla
alias1 %db()
#IF () {
bla bla
}
#ADDKEY bla2 bla1
alias2 %db()

which zMUD doesn't, and that bothers me alot because it's harder to read and handle the scripts.

What I would also like is that the program would auto ident all lines within {} when #IF and such commands are used, not only when there's more than 2 lines.

If the suggested things here would be added/changed, I would most likely change to CMUD and somehow get the main scripts working.

//Ice

Posted: Wed Jun 20, 2007 5:27 pm

CMUD no longer prints your scripts prettily on the fly because there're many associated problems with it. It's one of my major gripes with zMUD. New versions do include the pretty print feature, though - press Ctrl+M or choose Reformat Script from the Editor menu. Just make sure your script has no syntax errors before you do this.

If you post details about your scripts that aren't working in a new thread, I'm sure there are plenty of people around to help you with getting them working.

And finally, what do you mean by sharing and exporting/importing scripts like you used to? The text export from zMUD was one of the most complained-about features as I recall, which is why CMUD opted for .pkg files and an XML export. The next version of CMUD should include a new, readable XML format for exporting (and writing) scripts. As it stands currently, XML export works exactly like text export did, but it's not easily understood.

Apprentice Joined: 06 Apr 2004 Posts: 173

I think the thing I'd want most... is to have the import export trigger options the way they were in zmud... I totally don't understand the xml export, and transfering triggers back and forth between zmud using this option is useless. I've tried saving packages, but it crashes my system, so I'll not do that for a while.

Apprentice Joined: 06 Apr 2004 Posts: 173

let me clarify what I mean, I was rather vague. In zmud it lets you save as .txt in the export triggers option. the output is the standard:
#VARIABLE varname1 {val} {defval}
#ALIAS aliasname {setting}
#TRIGGER "id" {pat} {com} "" {}

whereas the cmud export saves it as xml
and it's hard to edit in notepad because of all the extra stuff... and its impossible to export to zmud because it's a different format

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

Export to Zmud is discouraged as there are new features in Cmud that did not exist in Zmud. There are soon to be even more features that
were not there before. Earlier there were even fewer differences and people just thought of Cmud as a prettier Zmud; that is not the case.

Yes, if you come up with a concept that works in Cmud that concept can be used in Zmud, but they should be considered more in the terms of
I wrote a program in C++ and my friend is using Linux so I want to write him a copy of my program in Java.

There are many things that work in C++ that work very similarly in Java. But like the difference between Zmud and Cmud if you try to do other things they just do not work or require totally different syntax!

Zugg worked hard at first trying to make the syntaxes as similar as he could for importing so that we would not have to completely rewrite our scripts. Some of us have HUGE scripts. My stuff for Avalon alone is enormous and I have merged my own stuff with Larkin's for Achaea... You don't want to know!

At first I would play my muds in Zmud and test in Cmud. Once Cmud got stable enough that it was not crashing on me all the time, which has been a while now. I started converting my scripts to it. I would not want to go back to playing on Zmud now.

That all said. Now that I am making scripts in Cmud I know how to write in both languages and can recreate my new stuff in Zmud.
Yes that is cumbersome but I can understand why Zugg does not want to support moving scripts from Cmud to Zmud.

What I do when I MUST go backwards is open both programs and copy and paste between the two settings editors. Test things. Then I export from Zmud.

Apprentice Joined: 06 Apr 2004 Posts: 173

even realizing that they are different, I would still like to see triggers in a familiar format. It's easier to manipulate in the older format. And there are enough similarities to make it worth while. After all zugg isn't completely destroying zmud now that there's cmud. There are a lot of similarities, and all the major commands still work the same way.

Posted: Thu Jun 21, 2007 9:06 pm

I assume you mean trigger exports in a familiar format, and that the comparison you're drawing is between the old text format and the new unreadable XML export. I remember a thread somewhere where in which Zugg was lamenting the old text format, especially the #button command - it was simply ridiculous with the number of options it had, making it pretty hard to define one yourself with a command. The new XML export that's slated for the next version will be much more readable and also be much better for setting that kind of thing, if you can find the examples Zugg gave.

Expecting as much ease as possible when moving from zMUD (which can be considered the old client) to CMUD (the new one) is to be expected, just like moving from an older version to a newer one. But trying to move from a new version to an old one of anything is usually much more difficult because of all the new features added, and this is really another case of that. It's true enough now, but it'll be even more so after the next version (check out the feature list!) - CMUD will just be too different to zMUD to allow easy movement backwards. But since the intention is for CMUD to be superior to zMUD in every way, I don't see that as a problem :)

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

There are many benefits to using an XML format that most people just don't consider. I wrote a program once that saved data files in XML. I then updated the program to a version 2.0 with a fairly different, but similar, XML format, adding new attributes and child elements. One thing that surprised me was that I could still easily load the old XML files in the new program, filling in defaults where pieces were missing AND load the new data files in the old program, ignoring any attributes or elements I didn't need.

When the XML format is made more human readable and you have the option to edit it inline as a class script, things will be much easier for anyone wanting to use this method of writing/sharing scripts. For now, it's more of a feature placeholder that people can use for some debugging.

Beginner Joined: 07 Jan 2007 Posts: 17

Other.
can't afford to even test it, but if it handles XML better than zmud and I don't have to trigger all the id's and presets from dr, i'd jump the moment I could afford it.

Beginner Joined: 07 Jan 2007 Posts: 17

Ok, the single most needed feature is the update of the simutronics folder to allow <push(function)> and <pop(function> presets, preset ids (colorings) and an update to the trigger that catches the values of hp, mana, stamina and spirit to the dragonrealms xml too.

The word stormfront placed under the simu emu section. (now only has zmud, wizard, fe_browser)

maybe a default package for minimum, optional things could be included in the test instance, with just the bold(ing) presets?

Wizard scripting functions?
sf scripting functions?

Posted: Thu Aug 16, 2007 10:42 pm

Could we get a feature similar to the Option Explicit in vbscript?

Any possibility of a search feature that could scan through all currently located packages? Example - find variable weapons in all locations.

Reasons - I've had code go crazy and create things I didn't expect. Then I spend several sessions discovering my variable created in other classes and even other packages. In the worst case something went crazy and I had the variable hp created 300 times in just one class. Still trying to recreate this bug as it happens intermittently and is hard to pinpoint.

Posted: Thu Aug 16, 2007 11:10 pm

Posted: Thu Aug 16, 2007 11:17 pm

If you explicitly refer to a variable using the @//ModuleName/ClassName/VariableName syntax that way your variable should only resolve to variable.

To see the list of all variables, typing #VARIABLE with no arguments will list all variables in memory.