Zugg Software :: View topic

Posted: Wed Aug 30, 2006 2:18 am

To start a slightly new thread based off of another one:
1)

Magician Joined: 29 Nov 2005 Posts: 482

Most importantly this is still beta as such features are missing or buggy that you are used to using etc. So i wouldnt be too hard on anyone because you get a crash while trying to edit something he just in the last version messed with.

3. the defaults are over ridden by things you put in packages. So if you redefine your default number pad in a package it will over write the settings in the default package.

2. Your inherited settings i think more evolve around the packages created which is something i believe zugg mentioned already isnt quite ready yet.

1. Please dont take my words out of context. You asked for an xml export which i provided. It still looks like

#TRIGGER {BLAHBLAH} just like it did in zmud and since that was what we were discussing when i posted that comment i would prefer that it stays in context. You wanted to edit your scripts by printing them out.. The text version showed #COMMAND etc. whereas the xml didnt and was hard for you to read. My post was directly related to that point.

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

1)You don't. ZMud kludged everything, and high on that list was the Class Script tab. Unless Zugg is going to add it back again, it's forever gone, I think.

2)is related to #1

Posted: Wed Aug 30, 2006 4:10 am

Posted: Wed Aug 30, 2006 4:26 am

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

I used the class script page a fair amount when I was doing my scripts, however that was usually to do with sharing my scripts with others so with the package library I'm not sure if I will have the need for it or not.

Sometimes I would copy the class script on one computer, and using a clip-board sharing tool, paste it into the command line on my other computer to get the script installed.

So... it definatley had its uses, even if they are limited.

Maybe a more human-readable form of XML is still the way to go, and that XML could be displayed where the class script used to be?

Posted: Wed Aug 30, 2006 4:34 am

All I want is SOME way that I can export or copy and paste my entire scripts into a text file so that I can then print it and on a relaxing train ride be able to see:

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

I'm going to go out on a limb here and say that if there's no way to export triggers to a human readable format then it'll hurt CMUD far more than shared packages will help CMUD.
Personally the shared packages feature doesn't excite me much, I only play one mud and I don't expect to start anywhere else. Ignoring that though, if I was ever to download a package then I'd want to be able to see what it does - which I'd normally do by exporting to .txt and reading.
If I couldn't easily see what it does I'd not download it, simple as that. Not only because I want to see what's running on my machine, but because if there's something fancy in a script then I'd like to be able to pick it apart and use it elsewhere to learn. That's how I've picked up most of what I know, by looking at what other people have done better and trying to copy it. I'd expect a lot of the more experienced users would be in a similar position.
Another reason (something I already posted elsewhere)

Posted: Wed Aug 30, 2006 10:20 am

Posted: Wed Aug 30, 2006 5:24 pm

The "Class Scripts" are not necessarily gone for good. As mentioned, they were kludged in zMUD and had many problems. In some cases, people have lost a lot of work because of these problems. So it didn't make any sense to implement something this kludgy in CMUD. More readable text formats *are* planned, and you might see some sort of Class Script or "Module Script" in the future.

However, let's stop whining about changes and "the way it used to be" and focus more on what you are trying to accomplish. Look at *why* you used Class Script. Vitae mentions that he prints the script to read it on a train. OK, that's the *task* to support. It doesn't matter if it used zMUD's kludgy text format or not, as long as it's something readable that you can print and edit. Other people have mentioned exchanging scripts (which is really what the shared library is meant to handle), mass editing of scripts, etc. Try to focus on the task you are trying to perform and not the specific implementation details.

Also, I will repeat this over and over and OVER AGAIN because people just don't seem to get this: ITS A BETA VERSION! Not only are beta versions buggy, but they are not feature complete. Please stop gettting bent out of shape.

In fact, I'll say something even more controversial: the first Public CMUD version might not even implement *all* of the features. CMUD is going to be developed and improved over many years, just as zMUD was. zMUD had 10 years of development. CMUD has had 9 months. Some things are going to take time to appear in CMUD. My focus on Public Versions is to make them stable. But new features are going to be added over time. The first public version of CMUD is not going to magically implement everything you have ever desired. It will take TIME to add new features, or even some features that were already in zMUD.

