Zugg Software :: View topic

Novice Joined: 18 Mar 2007 Posts: 39

I play with 3 sessions open for my different characters, and i have found when i use an script to gather a info into one variable database it causes a crash, when i check, the variable has had its info stored on another session to the one i was using the script on (the script been only on the session i was actually using). The result is that the scripts fail to find the variable they just created because they are not in the correct session for it to locate.

As a side note, and potentially related; some times variables are created in a random folder i was working on, and when i use the find function to locate the variable, i have 2, one located in the main directory of the session and one located in a sub-folder, if the sub-folder is currently disabled it stops scripts from locating the variable as it seems to prefer using the newly copied variable to the one in the root folder.

Wizard Joined: 22 Mar 2007 Posts: 2320

If a class is disabled and a variable within that class is used in a script, a variable of that name is created elsewhere. This is normal. To access a variable, a number of things need to be true: the variable must be enabled; the class holding the variable must be enabled as well as any other classes which hold the class, all the way up the heirarchy to the package containing the variable, and the module or window containing the variable must be visible to the "scope" of the script calling the variable. If any of these conditions are not true, the variable will return a null value, and if the script tries to change the value of the variable, a new variable with that name is created somewhere else.

It sounds like you need to make sure the classes containing your variables are enabled before you try to use them.

Novice Joined: 18 Mar 2007 Posts: 39

Yeah, thats why im reporting it, because that isnt always happening, i was redoing a script yesterday and i created the variable in the same folder i was writing the script in, and nothing was been stored in the variable, after some head scratching i did a search and i found a second variable of the same name (along with 3 others in the same folder that had no place been in there), in a class that was disabled, namely my 'scan' class that only turns on when i activate scan for 0.4 seconds and then turns off (which i was also not using while i was making the script i would add).

The variables in said second folder had the information that the script had been capturing in them, so...

variables in wrong folders
disabled class, variable storing info
variable in right folder nothing in it, not working, etc.

Wizard Joined: 22 Mar 2007 Posts: 2320

The way you described it, it sounded like the variable you wanted to use was in a disabled class, and you were frustrated because it kept creating a new variable elsewhere. That is the correct behavior--it will not use a variable within a disabled class.

You should check this very carefully. Quite a few of my scripts would not work if Cmud were using variables in disabled classes as you describe, and I have seen nothing like this, nor has anyone else reported it. Check your scripts. Are you certain the class is disabled when the script is trying to store values? Are you using a full pathname for the variable, or just a variable name? Is it possible that the variables in the disabled class contained old data, and did not in fact change when you ran the script? Can you reproduce this problem with other scripts? Can you reproduce it in a new session? Showing us the script may also be useful.

Posted: Sat Jan 16, 2010 1:36 am

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

New variables are created because CMud cannot see the old ones. It could be something related to:

-the visibility of the package (ie, the package with your variable doesn't have a checkmark in the package list for the module containing the calling setting)

-the visibility of the module (window, global, external, local)

-the visibility of the class (enabled, disabled)

-the visibility of the setting (enabled, disabled)

-bugs (interferes with any or all of the above by changing the pointer context--ie, a typo in the delphi variable containing the name of the cmud variable your script is referring to, a reference to this delphi variable before it gets populated, logic errors in the scoping rules, etc)

-corruption (interferes with any or all of the above by changing properties of the data)

Posted: Sat Jan 16, 2010 9:05 pm

Your list is a good one and as a matter of habit I try to eliminate all the possible causes except for the ones I have no control over (i.e bugs).
As for package corruption we have to take into account that a user cannot cause this, or if he/she can, the that is a CMUD bug. So if we eliminate the user, then that leaves CMUD itself as the cause, also a bug. This has been the point of the posts.
Most applications have quirks, so if this variable problem occurred once a month or a year, you could call it a quirk (or a minor bug), but it occurs frequently enough to threaten the use of the client and it has been around for a long time. Just because not everyone experiences the problem it can be said that it is not an important bug. Not everyone experiences the problem because the set of ways one can use the client might be finite but it certainly is very large and not all ways lead to this bug.
I've certainly have spent much time trying to pin down the problem because of the frequency with which it occurs in my scripts.
I do use multiple packages. I do have executables running from secondary window objects (e.g. buttons on MXP-created windows, etc).
I like to keep script elements separate so in many cases the referred variables are in another class, and the class might be in another module, which might be in another package (I do make sure that all the visibility checkboxes are checked).
An specific instance of this problem occurs when I run a script that uses buttons on a secondary window as the script driver, that is nothing happens until the user clicks a button.
I keep the buttons for the window in a class folder attached to the window. After one or more uses of the window application, I find duplicates of the variables within the button folder. I can't claim that this does not occur due to a bug in my scripts, but since I only address the buttons with T+/- I can't think of a direct link to the problem.
Mainly, the variables which are being duplicated have their analogs placed in the main window folder.
In looking at the compiled code, I've noticed that no matter where the variable resides, the scope is always declared as <mainwindowname>. Since most scripts run correctly, I assume that it is an quirk of the decompiler rather than an actual problem.
However, forcing recompilation of the scripts and/or deleting/recreating the variables (cut/paste does the job) does solve the problem temporarily so maybe it is a scoping problem after all,.

Magician Joined: 23 Nov 2004 Posts: 364

This trigger nearly always creates the variable newmissiontime in another session:

#class 0
dboff
#walk @lastroom
mission list
mission accept recon
mission check
#lua {zs.var.newmissiontime=os.time(t)+650}