Zugg Software :: View topic

Wanderer Joined: 01 Aug 2005 Posts: 76

I'm a fairly new user to zMUD, but have gotten up and running with programming within it very easily. The most FRUSTRATING complaint I have with zMUD is its damn scope rules. Take the following example.

#CLASS Class1
#VAR testVar 1
#CLASS Class2
#CLASS Class3
#ALIAS setVar {@testVar = 2}
#ALIAS printVar {#SAY test var = @testVar}

If I'm not mistaken, if I execute 'setVar', then a new variable is created in the parent class of Class1, instead of testVar being set. And if I execute 'printVar', 'testVar' is said to still contain the value '1'. Granted, the #VAR command allows you to specify class paths, but the @var = X notation does not. I believe I read somewhere that you can use the notation @../var = X, and that even compiles, but when I try @../../var = X, the alias won't even parse.

Am I seeing the correct behavior here? If so, why are there *different* scope rules when reading/writing variables with the @var notation?

Apprentice Joined: 14 Sep 2005 Posts: 121

To set a variable, you can't just use the @varname, you have to use #var varname value. Though don't hold me to that, I'm still just learning myself

Wanderer Joined: 01 Aug 2005 Posts: 76

No, you can actually set a variables value with the following notation:

@myVar = "this is another way to set a variables value"

And, if I'm not mistaken, the @ is optional. This being the case since some people change the character used to prefix var names, and it helps with making exported scripts usable by everyone regardless of their preferences.

SubAdmin Joined: 18 Nov 2001 Posts: 5187

When using the syntax of:
VariableName=something
The variable is either assigned or created in the current default class. Note that the @ is only used when referencing the contents of a variable and not when assigning it.

In other words zMud has little to no concept of scope. A variable, alias, trigger or any other setting is valid so long as it and the class(es) containing it are enabled. Assignments and creation though take into account the default class. This can be set either through the class option "Set as default when executing" or through the #CLASS command. The full form of most setting creation commands has a class parameter that can be used to veride this default. Further settings can be referenced with the class character notation you were mentioning to provide some sort of scope. However it is best to always complete a portion of script that uses a #CLASS command with "#CLASS 0" to set the default class back to none.