Zugg Software :: View topic

Sorcerer Joined: 10 Oct 2000 Posts: 706 Location: USA

One thing I would like to see as a change with the package library is:
1) When you select a package to install that it would be able to detect what session you are in and put the package into a subdirectory under the mud session directory and open the package in that session instead of just downloading it.

Wizard Joined: 22 Mar 2007 Posts: 2320

I can understand the desire, but you don't always want to do that. Perhaps have it as an option.

Sorcerer Joined: 10 Oct 2000 Posts: 706 Location: USA

Wizard Joined: 22 Mar 2007 Posts: 2320

But once you download the package into the Packages folder, you don't have to install it again. You can load that package into any other session without going back to the Package Library. That is why it is put into the Packages folder rather than a specific mud folder. When it says "install" it means "install into Cmud", not "install into this specific session".

Posted: Tue Nov 09, 2010 5:16 pm

Rahab is correct that it means "Install into CMUD". Each session has it's own list of packages, and maybe I need to add a button to the Package Library to show the packages specific to your session. But what makes it complicated is that you might have multiple sessions open when you open the package library.

Sorcerer Joined: 10 Oct 2000 Posts: 706 Location: USA

Wizard Joined: 22 Mar 2007 Posts: 2320

It depends on how the package is built. A well-designed package would not store session-specific variables within the package itself, but let them be created in your own session. Then every session will have it's own variables which are used by the package, even if you have multiple sessions running at the same time with the same packages. A badly-designed package might have session-specific variables already defined within the package itself, which would lead to the problem you describe. If the package does not define where the variable is to be created, it will usually be created in your session package, not the secondary package.

[edit] Actually, that is a generalization. There are situations where you might want one session to know about the variables associated with a different session. In that case, a well-designed package would automatically keep track of which variable belonged to each session, possibly by using classes or variables based on the name of the session or character. My skill-tracking package does that, because I wanted it to track skills for my pets as well as my character. It had the side-effect of making the variables of any of my characters accessible from any other of my characters.

Sorcerer Joined: 10 Oct 2000 Posts: 706 Location: USA

Then say for instance how would I change my Speech Type script then to save the speech variable to the specific session? On one mud I play I use the stutter type and another I use the Old English Type. You can get my package from the library if you want to see it.

Also I have the same issue with my Mundane Auto Eat Scirpt for the food and container values.

Posted: Tue Nov 09, 2010 8:01 pm

If a shared package refers to a variable (without a full module path), then CMUD will look for that variable in the current session window. So just don't create the variable within the package itself. Let CMUD create the variable within the session window. Packages are not supposed to store session-specific variables if you intend the package to be shared across multiple sessions.

Sorcerer Joined: 10 Oct 2000 Posts: 706 Location: USA

If you give it a class path then it will create the class in the session window. For example:
#var ClassName/variablename 0

Wizard Joined: 22 Mar 2007 Posts: 2320

That is correct. Is that not what you wanted to do?

Sorcerer Joined: 10 Oct 2000 Posts: 706 Location: USA

Posted: Tue Nov 09, 2010 10:11 pm

Well, Rahab isn't exactly correct. When you use a path like that within a different module, it will create a class folder within the module it's being used from if no other variable is found. If you want to create the initial variables in the session window, you would do this:

Sorcerer Joined: 10 Oct 2000 Posts: 706 Location: USA

Zugg, I would like to initialize this only once. How would you suggest to do that in the package, without it initializing each time you load the package.

I answered my own question on how to get it to load only once. I made onLoad event and checked for a variable called setup if it is set to 0 it creates the class and variable as you stated how to do it, then I set the setup variable to 1. This way next time it doesn't run again.

My only issue is that with your above example the speech variable using the syntax of #NEWVAR variablename 1 didn't create it in the new class that was created.
Here is my code:

Wizard Joined: 22 Mar 2007 Posts: 2320

The easiest thing to do is to not specify a class name at all--just a variable name. If there is no variable already existing in the scope of the package function, it will create the variable under the session window. The user can then move the variable wherever he wants. Do you really need to specify a class name? Can't you let the user decide where to put the variable?

Sorcerer Joined: 10 Oct 2000 Posts: 706 Location: USA

I was using the wrong syntax.
Here is what I finally came up with.

Sorcerer Joined: 10 Oct 2000 Posts: 706 Location: USA

I just realized that when I moved the speech variable to be in the module window under the SpeechTypeGV class. My multi-state button now doesn't work. I doesn't recognize the speech variable now.
Here is the code:

Wizard Joined: 22 Mar 2007 Posts: 2320

Are the buttons in your main session window, or a different window? Likewise, is that alias defined in your main session window, or a different window? If it is a different window, it will not be able to see variables defined in your main session window.

Sorcerer Joined: 10 Oct 2000 Posts: 706 Location: USA

Wizard Joined: 22 Mar 2007 Posts: 2320

A window can reference variables, triggers, aliases, etc. that are defined in _modules_ outside itself. But it cannot reference anything that is defined in a different _window_. This is one of the main differences between modules and windows.

[edit] A bit more detail:
A module can reference anything defined within itself or in any window or module in a package that it has been told to check.
A window can reference anything defined within itself, or in any module in a package that it has been told to check.
A window cannot reference anything defined in a different window.

Sorcerer Joined: 10 Oct 2000 Posts: 706 Location: USA

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

Sorcerer Joined: 10 Oct 2000 Posts: 706 Location: USA

Posted: Wed Nov 10, 2010 10:18 pm

Matt is correct. But shared buttons are a bit special. When you put a Button into a shared package (global module), CMUD actually creates a separate "instance" of that button within each session that has the global module enabled.

Now, when a button is *clicked*, CMUD executes the script for the button instance within the context of the window that contains the button. So the script for the button will use variables within the specific session window that has the button. The Button Caption is also evaluated within the context of the local session window. This was tested with a shared button that displays a HP gauge, for example.

The problem is that this was never tested or made to work for multistate buttons. It seems that the State variable for the multistate button is being searched within the context of the module and not the local window.

It's possible that specifying the class name is causing this problem, so try it with just @speech as the button variable name and see if it works.

If not, I'll have to add this to the wish-list for a future version. It's too major of a change for a simple bug fix in the public version, sorry.

Posted: Wed Nov 10, 2010 10:29 pm

why not just have the button run the alias?
:%item(%name,1):aliasname