Zugg Software :: View topic

Newbie Joined: 02 Jul 2007 Posts: 2

Greetings,

After a long absence from mudding I've returned, and am recreating all of the scripts that I foolishly deleted back in the day. In order to save some time for my friends using CMUD, I'm setting up each script as a separate package to distribute to them (because I only want certain people to have access to the fruits of my labour, I'm only distributing the .pkg files directly). However, I ran into a bit of a problem when I split the scripts out into the individual packages.

Two packages have the same variable, @tank. Before I split them into separate packages, I would set "tank = somebody", and both scripts would use it and be happy. Now, only one of the two variables is being updated (in the package that comes first alphabetically, actually), and the other doesn't get changed. What is the best way to change them both together?

It's possible that this variable will end up in a number of my scripts, or that a similar problem will recur. The only thought I've come up with so far is to create a package for all of the variables for my scripts, so that there will only be one version of each variable, but this would give each person who uses it far more variables than necessary.

Any suggestions?

Posted: Tue Mar 03, 2009 11:15 pm

The idea, basically, is that you don't ever want to be in this situation: packages must be separate. Remember that - they must work entirely within themselves.

The problem comes because tank=somebody doesn't know which variable it should be setting - you haven't told it a particular one, or both. Exactly why it's going wrong depends on how and where you're running the command, but that's the general problem. The simplest way to solve this sort of problem is with events.

Instead of setting tank=somebody in your trigger, you instead do #raise TankIs somebody or something like. You then put an event handler in each package that will then set that particular package's copy of the variable - you can either play with the scoping rules until you have each one being set correctly, use absolute paths like @//module/class/varname (not recommended) or my personal favourite - give the variables different names. You could even, in some cases, do away with the variables entirely and put whatever code cares about their contents into events instead - whether or not that'll work in this particular case is for you to decide, but it's something to bear in mind for the future even if it won't work here.

The alternative to using events is to have a single copy of @tank somewhere that both packages can see it. The trouble with this is that this'll either require a third package to contain the variables, or require your end-users to do some fiddling to get the variables in the right place - neither of which is a great option. In my opinion, events are the way to go when you want to disseminate information from a single source to your many packages.

SubAdmin Joined: 18 Nov 2001 Posts: 5187

It sounds like the variable is session specific. Meaning if a person has 2 different characters and are using your packages the @tank variable needs to be unique to each character.

In order to make this happen all you have to do is not include the variable in any of the packages that use it. This will cause the variable to be created in the window that is executing the script. Then anytime a script being called wants to know the contents of the tank variable it will find the one in that window and not a value from some other window.

This particular rule to the scoping system is about the only difficult one to follow. Once you see it in action it makes sense, and the rest of the scoping/context rules are designed to be so intuitive that no one has to think about what is going to happen.

Newbie Joined: 02 Jul 2007 Posts: 2

Thanks for the tips about Events, Fang Xianfu. While I don't think I can just switch to events completely in this case as you suggested, they should help clear up the issue. I can name the variables something different in each case, and just tell people to raise the event to set them.

Vijilante, while the variable is session specific, there is a prohibition against multi-linking on the MUD, so I don't need to be worried about keeping things specific in that way. If I don't include the variable in any of the packages, when it's created will it just be created in some sort of global scope? If so, that may be the easiest solution; I'd just have to remove the variable from the packages. I'm not sure if it's 'better' than using events though. It might be easier for people to remember to 'tank=someperson' than '#raise TankIs someperson' though.

SubAdmin Joined: 18 Nov 2001 Posts: 5187

If no enabled variable is found to exist within the entire available scope, then the variable is created in the root class of the Window setting that is executing the script.

You can also think of it this way.
Package A is a global package containing a variety of scripts. You run session Mage which uses package A, play for a while, then logooff and quit CMud.

Next time you load CMud you feel like playing session Warrior which uses package A. Do you really want all the values in Package A to contain the last data from Mage? Would you like it to be working with values from Warrior?

If you answer yes to the first question for a variable then it belongs in Package A.
If you answer yes to the second question then the variable should be created in the window that is running the session. The rule is there to let you put the variable in that place.
If you answer yes to both questions then you are still confused.
If you answer no to both questions then it is likely the variable should be in the package and flagged with Use Default.