Zugg Software :: View topic

Beginner Joined: 20 Oct 2006 Posts: 18

Ok, so let's see if I can say this understandably.

I've got two separate classes one to handle my defenses, another to handle my prompt stuff.
Inside the prompt class for instance is an #IF (@nightsight=0) {nightsight} [Nightsight is a defense]
Well, the nightsight variable and triggers controlling that variable are in the defenses class.
Yet for some reason, the prompt class is creating it's own variable inside that class.
So, the triggers controlling the nightsight variable are modifying the nightsight variable inside the defenses class, and thus the prompt class variable value is remaining at 0, so it gets stuck in a loop trying to turn nightsight on.

Basically, for some reason it's treating my variables as local, whereas zMUD typically uses all variables are global. Is there some way I can change this preference setting?

On a completely related sidenote, that I'm not necessarily having problems with (yet), I've a class folder currently turned off, inside that class folder are various variables, triggers, etc. Inside some of those triggers are #IF's that reference variables currently contained in that class. Yet in the display it lists some of those variables as not existing (in red) and some as existing (in blue) despite the fact that the only place there are said variables is within that same class. Any particularly reason why the client is recognizing some, but not others as having a value?

SubAdmin Joined: 18 Nov 2001 Posts: 5182

If a class containing a varible is disabled then that variable is not available. When the variable is not available a new one will be created if you assign a value to that variable. The use of the #CLASS command or the option "Use as default when executing scripts" controls where the new variable would be created. I would suggest making sure that option is unchecked on you prompt class, and making sure you don't have any erronious #CLASS commands anywhere.

CMud does a number of different scoping checks that zMud did not do. With zMud, having 2 variable of the same name always spelled trouble. CMud allows many variables to have the same name by looking for the variable in a specific order. This is a feature that many of us worked very hard to make sure was extremely logical and consistent in behavior. The aim of all that testing was to make it so that there is a semblance of object oriented programming principles. Basically after you finish checking over your settings to make sure there are no reasons for CMud to continue using the wrong variable you can delete them; and that will cause CMud to find and use the right variable.

I am not quite sure why some of your variables are displaying in blue and some in red when all of them are unavailable. If you post a script that consistently does it then we perhaps Zugg would be able to locate the cause.