 |
darmir
Sorcerer
Joined: 10 Oct 2000
Posts: 706
Location: USA
|
 Posted: Thu Aug 19, 2010 8:39 pm
Modules and variables
|
Hey everyone,
I haven't played MUDS in about 5 years. I decided to start backup and modify my Auto Eat/Drink package and communication package with CMUD's latest features. Since then modules have been implemented and local/global variables.
Can someone give me an example of the use of a module? I know that it is like a super class. An example would be great.
Also I remember that I tried to work with the local and global variables. Can I get a good example when to USE globals versus locals?
Thanks |
|
_________________
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) |
 |
|
|
MattLofton
GURU
Joined: 23 Dec 2000
Posts: 4834
Location: USA
|
Posted: Fri Aug 20, 2010 1:20 am
|
| Quote: |
Can someone give me an example of the use of a module?
|
| Code: |
Main Window
trigger that captures vitals info (ie, hp, mana, moves) from the prompt
variables containing the vitals info
Super-duper Extended Status Window (ie, a child window that you update with status info)
alias to update SDESW when the variables containing the vitals info changes |
In this example, there's a major problem here in that any setting of any type that is contained inside a window is unavailable to any other setting of any other type in any other window or module. Ergo, the alias that updates the child window cannot be used by the trigger in the Main Window and the variables in the Main Window are not seen by the alias in the child window. In this case, you would want at least the variables and the alias in a module so that both windows can see/use them.
So, basically, a module is just a window without the window.
| Quote: |
Also I remember that I tried to work with the local and global variables.
|
Way back in ZMud, where there are no local variables, if you wanted to save a temporary value you would either have to create a permanent variable (ie, @temp) and keep it forever, or constantly create the variable, use it as needed, and then #UNVAR the variable. Pretty inconvenient, yes?
Local variables ($varname) are variables which do not get inserted into the package file and which do not exist outside of whatever setting you use them in. For example, let's look at a basic inventory display. Typically, an item from the game is going to be colorized and you might wish to retain this color info. However, the color info isn't very easy to work with when trying to do calculations and other codework and so you might wish to have a "plain" version of the item name to use.
#local $plainitem //this line is optional for a=b/#VAR assignments and for local variables used in the %match() function
$plainitem = %stripansi(@colorizeditem)
Additionally, local variables can also take on the role of named arguments in things like functions and aliases. This works pretty much the same as the %1...%99 variables you probably remember from Zmud, but are far more readable and intuitive when you need to figure out what went wrong in your script.
#alias TestNamedArgs($arg1,$arg2) {#print %format("I'm a little teapot, &s and &s...",$arg1,$arg2)} |
|
_________________
EDIT: I didn't like my old signature |
|
|
|
darmir
Sorcerer
Joined: 10 Oct 2000
Posts: 706
Location: USA
|
Posted: Fri Aug 20, 2010 5:06 am
|
Thanks Matt! I appreciate the explanation. I can't wait to start working on this again. I got a lot to learn over again in CMUD, since the last time I wrote those packages when CMUD first came out.
|
|
_________________
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) |
|
|
|
|
|
|
|
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
|
|
