Zugg Software :: View topic

Posted: Thu Jul 20, 2006 1:09 am

I decided to play about with 2 sessions at once so created a session for the sample package. I was online with my main session and went offline with the sample session and the status bars that were defined in the sample session suddenly took effect in my other online session, I tested using an alias which worked also.

Has anybody else tried this, what do you get?

Posted: Thu Jul 20, 2006 1:27 am

Something else I've noticed too. If you close a session the settings window still has a pointer to it and so if you open a session again you end up with a new pointer to it. I did this with the sample package and got everything happening twice. Anyone else get the same?

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Yeah I have seen that as well. It causes all sorts of problems if you start deleting the duplicates in the Settings Editor too.

Magician Joined: 29 Nov 2005 Posts: 482

Yeah i think there are a few more quirks to mash out in the settings side of things..

Variables are having issues as well :/

Posted: Thu Jul 20, 2006 12:42 pm

Just to clarify this bug in case my top posts confuse:

Seperate sessions, say one to MUME and another to Achaea, which have seperate package files end up sharing their settings. So triggers and aliases etc defined in one session are available to all sessions.

Wanderer Joined: 13 Jun 2005 Posts: 51

Can you find the setting file? I cannot find those mud files defined in sessions.

Magician Joined: 29 Nov 2005 Posts: 482

sounds like you are creating things in the default package its using for all connections ><

I can load two different muds and things dont fire on both (NOT SHARED) but the default seems to be shared. Anything in default seems to work on both.

I am not sure i really like that.

Posted: Fri Jul 21, 2006 8:01 pm

Nope each session has seperate packages not related to the untitled package and settings work for any session. It may be because one session is offline. I'll create a new session to an actual proper online location and see if they mix then.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I will predict that they will mix. So far I have seen buttons, staus line items and many other settings; that I want to be seperated on other windows shared.

I don't quite think the new settings system is the right to seperate settings to only act on certain windows. Multiple sessions likely falls into the same space with the way the new window setting was created. I think the first step is to ensure that multiple window settings of the same name can not be created, this likely would involve the addition of way to tag the source for what becomes a common capture window. Next is getting an ownership field for the window settings. Each package needs to be listed for easy modification, but all of its settings must be excluded from windows that don't own it. The truly hard part of that is how to handle the main window for a session, I believe that requires that a session create a 'window setting' outside of all packages with an ownership list that covers the default and assigned package file. That assignment would be done through the editting the session, and needs to have an option to include the default package.

I say that the default package needs to be an option since I generally have to override or disable over half the settings in it.

Posted: Wed Jul 26, 2006 8:39 am

the problem seems to be all currently enabled packages seem to be available to everything, there is no scope of what session it works for

Magician Joined: 29 Nov 2005 Posts: 482

yeah i kinda would prefer not to have the default package but i understand why its there.

Posted: Wed Jul 26, 2006 4:58 pm

The purpose of the default package is to initialize *all* of the default values for preferences, and to set up the system class structure for stuff like the Directions, Autologin triggers, and Keypad macros.

This way, your own character-specific packages only have to store what's different. Unlike in zMUD, where each MUD file had a complete set of preference values, a CMUD PKG file only has the preference values that are different from the default. Thus, there has to be some sort of "reference" package to determine if a preference needs to be saved. It uses the Default package as this reference, so it would be hard to get rid of this.

My guess is that the main thing people don't like about the default package is that a) it's visible (and I might add an option to keep it hidden so you don't have to mess with it), and b) some people don't like the default macro key assignments.

(b) is easy to deal with since any macros that you define in your own package will override the defaults.

So, perhaps people could be a bit more specific about what they are needing to disable in the default package.

Wanderer Joined: 13 Jun 2005 Posts: 51

Is it possible to specify which package I am using when I use command line to add a trigger, alias, etc?
When I use #tr, it is always added to default package.

Magician Joined: 29 Nov 2005 Posts: 482

just about anything. The only reason i even used a package with settings to begin with was due to the error i reported to you about settings not saving properly unless i used your precreated MM File due to some other issue.

The main default package which houses the atconnect etc. I end up attempting to delete or disable the macros, buttons, auto gauge, auto stat bar etc. I leave the atconnect alone although i do add things to it. Which i prefer not to do in a default package but rather in the "PACKAGE FOR THE MUD".

I dont want every mud that utilizes the "Default package" to use the settings i have to stick in there. depending on the mud.

In zmud i got the option to start with a 100% clean file minus the atconnect aliases etc.

As you stated i "can" override them with settings in the package but i dont want to do that because then if i distribute my package with specific macros setup its going to override the ones the user created or what another person uses as default. In addition i dont want to have to add a rack of macros to my new package that already exist. its like having extra settings that arent needed.

For me i just edit the default (which i dont like doing again because its default) or i delete the macros in there and recreate them in my mud package.

Also for me I dont like the folder structure. Its a personal quirk im sure. But i dont want things in SYSTEM and MXP etc. I have a very specific setup for every alias and trigger etc i use. I was in the middle of redoing that when you mentioned cmud and i stopped because i knew id have to recreate it and with packages it will allow each package to house the settings for a particular script. Which i like. After im done cleaning house the default package is left with like 4-6 empty folders (dont have cmud up atm) which just annoy me.

So i agree with you maybe it would better if the default is just hidden and all the changes you are making go to the current package you are working on. Because some of them tend to go to other places like default. Use the default as your safeguard and dont let us play with it. Dont let us see it. Save our options to the mud package we are creating. For me its a visual clutter i think more than anything.

Wanderer Joined: 13 Jun 2005 Posts: 51

Current package and session system is too confusing that I still have no successful loaded package, nor a saved session yet.
I hope help files will be available soon.
IMHO, package and session should be completely parallel, each session can link to a set of different packages, but it should not be able to modify common files by default. Packages should a sealed entity with its own logic and data and provide limited accessibility from outside.

Posted: Thu Jul 27, 2006 5:05 pm

I think the main problem is that people are having to deal with the bugs of stuff not going to the correct package. Stuff should *not* be going into the Default Package. The Default Package is a read-only package to initialize the defaults for the program. It was never intended for general use.

I'm going to start another thread on Session problems, but I think this is another case where things in CMUD are really messed up and it's not working at all as I intended it, and we probably can't really have an intelligent discussion until I fix these continuing major issues. With the current bugs, the package system just isn't working and things that people are complaining about are really bugs and not design problems.

Anyway, for now, please avoid modifying stuff in the Default Package. The default.pkg file gets overwritten when CMUD is upgraded, so you'll just end up losing all of your work.

Stuff that you add should be going into the "Untitled" package, or in whatever session package you have loaded and created from a *.MUD file from zMUD.