Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD General Discussion
evdryst
Beginner


Joined: 04 Mar 2008
Posts: 19

PostPosted: Thu Nov 04, 2010 6:42 pm   

Referencing variables
 
How can I refer to a specific variable in a package->window->class? It seems if I just do countit = {%random(3000, 4500)} it creates countit all over the show so I'd like to specify in some way where exactly it should go.

Also, could somebody tell me what the difference is between a module and a window? I see I can convert my windows into modules and was wondering if that would help with keeping the settings seperate since it seems sometimes they use each other's stuff.
Reply with quote
Fizgar
Magician


Joined: 07 Feb 2002
Posts: 333
Location: Central Virginia

PostPosted: Thu Nov 04, 2010 7:30 pm   
 
If you wanted to access the countit variable in a different module or window say one called NewModule from the command line for example you would do something like this:

#var //NewModule/countit {%random(3000,45000)}

As for the difference between a module and window

This is from the help files.
Quote:
A "Module" is a collection of Class folders and other settings, such as aliases, triggers, macros, etc.

You can think of a Module as a "super class".

A Package contains one or more Modules or Windows.


What makes a Module different from a class?

A Module can be "published", which allows the contents of the module to be used from other packages. Modules that are not published contain scripts that can only be used within the same package that contains the module.

A Module can also set which other packages are visible to the scripts within the Module. By default, all other packages are disabled for a module, so a module is completely self-contained.

In the Package Editor you can modify the list of enabled packages for each module.


Module vs Window

A Module is also very similar to a Window. In fact, there is a button in the Package Editor when viewing a Module to convert it to a Window. And when viewing a Window in the Package Editor there is a button to convert it back to a Module.

A Module is like a "non visible" Window. A Window can display buttons, MUD output, a status bar, and a command line. A Window can contain classes and other settings such as aliases, triggers, buttons, etc.

A Window is never "published". The settings within a Window cannot be used from other external packages.
_________________
Windows Vista Home Premium SP2 32-bit
AMD Athlon Dual Core 4400+ 2.31 GHz
3 GB RAM
CMUD 3.34
Reply with quote
Rahab
Wizard


Joined: 22 Mar 2007
Posts: 2320

PostPosted: Thu Nov 04, 2010 7:51 pm   
 
Yes, you can access a specific path using Fizgar's directions.

I'm curious though why your script would be putting new variables "all over the show". Generally this means you have a problem with your script, or with interactions between scripts. If that is the case, specifying the pathname won't help. There are a number of reasons why it might be making new variables instead of using the existing variable. Here are just a few:
1) One of the classes in the tree hierarchy above the variable might be disabled at the time the script tries to access the variable.
2) If there are already multiple variables with the same name, different scripts might access different variables depending on their own scope.
3) If the variable is defined in a window, and the script is defined in a different window, the script will not see the variable and will create a new one.
4) If you have use use threads (i.e. use #THREAD or any of the #WAIT commands) and multiple threads try to access the same variable, they will conflict, and create new variables.

In all of the above situations, using an explicit path will not help the situation. The only cases where an explicit path will help is:
5) You have multiple variables with the same name, and scripts in different modules or windows which have different scopes, some of which see one variable first, others which see a different variable first.
6) You use the #CLASS or #MODULE commands or other means to change the "current directory" of your scripts.

I recommend you try to figure out why your scripts are creating multiple variables, because it is quite likely that using an explicit path will not help.
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Thu Nov 04, 2010 10:46 pm   
 
Quote:

In all of the above situations, using an explicit path will not help the situation.


Actually, explicit pathing always only operates at that location. If for any reason the operation fails, then the operation simply doesn't do anything at all. If you are getting extraneous variables, it's because your explicit-path reference was (accidentally) converted into an implicit-path reference via typo, bug, or unintended parsing result (ie, using the entire value of a datarecord variable instead of just the value of a specific key, or the entire value instead of just the first/last/whatever word).
_________________
EDIT: I didn't like my old signature
Reply with quote
evdryst
Beginner


Joined: 04 Mar 2008
Posts: 19

PostPosted: Fri Nov 05, 2010 12:19 am   
 
Thank you for the help so far. The variables that the triggers are supposed to be using are in the root of the window. The triggers are scattered in various classes. I don't use #THREADs. I do use #WAITs, but I don't even get to those before it all goes south.

For example. I set a variable to either 1 or 0 which I then test later to see whether certain actions should be taken in a trigger based on what the value is. When I set the variable to on (1), the variable, even though it already exist and is enabled in the root, is created in a subclass that isn't even enabled!

All variables seem to be created in this subclass. I have no idea why it's so special. I've renamed it to see what would happen and it just created the variables in the renamed subclass again.
Reply with quote
darmir
Sorcerer


Joined: 10 Oct 2000
Posts: 706
Location: USA

PostPosted: Fri Nov 05, 2010 12:30 am   
 
evdryst,
Can you post the package in xml code? This would make it easier to see what is going on.
_________________
Run as hard as a wild beast if you will, but you won't get any reward greater than that destined for you.
Source: (Egyptian)

Last edited by darmir on Fri Nov 05, 2010 12:32 am; edited 1 time in total
Reply with quote
evdryst
Beginner


Joined: 04 Mar 2008
Posts: 19

PostPosted: Fri Nov 05, 2010 12:30 am   
 
Right so.. I noticed that when I close Settings and open it back up again, classes that were expanded before were still expanded and that "special" subfolder was the first one that is open. I think it was just some kind of glitch because THAT part of it sorted itself out now.

I will try the explicit paths for the other issues I have and see if that helps. Thanks a ton!
Reply with quote
evdryst
Beginner


Joined: 04 Mar 2008
Posts: 19

PostPosted: Fri Nov 05, 2010 3:28 am   
 
How would I use explicit pathing in the following statement?

#if (@teaching = 1)
{
blah blah
}

I will post the package in xml code as soon as I whittle it down to something manageble, there is a lot of mess in it right now :/ I made a backup though, just in case.
Reply with quote
Fizgar
Magician


Joined: 07 Feb 2002
Posts: 333
Location: Central Virginia

PostPosted: Fri Nov 05, 2010 4:37 am   
 
Code:
#if (@//ModuleName/ClassName/teaching = 1) {blah blah}

That should do the trick

Here is a pretty good post about communication between different modules and packages.
http://forums.zuggsoft.com/forums/viewtopic.php?p=113326
_________________
Windows Vista Home Premium SP2 32-bit
AMD Athlon Dual Core 4400+ 2.31 GHz
3 GB RAM
CMUD 3.34
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Fri Nov 05, 2010 4:16 pm   
 
There's a slight incompletion to the module/class syntax that affects datarecord variables. The below doesn't work in some situations:

@//module/class/varname.key

You'll need to use the below to get around this:

%db(@//module/class/varname,key)

For simple variables, though, it's just a matter of replacing @varname with @//module/class/varname like Fizgar shows.
_________________
EDIT: I didn't like my old signature
Reply with quote
evdryst
Beginner


Joined: 04 Mar 2008
Posts: 19

PostPosted: Fri Nov 05, 2010 7:36 pm   
 
I'll keep that in mind, thank you. I've fixed the most intensive trigger class with the expicit paths and everything else seems to behave.. for now ;)

Thanks for all the help, appreciated!
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD General Discussion All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net