 |
Araadan
Wanderer
Joined: 07 Jun 2009
Posts: 65
|
 Posted: Mon Feb 13, 2012 1:53 pm
[zmud-cmud 3,34] #var creates a new variable rather than modify an existing
|
| Quote: |
Syntax: #NEWVAR varname value defaultval
Creates a new variable in the current class. Does not search outside the class for any existing variable of the same name. Normally the #VAR command will search for existing variables and modify their value rather than creating a new variable. You can force #VAR to create a variable in the current class by using the syntax:
#VAR ./varname value |
One of several requests creates a variable of another window, to which access can not get another alias or retrieves a value from a pre-existing variable.
I set the default class(QuestVAR) (see star in the list # class)
structure of the session:
-char_session_window
-ListFunctions module from package library (readonly, no window)
-default_mud_script module (readonly, no window)
-char_map(+room scripts)
-window: channels, quest, say, tell (the window with messages from #capture)
In these last four variables windows are formed, although in char_session_window | QuestVAR are their counterparts. This class is not hidden or disabled.
In the title I wrote that it is a problem already existing in zmud. The problem of creating a new variable, despite the existence of another appears to me regularly since instigated a series of 5, where only the existing script to import an additional. But always enough to erase the "bad" variable and the situation has not repeated the next import script.
For two weeks I can almost do anything with the client, because at each step are lost variables and their values. |
|
|
|
|
Rahab
Wizard
Joined: 22 Mar 2007
Posts: 2320
|
Posted: Mon Feb 13, 2012 3:41 pm
|
I'm having a great deal of difficulty understanding what you are saying. When asking for help, could you please use clearer language? And perhaps the actual code you executed, and the actual results of it? For instance, I can't quite understand what you mean when you say "One of several requests creates a variable of another window". What requests? What window? Exactly what commands are you executing?
I _think_ you are saying that sometimes variables are being created in the wrong place, duplicating variables when you don't want them to, but beyond that I can't figure out what you are saying. You cite the #NEWVAR command, which explicitly states that it will create new variables even if variables with the same name exist in other classes. Are you using the #NEWVAR command? What is it you want to happen? What commands do you execute? What happens different from what you expected? |
|
|
|
|
Taz
GURU
Joined: 28 Sep 2000
Posts: 1395
Location: United Kingdom
|
Posted: Mon Feb 13, 2012 5:11 pm
|
Araadan doesn't speak English and uses computer translation to post on the forums so most of the time the posts don't make much sense.
|
|
_________________
Taz :) |
 |
|
|
Araadan
Wanderer
Joined: 07 Jun 2009
Posts: 65
|
Posted: Mon Feb 13, 2012 5:30 pm
|
quote comes from the official help file CMUD.
one of the aliases
| Code: |
#var invis 0
#var terrify 0
#var aquabreath 0
#var sanctuary 0
#var detecttraps 0
#var sneak 0
#var fly 0
#var passdoor 0
#var float 0
#send affected |
All variable exist.
default class is set
part of the variable is updated, the rest is created in the windows of the quest, tell, say, channels
Addressing #VAR./varname value in my case is not an option. variables are created by the aliases / triggers that are in readonly module.
edit: default class is obviously beyond the read-only module |
|
|
|
|
Rahab
Wizard
Joined: 22 Mar 2007
Posts: 2320
|
Posted: Mon Feb 13, 2012 6:03 pm
|
Are the existing variables enabled? Are all of the classes holding the variables enabled? If the variables or the classes holding them are disabled, Cmud will not see them and will create new variables. Also check whether any other scripts are enabling or disabling classes while this alias is running.
Are all of the existing variables in modules that the read-only module can see?
Are there other scripts in other threads trying to set those same variables? If two scripts try to work on the same variable at the same time, you can sometimes end up with duplicate variables.
Are there other scripts running in other threads which might be changing the current class?
One other thing you can do is, instead of using the full path instead of ./varname. That is, use something like: /class/subclass/subsubclass/varname. By specifying all of the classes, you can ensure that you are specifing the correct variable (as long as all of those classes and subclasses are enabled). |
|
|
|
|
Araadan
Wanderer
Joined: 07 Jun 2009
Posts: 65
|
Posted: Mon Feb 13, 2012 8:42 pm
|
| Quote: |
| Are the existing variables enabled? Are all of the classes holding the variables enabled? If the variables or the classes holding them are disabled, Cmud will not see them and will create new variables. Also check whether any other scripts are enabling or disabling classes while this alias is running. |
The variables are active. Char_window and QuestVAR (default class) are active.
None of the script does not turn on and off.
| Quote: |
| Are all of the existing variables in modules that the read-only module can see? |
Each window has enabled default_mud_script module (read-only).
However, any variable of the windows (quest, tell, say, channels) does not see default_mud_script or char_session_window.
| Quote: |
| Are there other scripts in other threads trying to set those same variables? If two scripts try to work on the same variable at the same time, you can sometimes end up with duplicate variables. |
No, the script debugger and #thread does not show anything suspicious.
| Quote: |
| Are there other scripts running in other threads which might be changing the current class? |
Yes, the onload event sets the default class -> # CLASS QuestVAR |
|
|
|
|
Rahab
Wizard
Joined: 22 Mar 2007
Posts: 2320
|
Posted: Mon Feb 13, 2012 9:10 pm
|
Try using //char_session_window/QuestVAR/invis, etc.
|
|
|
|
|
Araadan
Wanderer
Joined: 07 Jun 2009
Posts: 65
|
Posted: Tue Feb 14, 2012 2:57 pm
|
After 16 hours of testing I can say clearly - it works.
All variables were formed in QuestVAR.
At first I had a problem - the program to crash repeatedly. Script Debugger help, I identified two status bars, and one button, which is falling into an infinite loop. Previously, the problem did not exist.
On the beta forums, I found the same problem in 2008 -> http://forums.zuggsoft.com/forums/viewtopic.php?t=29941
I think that cmud in this section of code has a bug. Should behave according to information from the help file - "Normally the # VAR command will search for existing variables and modify Their value rather than Creating a new variable.".
Thank Rahab. |
|
|
|
|
|
|
|
|
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
|
|
