Zugg Software :: View topic - Global Package and Automated export/import questions.

Apprentice Joined: 17 May 2005 Posts: 108

I'm trying to learn to use packages as intended, but after placing all of my speedwalks in one, I found that I had almost nothing left that didn't require unique variable values/keys from one session to the next, and worried that these things would overlap and thus fail to operate as they should. So, to put my mind at east, is there an approved method for using a variable path in a variable to ensure that it is defined in, and referenced from, the session/class that I desire?

For instance, a little experimentation shows me that:

Posted: Wed Jan 16, 2013 7:00 am

Variables defined from any package should automatically be defined in the root class of the session that the script is running in (unless it already exists in a class), not the package that tries to define it.

#VAR name {value} _nodef {class|names}

should be fine, though i rarely see the point of defining the class unless i have more than one variable of the same name going, and frankly i prefer to always use a unique varname
i just moves the variables about manually when i go in to clean up my scripts

Wizard Joined: 22 Mar 2007 Posts: 2320

In general you shouldn't need to specify the full path to the variable. You can put triggers, aliases, etc. in a global package, even if they use variables defined in the session packages. As long as each session defines those variables in the session package, the global triggers and aliases should work fine. And new variables created by scripts in the global package will by default be created in the session package. That is one of the specific purposes global packages are designed for.

Apprentice Joined: 17 May 2005 Posts: 108

Excellent, that makes using packages a lot easier. Trial and error also proved that triggers created by the package also showed up in sessions, so everything worked out.

Thanks for the info!

Apprentice Joined: 17 May 2005 Posts: 108

Well, changing over my major/most used scripts to packages is nearly complete. I discovered early on that scripts which rely on triggers that turn on/off based on input from the mud don't work very well in global packages (first session to match the pattern fires them, rather than the session that initialized them, obviously). Now the only issue (so far) deals with connecting packages to sessions. I went through and edited the session individually, adding packages to those sessions which needed them, then I discovered that a session will use a package that I did NOT link to it, providing only that the package is loaded when said session is online (or vice versa).

For example: I have a thief's session loaded up, which uses a "rob script" package. At some point while the thief's session is loaded, I decide to load up a cleric's session, which is not linked to/should not use that package, but triggers in the "rob script" package fire in the cleric's session.

I can fix this (so far) by opening the the package editor, clicking on the main icon of the session that I do not want to use the package, and unchecking the package in the advanced tab. This works, but I wondered if there were some way to avoid this problem. With some 6+ packages per session, 20+ sessions, and a variety of packages I want to use with each session, loading up every possible combination and unchecking packages manually could turn out to be a very long process.

Any suggestions?

Posted: Sun Jan 20, 2013 6:47 pm

well you could edit each of your sessions (package files tab) and make sure that they are only loading the packages that are actually relevant to them

Apprentice Joined: 17 May 2005 Posts: 108

That is exactly how I added packages to the sessions. The issue is with packages running on any session that is loaded, regardless of whether or not those packages were added to the session in the package files tab.

I have found it to be mostly true, thus far, that global packages which create or define variables do so in the session that causes the action to take place. However, I've been having a great deal of trouble with one session accessing another session's variable when a global package sets it. For instance, I have an alias in a global package, "ca," which does

Posted: Sun Jan 20, 2013 11:47 pm

it sounds like you are having one of the standard multiplay issues... i think you need a supersession that only handles the layout
on top of a session for each character you play
there are other threads that go into this more in depth

seeing as i always run a seperate instance of CMUD for other characters, i cant really help you out further

Apprentice Joined: 17 May 2005 Posts: 108

Well, I believe I have solved the problem, though further testing will be required to find out for certain. In case anyone has a similar problem and wonders what I did, here's an explanation.

I did this by first changing the variable into a database record, using

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

#wait creates a new thread. One thread referencing a variable that another thread references will result in an AV when both try to reference the variable at the same time.

Apprentice Joined: 17 May 2005 Posts: 108

I didn't think that that could be considered the same variable. Although each session had its own instance of the @LastSpell variable, one character, we'll call him Joe, will have a reference to @//Joe/Lastspell.Joe, while character Bob has his reference to @//Bob/LastSpell.Bob.

If both characters had a #wait (which was created by a trigger in a global package both of them are using) at roughly the same time--i.e., the one wait began at any point before the other had finished--only one of them would fire.