Zugg Software :: View topic

Novice Joined: 04 Jul 2001 Posts: 32

I have some variables that are changed by buttons. The buttons are in SubClass which itself is inside Class. The variables were initialized either by the buttons or manually created by me.

When I view Class, all of the SubClass variables are there. When I move them to SubClass, they just recreate under Class again.

What gives?

Enchanter Joined: 20 Nov 2002 Posts: 627 Location: USA

ALIAS

Syntax: #AL [aliasname] [string] [classname]
Straight from the help in ZMud

Example: #al rb {ring the bells} {new|other}
this will create the alias "rb" in the class of new subclass other everytime.
#BUTTON 1 {ring} {#al rb {ring the bells} {new|other}} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} "" {} {} {}

Help files.

Novice Joined: 04 Jul 2001 Posts: 32

Yes, that's grand. But having declared VARIABLES and placed them in the SubClass folder, I'd like to assign values with this line:

VariableName=ValueString

When I do this, it doesn't write ValueString to VariableName in SubClass. It creates a fresh new VariableName in Class and leaves VariableName in SubClass holding old values.

MASTER Joined: 28 Nov 2000 Posts: 4817 Location: USA

If you want to specify the class, use
#VAR VariableName {ValueString} {_nodef} {Class|SubClass}

If you insist on using
VariableName=ValueString
then accept the variable going wherever the button puts it.

Novice Joined: 04 Jul 2001 Posts: 32

If you don't know, just don't reply :P

I've gone to the trouble of declaring variables both in the full-text way and by moving them into the SubClass folder. However, the button keeps creating a new variable of the same name in a class that neither the variable nor the button belongs to - not in the root (none), mind you, but in a class.

Given I'm using perfectly legal syntax suggested by the helpfile entry itself, don't you think this is odd behavior on the part of Zmud? I sure as f### do.

MASTER Joined: 28 Nov 2000 Posts: 4817 Location: USA

I do know. If you don't specify where a setting is to be made, it will be made in the default class. This is usually the None class, but there are ways of changing it.

If you want to specify which class the variable is made in, you must use the form of the variable command which allows you to do so. That form is the #VARIABLE command, which follows standard zScript syntax.

The alternate syntax is provided for people who can't break the habits they picked up from other languages. It provides no method of specifying which class the variable is in. It also provides no way of specifying a default value.

I don't find it at all "odd" that Zugg allowed some limited capability for people who don't like to change their habits. What I do find "odd" is people who would rather argue about why their preferred method doesn't work than accept solutions that do.

Novice Joined: 04 Jul 2001 Posts: 32

Then tell me this.. why are other variables updating just fine? Why are THESE variables creating in a Class where even you expect them to create in the None area?

Enchanter Joined: 20 Nov 2002 Posts: 627 Location: USA

oops i now see my mistake, i am always moving to fast and make little mistakes like alias and variable. sorry.

Lightbulb is correct, you must use the write variable command.
You "write" that you have ones that work but the one with the button does not, is this correct?
or do you have others with buttons that work just not this one?
And if it is so important that you figure this out, why don't you post the script here so we all could take a look at it and find the problem.

OH, and it wouldn't hurt to watch you attitude, Alot of people spen there valuable time here tring to help. We know how frustrating it can be, but you get more flys with honey than water.

Novice Joined: 04 Jul 2001 Posts: 32

*EDIT*

Nm... I reinstalled, wiped and started from scratch. I then declared all variables from the command line and it works fine. VarName=VarValue WORKS JUST FINE after the variable has been declared from the command line. It doesn't move them around. Same with #PROMPT. (chew on that, bulb)

However, moving the variables across folders in the editor is not sufficient. Similarly, deleting these variables and recreating them in the proper folder doesn't work. They both really should but I'm happy with the work-around.

Now, megamog, we got where we needed to 'cause you gave me the bit of insight I needed to find the solution (initialize from the command line). Thanks for that :)

DimBulb's posts were not only obnoxious, but misleading.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Mr. sp000n,

I am considered, and consider myself expert on zScript and zMud in general. I will happily defer to Lighbulb's expertise any day of the week. I find your remarks regarding both his knowledge and character to be disheartening and would request that apologize.

While I will agree that no one was able to answer your question satisfactorly, there is no excuse for being rude. All of us are here to help others voluntarily (yes I am volunteer in no way paid, compensated, or representative of Zuggsoft) or receive help voluntarily. As such misunderstandings can and do happen, that an expert misunderstood your request is resonable. Please do not be unreasonable in your future replies, I am sure we will misunderstand you again at some point.