As other people have said: It's not like zMUD is going away. You are free to continue using zMUD until you feel that CMUD is good enough to switch to.

Posted: Wed Aug 30, 2006 5:28 pm

Oh, and back to one of Vitae's questions about the default settings:

a) Unlike in zMUD, you SHOULD NOT CHANGE any of the default settings. Just add new settings to your own package and they will override the defaults.

b) If you want, you can click on your Module/Window in the settings editor and in the list of enabled packages, you can uncheck the "Default Settings" package. This will disable the default settings for your module. The list of enabled packages is the proper way to control which packages are used/inherited for which modules/windows.

c) If you *really* want to change the default settings, go to the View menu and select the "Show Default Settings" option. Then click on the Default Settings module and then select Package Properties from the Edit menu. Uncheck the "ReadOnly" option for the package. Now you can make changes to the default settings and the changes will get saved to the default.pkg file. However, this file will get overwritten when you upgrade CMUD, which is why you shouldn't change the default settings.

Posted: Wed Aug 30, 2006 5:56 pm

Posted: Wed Aug 30, 2006 6:03 pm

Posted: Wed Aug 30, 2006 7:28 pm

Posted: Wed Aug 30, 2006 7:40 pm

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

I think there needs to be an easy interface for overriding the defaults - eg I've been trying to create an atconnect macro in my MUD package (rather than the Default Package)... it would be nice if I could start typing on the atconnect macro that's in the default package and have it pop up saying "This is a default setting, would you like to create an override setting in your MUD's package?" instead I had to create a System class in my package, then create an atconnect alias - all manually.

Likewise for disabling specific classes, if I click the disable button on KeypadDiag then it says "This is a default setting, would you like to disable this class in your MUD's package?"

Just something to make the task a little simpler :)

Posted: Thu Aug 31, 2006 1:56 am

I'll probably add something more like that in the future. But right now things are changing too much. For example, the "atconnect" alias is going away and will be replaced by "events" and that will get rid of some system defaults. And for the keypad stuff I'll probably just add options to enable and disable the entire class since for most people you either want the keypad or you don't, so few people are going to disable a single key.

But having the keypad defaults are really no different than some of the Windows menu shortcuts. For example, if you assign a macro to Ctrl-C, it doesn't work unless the "Override Menu Shortcuts" option is turned off. So why treat the keypad any specially. Instead of being defined in the default.pkg they could just as well be keyboard shortcuts.

So yes, there are always things to do to make things simpler. But I have so many other higher priorities that you probably won't see tweaks like this for quite a while.

My feeling is that when the default settings are done properly, then you won't even know (or care) that they are there. I actually feel that the dialog in zMUD that tells you that you are overriding a default setting to be annoying and not very novice-friendly.

Posted: Thu Aug 31, 2006 2:08 am

Vitae: In CMUD everything has a "priority" number that determines the order in which things are processed. Every enabled trigger from all packages are sorted based upon priority number, with the lower numbers going first. By default, priorities are multiples of 10 so there is plenty of room to put your own triggers in the right order. So this isn't confusing at all and is more like how people wanted zMUD to work.

Back to the Default Settings issue...it sounds like you really just want to disable the keypad macros. As I said, I might consider making that a preference option that is easy to change. You really don't want to completely remove the default settings, because then you are also removing stuff like the default direction settings, which would make all of your paths and speedwalking stop working. And you'd lose all of the default preference settings, so you would end up with all sorts of preferences that were set different from the "clean install" settings that other people use.

So, "getting rid of it in the 1st place" really doesn't make sense if you understand everything that the default settings really control. And again, it's trivial to create ONE package that does what you want and then include it in the list of packages that you load with your session. This is something that you set up ONCE for a character and then when you change your own common package, all of your characters see the changes. It's really not that much work and I think you are just being a bit stubborn about not learning the new package system and embracing new features that will help in the long run. Perhaps you are just frustrated by some of the rough edges of these features in the beta. But it's starting to sound a bit like the poster who just didn't want to change anything.

