Zugg Software :: View topic - Making sense of Packages, Sessions, and Classes

Newbie Joined: 16 Jan 2012 Posts: 7

I'm getting confused reading the help files, any Gurus able to set me straight?

Here's what I would like to do:

1. Log in to a mud with a specific character having all aliases and triggers unique to just that character.
2. Log out.
3. Log in with another character with aliases and triggers unique to that character too.

Upon CMUD startup, I get a window telling me to choose a session. Are sessions the way to go about this??
I created a session called healer and a session called thief that log into the same mud, but all the triggers and aliases are the same for both characters.

Sorcerer Joined: 15 Apr 2011 Posts: 809

The only reason all the triggers and aliases would be the same is if they're sharing a package. If you create a new session, it should get its own package, so I'm guessing you either manually added your first session's package to the second session, or you used copy/paste to create your second session, in which case the packages of the session you copied would all be attached to the new session. You can change a session's packages by editing the session, then going to the Package Files tab, removing the ones you don't want to apply to each character should fix your problem.

Newbie Joined: 16 Jan 2012 Posts: 7

Thanks for the reply. So new sessions should get their own packages? Good to know! Yea I simply right-clicked my 1st sessions icon and duplicated it, then just renamed it. So both sessions are using the same package.

I'll create a new "thief" package and attempt to apply that package to the "thief" session. Same with the other character: healer sessions/healer package.

Then for classes, those are just folders in a package to group similar aliases/triggers/functions/etc?

Sorcerer Joined: 15 Apr 2011 Posts: 809

That's correct. They can also be used to disable groups of settings all at once, which can be useful.

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

Session = the collection of packages, mapfile, databases, and user-maintained datafiles that defines your playing interface.

Package = a single file with a collection of windows and modules (both of which can potentially contain classes, which in turn can contain all of the other settings type displayed in the New button dropdown in the Package Editor).

Window = a module with a visual component to display visual entities (text, buttons, menus, pictures, etc). Classes and any other non-window/non-module type settings are stored in Windows.

Module = a window without that visual component (there are a few other technical differences, but we'll leave that for a later conversation).

Newbie Joined: 16 Jan 2012 Posts: 7

Very nice, thanks Matt.

This was fun, here's what I did.

1. I opened up my default session/package that I've been playing in.
2. From the package manager, I created two classes (thief and healer).
3. I moved all thief aliases, triggers, and functions to the thief package, and vice versa for the healer ones.
4. I then created two new sessions called Thief and Healer and had those sessions load their respective [thief/healer] package.

Good to go. Upon launching the thief session, I have just thief-y aliases and triggers running.

But one question, all the maps are gone. I was thinking I could create a third package titled "Maps" and have both thief & healer sessions load the Maps package so I don't have to recreate maps for each character. But where do I find the map information? I'm stumped on this one.

Sorcerer Joined: 15 Apr 2011 Posts: 809

If you open the package editor with the map open, you'll see a map object at the top level of your package (not in a window or module, it's its own entity). Create a new package (File -> New Package), then move that map object into the new package. Then edit your sessions, go to the package files tab and add that package with the map object to both sessions. That new package doesn't need to be exclusively for the map, btw - you could use it as a general shared package and put any scripts that you want to be shared between both your characters into it.

Wanderer Joined: 13 Aug 2011 Posts: 74

I would appreciate explanation on the following example. Lets say I play on one MUD with two independent characters (one at the time), so i created one session for each. I want to use scripts counting creatures defeated by my characters (example representation as db variable "rat=26|ork=17"). It will be shared so i put this module into a package and add it to each session, right? But then all statistics will be summarized from both sessions and i want to count it separately when I am logged as first or second character.

This is why i completely don't understand the idea of packages.

Posted: Sun Jan 22, 2012 2:35 pm

CharA has its own session and package
CharB has its own session and package

both want to keep a count of kills so you make a shared package to count kills

your issue is likely that you left the database that stores the info iINSIDE the shared package (which means same data for both)
instead, let each character make a database within thier personal settings (same name for both)
Then use the shared package to increment it.

Sorcerer Joined: 15 Apr 2011 Posts: 809

Just because you want both characters to have this script doesn't mean you need to put it in a shared package. If you want the stats to be calculated separately for each character, it sounds like you actually want two copies of the script, one in each character's package.

Wizard Joined: 22 Mar 2007 Posts: 2320

It's perfectly possible to have the script in a shared package. That way if you need to edit it, you only need to change a single copy. All you need to do is make sure the variables which store the data are in the individual session packages. A script in a shared package can read or edit a variable in the main session package.

Beginner Joined: 16 Oct 2011 Posts: 13

I'm using shared packages like Rahab is talking about, yet have run into lots of unexpected dilemmas. I use a lot of class folders to keep all of it sorted out. The #CLASS command can be useful in your scripts by enabling and disabling specified classes that contain your unique aliases and triggers.

Another idea for using shared packages is %char

If you create a class with your character name, you could try something like this.
character=%char
#IF (@character=NAME) {

#CLASS Thief 1
#CLASS Affiliation 1
}
-If you use another session don't forget to disable your classes.

Posted: Wed Apr 11, 2012 12:07 am

Wizard Joined: 22 Mar 2007 Posts: 2320

A shared package refers to a package which multiple sessions will load. In the Package Editor, you can add and remove packages for the session. For instance, the English Directions package is a shared package because by default every session will load it. Near the top of your Package Editor, there should be a series of tabs, one for each package you have loaded (except for hidden packages). There is an option inside each package to hide it, so it doesn't show up on a tab.

Modules in shared packages usually need to be set to global, but that depends on the details of the package. It is not a defining characteristic of shared packages.