Now for everyone else that ever experiences this problem (specifically variables being created, when the VarName=whatever syntax is used, while a variable by that name already exists). This is caused either by a default class, a disabled class, or 2 different bugs (neither of which could be reproduced reliably enough to make a proper bug report). The majority of the time this is caused by a default class which occurs when importing a script without a closing "#CLASS 0" and can be rectified by doing that at the command line. A disabled class is not searched when assigning a value to a variable and hence will result in a new variable being created in the current default class. Note that these behaviors are not mutually exclusive and can combine to produce interesting results.

Beginner Joined: 09 May 2001 Posts: 25 Location: USA

Thank you Vijilante. While I've not encountered that problem yet, some future scripting may very well include variables held in classes that are disabled at various times. You've certainly ensured that I avoid some hair pulling down the road Very Happy

And I'd also like to thank all of you folks who contribute your time and brain wattage to help us poor muddicts tweak our client. [^]

Novice Joined: 04 Jul 2001 Posts: 32

Listen, V, I've no problems with being corrected or finding out I've been entirely wrong and short-sighted. You'll find my posts have always been courteous, I use the search function to at least try not to be redundant, AND I always post a follow-up message to let ppl know if it worked out. Go ahead, use the search function from your .sig and check up on me.

Lightbulb, whether he was just feeling his oats that day or really is a *****, not only brushed myself and another user with the same problem aside insisting our obstinance caused the problem but also was very rude in response to my request for help deciphering his rather optimized code. I'd much rather he wasn't a dink and we could all be happy together but ain't going to lose sleep over the reality we live, either.

You're welcome to pursue him for an apology. I won't bother reading it if he does.

NOW... I found an interesting addendum to your information. If you use the GUI editor to manipulate your script settings as I do... then leave a class/subclass highlighted when the window is closed or moved to the background... you've opened a default class! Took me a while to figure out this was compounding my confusion earlier.

To reiterate... the folder view can set the default class but doesn't send a #class 0 equivalent upon close.

This a feature or a bug?

MASTER Joined: 28 Nov 2000 Posts: 4817 Location: USA

sp000n obviously has a very limited understanding of courtesy. He thinks it's rude for me to explain that the varname = value syntax is more limited than the #VAR varname value default class options syntax, but considers his posts, replete with insults and slurs to both Zugg and me, to be "always" courteous. I think what really upset him was that I refused to answer his question in another, unrelated, thread dealing with someone else's problem and said that the answer was obvious.

Very well, I'll explain the obvious. The question was:
LightBulb, could you walk me through that #LOOP, plz? I don't follow that %numparam() or %param( %i) bit. Also, what did #NOOP do in this case?

The loop in question was:
#AL roomflag {redit;3;#LOOP %numparam() {#IF (%param( %i) = "dark") {1};#IF (%param( %i) = "nomob") {3};#IF (%param( %i) = "indoor") {4}};0;y;#NOOP}

%numparam() gives the number of parameters to the alias. As it says in the helpfile: "returns the number of parameters passed to an alias." Since this is the first parameter (range) of #LOOP, it controls how many times the loop is done -- once for each parameter passed to the alias (seems obvious, doesn't it?).

%param( %i) gives the ith parameter to the alias. As it says in the helpfile: "return the nth parameter passed to an alias." Since this is in the second parameter (command) of the loop, %i gives the loopnumber. As it says in the helpfile, "The current value of the loop variable is stored into the %i variable for use in the command." That means that the first time through the loop, %param( %i) refers to %1 of the alias, the second time it refers to %2, etc. (seems obvious, doesn't it?).

The helpfiles for these two functions do a better job of explaining the purpose of #NOOP than I can do. This is the one from %param():
"The #NOOP is used to take care of the 'unused' parameters. Parameters are only flagged 'used' if accessed with the temporary variables %1, %2, etc."

Since you have trouble deciphering the obvious, I should also point out that Vij suggested YOU should apologize. But here's that apology that you won't read:

I'm sorry you found my posts unhelpful. I did my best to help.
I'm sorry you found my posts inaccurate. I've reviewed them and still think they're accurate.
I'm sorry you're set in your ways. It makes it difficult to help you.
I'm sorry you found my previous posts rude or insulting. They weren't intended to be. This one was.

"DimBulb"