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
shaun.murray
Magician


Joined: 23 Jul 2005
Posts: 334
Location: Chicago

PostPosted: Wed Dec 23, 2009 2:26 pm   

variables across classes
 
unsure what the issue is, or how to go about starting to find this needle in a haystack. but i've got a window with many buttons, and lots of variable information. however, i'm finding that only a third of the variables are actually being reported from the main class. has anyone else had a similar issue?
Reply with quote
Rahab
Wizard


Joined: 22 Mar 2007
Posts: 2320

PostPosted: Wed Dec 23, 2009 5:37 pm   
 
Your question is rather unclear. What do you mean by "variables being reported"? By "main class", do you mean your session window, or something else? Is there some relationship between the buttons and the variables? You don't explicitly say so, but putting those together in one sentence implies there might be some relationship.

The only logical interpretation that I can extrapolate from your question is that you have a window (probably a secondary window) containing many buttons whose states are dependant on certain variables, but somehow the buttons aren't showing the right states to match the variables. Is that correct? Please give more details. Where are these variables defined? What makes you say that many variables aren't "being reported"? Are you somehow getting null values for variables that should have values, or are you getting the wrong values?

Things to check in general: Are there variables in different locations with identical names? Are the problem variables disabled, or within a disabled class?
Reply with quote
shaun.murray
Magician


Joined: 23 Jul 2005
Posts: 334
Location: Chicago

PostPosted: Wed Dec 23, 2009 5:55 pm   
 
yea, thanks rehab. heh, i was unsure how to get my question out, so thanks for the direction!

basically, yes, you are right. i have a subwindow, that has buttons, with a variable name and the variable itself. basically....

Code:
<class name="info" id="1433">
  <button type="Gauge" autosize="false" width="130" height="23" autopos="false" textcolor="#FF8000" priority="14354" id="1434">
    <caption>autoheal = @autoheal</caption>
  </button>
  <button type="Gauge" autosize="false" width="130" height="23" autopos="false" left="134" textcolor="#FF8000" priority="14342" id="1435">
    <caption>autoregen = @autoregen</caption>
  </button>
</class>


and, as that variable changes, i can see in realtime when that variable changes, so that i can better troubleshoot whats going on with my core on a case by case basis. at least... thats the idea. i know that it should be working, because on the main (session) window i have an experience bar, and as i gain experience, it progresses till cap, and the gauge is full. i have the same button, on the subwindow, same everything, short of position and size, however, its not showing anything.

when i say that nothing is being displayed, all i'm getting is (for example) autoregen = and thats it. not a null or a failure or anything, just... blank. so its very odd.

i'll redouble my efforts to check on the variables and what not while my scripts are active, and verify that they aren't in a disabled state/class. thats a great point. heh. thanks again for your direction sir!!!!!
Reply with quote
Rahab
Wizard


Joined: 22 Mar 2007
Posts: 2320

PostPosted: Wed Dec 23, 2009 7:39 pm   
 
That is actually an example of a null value. The button cannot see the variable, so reads its value as null, which displays as nothing (not even a space).

The problem is that one window cannot use the variables stored in another window. If you want both windows to use the same variable, here is what you need to do:
Make a new module. It can be in the same package as one of the windows, or in a separate package.
Put the variables you want to share into that module.
Check both windows in the Package Editor, look at the menu labeled "List of packages enabled for this window".
Make sure that both windows have a checkmark next to the package containing the module with the shared variables.
Reply with quote
shaun.murray
Magician


Joined: 23 Jul 2005
Posts: 334
Location: Chicago

PostPosted: Wed Dec 23, 2009 7:55 pm   
 
hmmm, i've got a new module created, that i will move all my variables into. however, i don't see where that "List of packages enabled for this window" menu at anywhere. thanks again for all your great help Rehab! =]
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Wed Dec 23, 2009 9:00 pm   
 
Click on the Window object itself. The list of packages will be shown in the same window that you would go to to edit any other setting.
_________________
EDIT: I didn't like my old signature
Reply with quote
shaun.murray
Magician


Joined: 23 Jul 2005
Posts: 334
Location: Chicago

PostPosted: Thu Dec 24, 2009 3:25 am   
 
aaaahhh.... i think i see. when you click on the object. it says on the right side:

List of packages enabled for this w(for me, its cut off after this, so i can't see what it says)
English Keypad
English Directions
Clickable URLs
<session package name>


right? ok. well, the newly created module is under the default session name, and its grey'd out and already checked. so i'm assuming then that while my variables are in one, they are availabe in the other? brilliant! i'll check it out now, thanks again everyone!!! =D
Reply with quote
shaun.murray
Magician


Joined: 23 Jul 2005
Posts: 334
Location: Chicago

PostPosted: Thu Dec 24, 2009 3:55 am   
 
hmmm... i must be missing something. i've circled the two area's that should be showing the same information, yet isn't. i've also got a ss of the package editor. am i looking in the wrong place?






EDIT: Wrong second screen shot URL, fixed. Sorry if there was any confusion. ^^


Last edited by shaun.murray on Thu Dec 24, 2009 2:09 pm; edited 1 time in total
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Thu Dec 24, 2009 7:48 am   
 
Quote:

so i'm assuming then that while my variables are in one, they are availabe in the other?


This is correct by default. However, this can be affected by 2 things:

1)variables in windows are not available to anything but that window. Not even modules in the same package as the window can see it.

