Zugg Software :: View topic

Wizard Joined: 14 Oct 2000 Posts: 1368

1. Create a package A
2. Add to it:
#alias {test} {
text="abc"
#echo @text
}
#trigger {banana} {
text="abc"
#echo @text
}
3. Type "test" in command line to run alias.
4. Observe: New variable in package A. Remove varibale.
5. Say "banana" in MUD to cause trigger to execute.
6. Observe: New variable in main package.

Why does triggers and aliases use different scoping rules? How do I access the variables when they get placed in different packages?

Posted: Fri Mar 23, 2007 11:05 pm

This is correct. Triggers always run within the context (scope) of the window that contains the matching text. So, when the trigger runs, your main window is the active window. On the other hand, when you run the alias, the alias runs within the context of the module that contains it, which is your "A" module.

This is how it works. If you want to force the location of a created variable, you should specify the full variable path and not rely on scoping rules. For example:

#VAR //A/text "abc"

would force it to create the variable within your "A" module.

Wizard Joined: 14 Oct 2000 Posts: 1368

Posted: Sat Mar 24, 2007 12:21 am

Yeah, it's a bit mysterious, especially since you deleted the variable created by the alias. If you left the variable within the package, then the trigger will properly use that variable as expected.

New variable creation has always been tricky. So that's why I prefer that people don't try to rely on default behavior if they really need to make sure they are creating the variable in the correct place.

Because it's certainly possible that some of this default behavior might change over time as I work out bugs and other issues. For example, it's important for the trigger to create the variable within the window containing the text by default. Consider a sample package that wants to capture the hp/mana from the MUD prompt:

#TRIGGER {(%d)hp (%d)mana} {#VAR hp %1;#VAR mana %2}

Now, you *want* these variables created within the window the displays the MUD prompt so that this single package can work for multiple windows. This allows each window to have it's own @hp and @mana variables. You don't want the variables created within the package itself.

So, it's possible that the fact the Alias doesn't do the same thing might be a problem in the alias code that I haven't considered yet. Aliases might get changed in the future to do the same default as triggers.

However, aliases are very different than triggers. While the window context of a trigger is well defined (the text from the MUD within the window fires the trigger), aliases can be executed from scripts all over the place. So it's not clear which "window" the alias is coming from. This is why the alias just defaults to it's own class/module.