As far as making the file read-only, no, CMUD doesn't do that. The ReadOnly option box prevents any writing to the *.PKG database file. You can always go into Windows and make a file Read-Only yourself if you are worried about making a change. No need for CMUD to mess with that. I don't want package files to magically disappear from Windows just because a user still has the "hide readonly files" option set in Explorer.

Posted: Thu Aug 31, 2006 2:31 am

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

Magician Joined: 29 Nov 2005 Posts: 482

Vitae I am sorry but you really should read some of zuggs other posts. I have to run to work but ill link em up later.

The defaults window was hidden after a lengthy set of posts from many of us about not wanting to see or play with it, That it just shouldnt be shown. Many of us, myself included wanted to be able to redefine the settings in there based on a package we created.

Posted: Thu Aug 31, 2006 4:10 pm

Posted: Thu Aug 31, 2006 5:21 pm

Vitae, something you are forgetting again is that the Default package is *overwritten* each time you upgrade CMUD. This was also true in zMUD. So what did you do in zMUD when you upgraded and your default.mud file was overwritten? Did you restore your own backup or something? By doing this, you are not loading the latest defaults, so any changes made were not taking effect. While this might not have caused you problems in the future, it's a very bad way to handle things. All it would take is one new preference that you weren't initilializing properly (because you were using an old/modified default.mud) to mess things up. And this kind of problem would be really hard to find because everyone else would be using the proper defaults.

I think we have discussed this enough and gone around and around. In fact, the more I listen to this discussion, the more I'm thinking that I will make the Defaults completely un-editeable to avoid problems with people changing the defaults.

Creating your own Personal Defaults package as edb mentioned is *easy*. It's something that will take you 5 minutes and you only have to do it ONCE. It only adds a couple of seconds to creating a new character session, which isn't something that you would do every day. The time that you would waste in the future dealing with a bad default settings file is *way* more than the time it would take you to just do it right in the first place.

Regarding the atconnect, atstartup, etc stuff...there have been other posts about this. Those aliases are going away and will be replaced by a new "event" system that is more flexible. You won't need to redefine these aliases (and they will disappear from the defaults). So yes, it will be trivial to disable any classes you want at startup.

Edb: About the trigger priorities: Only the priorities of the TRIGGERS matter. The priority of the classes have no effect right now. CMUD only uses classes to determine which triggers might be enabled/disabled. The entire list of enabled triggers is sorted by the trigger priority number to determine execution order. Using the class priorities would involve a complex "join" query that would significantly slow down trigger processing.

Even though every setting has a priority, only triggers and buttons currently use the priority to do anything.

Posted: Thu Aug 31, 2006 6:33 pm

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I am thoroughly disgusted by this entire thread. I was also more or less disgusted by another thread or two closely related to this topic. In all cases the threads were fueled or started by you, Mr. Vitae. I had some respect for you, but it has all been eroded. That is the extent of my personal rant; because anything further, that I actually want to say, would require me to behave as a moderator and promptly delete my post.

Change is a good thing. Most users use the numberpad for directions. It is extremely easy, and for some of us even too fast for the MUD to be happy with. I have 10 years of experience doing data entry on a 10 key device so I also understand that using the number pad for numbers is faster then the standard top row in a keyboard layout. I used to do 13K keystrokes per minute on a 10key type machine.

Zugg has expressed his concern that most users have an easy transition into CMud. This particular discussion has yet to seem to be an issue for more then ONE user, and a solution is simple. The addition of a 'personal default' package. This would be a package that is inheritted by all sessions as well, and is secondary to the actual Default package. A user could make adjustments to that personal default such as using the still to be created 'onload' event to turn off classes within the Default package. I believe this would satisfy both the concerns of the 1 without impactiing the concerns of the many, however I would also guess that implementing some such thing might be a bit low on Zugg's priority schedule.

On a more personal side to this whole issue, I always end up overriding a number of the settings in the Default package. One way or another, they are not adequate to an experienced MUDder. In most cases, the changes required are specific to a given MUD; but I always end up having to override them. Most of the time I would create my own class and use zMud's "Remove inheritted class" for the default settings. So I do really understand Vitae's request that we be able to simply disbale settings in the Default package; even though his expresion of that request has disgusted me.