2)Variables in modules that are set as Local Only cannot be seen outside of the package they are contained in. You can change this part by clicking on the Module object and choosing another option.
_________________
EDIT: I didn't like my old signature
Reply with quote
shaun.murray
Magician


Joined: 23 Jul 2005
Posts: 334
Location: Chicago

PostPosted: Thu Dec 24, 2009 4:42 pm   
 
alright. i'm really confused now. comparing these two screen shots, there is NO difference between the configurations, just different times.




however, the variables that are actually showing, are hit and miss it seems. so, why is it that a few variables would work sometimes, some never work, and a couple always work? this is so very confusing!

also, why is it that you cannot use variables across different classes? i'm sure there is good reason, but to make it so hard to do that seems a bit funky in itself also. i'd love to make a button, to show quest information on a different window as well, because my session window is pretty full. =[
Reply with quote
Rahab
Wizard


Joined: 22 Mar 2007
Posts: 2320

PostPosted: Thu Dec 31, 2009 3:22 pm   
 
You _can_ use variables across classes. The only restriction is that variables defined within a _window_ cannot be seen by any script outside of that window. Other than that, any script can automatically see any variables anywhere in that same package, and in any packages which it has enabled. I believe that any new module has all other loaded packages enabled by default.

As for your problem, have you checked whether all the joint variables have been moved to the new module? Also check that there are no other copies of the variables elsewhere. If there are multiple variables visible with the same name, then Cmud uses scoping rules to determine which one to use. This can actually be useful in some cases (you could have a variable with a default value visible to multiple windows or modules, but one specific window could have it's own local value). Since this isn't what you want, make sure there aren't any extra copies of the variable elsewhere, such as in the individual windows. If the window couldn't see the variable before, it may have made its own local copy. Also, make sure the variables themselves are enabled, and that every class heirarchically above the variables are enabled.
Reply with quote
gamma_ray
Magician


Joined: 17 Apr 2005
Posts: 496

PostPosted: Thu Dec 31, 2009 6:45 pm   
 
The default for modules seems to be local only, that means by default they are same package only. To use variables in a different package, you need to put them in a new module AND set that module to publish AND enable the package containing the module containing the variables in any other modules/windows where you want to use the vars. It makes sense if you read the documentation, it just sounds like a bunch of steps at first.
Reply with quote
shaun.murray
Magician


Joined: 23 Jul 2005
Posts: 334
Location: Chicago

PostPosted: Fri Jan 01, 2010 4:31 pm   
 
oh man. document? =[ it was in the helpfile!?? ok lemme check. i feel dumb now.


Thread
Documentation wrote:
Since version 2.0, CMUD is completely multi-threaded. This has both advantages and disadvantages. The advantage of being multi-threaded is that CMUD can run multiple scripts in parallel for improved performance and more advanced functionality. The disadvantage of being multi-threaded is that scripts which run in parallel need to be more careful about accessing or modifying global resources (such as variables).

In normal scripting and normal use, you will not notice any changes resulting from CMUD being multi-threaded. By default, CMUD will still execute commands, triggers, and other scripts in sequential order, just like in versions prior to 2.0.

However, certain "wait" commands can now be used to suspend the current thread, allowing it to wait in the background before continuing. When the thread continues at a later time, it will be running in parallel with any other commands, triggers, or scripts.

The commands that will cause a thread to suspend itself are: #WAIT, #WAITFOR, #WAITTHREAD, #WAITSIGNAL, and #SUSPEND. If you use any of these commands in your script, then you should make sure that the rest of the script following the wait command is "thread-safe".

To make a script "thread-safe", you should protect any access of a global resource, such as a global variable, using the #SECTION command. This will create a named "protected" section of code, and only one thread can execute a named section at a time.


so thats why its being prevented from using variables across the different classes, so. that answers why its in place. but still doesn't answer how. hrmm.....


Module
Documentation wrote:
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.


i'll be honest. i can't find where to enable that module across all the classes. whats odd however, is that the session class, uses the variables in that module, but the class that also uses (just displays the contents) doesn't. my head hurts. lol, still looking, and thanks again. =]
Reply with quote
gamma_ray
Magician


Joined: 17 Apr 2005
Posts: 496

PostPosted: Fri Jan 01, 2010 10:25 pm   
 
If you open the settings editor and select that module on the left, it should have an option for Publish: Global, Local Only, External Only. What you want is Global.
Reply with quote
shaun.murray
Magician


Joined: 23 Jul 2005
Posts: 334
Location: Chicago

PostPosted: Sat Jan 02, 2010 11:51 pm   
 
ok, got it. was a lil confused having to make it published AND local. if its local, its already published. right? ok, i've done it. still not updating the information. i'm missing SOMETHING somewhere. for example:

button that has
Code:
bheal: @bheal


but it show's blank

but i type #window debugwindow ~>~>~> @bheal ~<~<~<

and the output in my window is >>> 1 <<<
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Sun Jan 03, 2010 12:15 am   
 
To access a variable in another package:

1)the variable must not be in a window
2)the module the variable is in must not be local (local means other packages can't see stuff in that package)
3)the class that the variable is in must be enabled
4)the package containing the setting that refers to the variable must have a checkmark next to the package that contains the variable
5)the setting (and the class that contains it) that uses the variable must be enabled (this one is pretty obvious, though, since if it's not enabled it won't do anything)

That's all you have to worry about, if you are not dealing with thread issues (you are not dealing with thread issues if you are not using #wait, #waitfor, or the explicit threading commands like #SECTION).
_________________
EDIT: I didn't like my old signature
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