Zugg Software :: View topic

Wizard Joined: 26 Mar 2008 Posts: 1547

Is there a way to make a variable that's global across sessions? Since each of my characters has their own session, I have some variables like attack_type, in each session. However, since this can be updated based on new attack_types, I'd prefer to have the variable be global somehow so that I don't have to replace each attack_type variable.

Posted: Fri May 16, 2008 11:52 am

Yes, put it in a package that's loaded in all of those sessions.

Wizard Joined: 26 Mar 2008 Posts: 1547

Maybe call it global? Whenever I load a package it wants to open a new connection window too. Is there any way to stop this? I think it only happens because I load packages of other characters and thus other sections, but it would be nice if I could do that without worrying about opening a window.

Also, how can I be sure that triggers and such entered through the command line go to the proper package?

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

In the Package Editor, use File -> New Package to make a non-session-window package. It will have a module of the same name inside it. Create your settings with the module name as part of the class folder structure to put things in that package (i.e., //Module/Class/SubClass).

Wizard Joined: 26 Mar 2008 Posts: 1547

Is there any way to open other session packages without opening windows?

And what you're saying about structure is that if I have two packages I need to identify them in what I'm doing? Like...

{Yasan|General Triggers|Quest Triggers} ?

Wizard Joined: 22 Mar 2007 Posts: 2320

The point of session packages is that they contain a window, the main window for that session. That is in fact the only significant difference between a session package and any other package. So the answer to the first question is no.

For the second, I'm not sure you understood what Larkin meant. If you have a session package and one or more auxiliary packages open, your commands will automatically be able to use aliases, functions, and other things in the auxiliary packages. If you want to specify exactly where something is in the package structure, the format is as Larkin said: //modulename/classname/subclassname.../objectname. If the classname is unique, you could drop the //modulename. For example, if you have a module NiceModule, with a class TopClass, in which is another class SubClass, in which is a variable NewVariable, you could specify it in a trigger as @//NiceModule/TopClass/SubClass/NewVariable. This would prevent you from confusing it with another @NewVariable in another location. If you are careful to keep names unique, then this is not necessary, and @NewVariable will work fine.

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

No. That's why you make packages that have modules instead of windows. You only open a session package to load things specific to that session and to get the window(s) with the connection. Everything else, especially shared or global things, should go into a separate (non-session) package.

You should only have to specify the full class path when you want to create the setting, but depending on how you write your code, you might want to use the full path to reference things (i.e., disabling a trigger, reading a variable, etc), too.

Also, remember to enable the auxiliary packages in your session modules. Select the module in the tree view to see the list of enabled packages.

Wizard Joined: 26 Mar 2008 Posts: 1547

Once again, you've seen how I store my triggers, etc... I just want to know if I can store them in a different way. Having a second package seems like it would cause problems trying to enter triggers, variables and aliases through the command line.

Wizard Joined: 22 Mar 2007 Posts: 2320

You asked how to have global objects which are shared by every session. We told you that the way to do it is with a separate package, which can be loaded with each session.

It does make it a little trickier to create new variables and objects through the command line, but we also told you how to do that--use the full path name, e.g. //NiceModule/TopClass/SubClass/NewVariable.

Wizard Joined: 22 Mar 2007 Posts: 2320

As an example, if you want to make a new trigger on the command line:

#trigger trigID {complicated pattern} {lots of commands} //NiceModule/TopClass/SubClass

Wizard Joined: 26 Mar 2008 Posts: 1547

Why the // ? I'm used to using { } for class names...

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

The {Class|SubClass} syntax still works, but it doesn't support modules (as far as I'm aware). Basically, it's been replaced with something better, and I recommend you learn the new syntax to make your life easier down the road. Smile

Posted: Fri May 16, 2008 5:02 pm

You can also use the #module command to set the current module in the same way you can use #class to set the current class.