Zugg Software :: View topic - [312B] Unexpected behavior of variables with default value.

Posted: Wed Jan 06, 2010 1:45 am

I have found that if I change a variable that has a defined default value, the new value will only remain while the current script is executing. As soon as the script is finished, the old value will return. This could be by design (i.e. variables with defined default values are really global constants) or it might be a bug.
Also, I've noticed that if I update the value of a variable with a defined default value (that is, I change both the settings value and the default value), the scripts depending on that particular variable are not recompiled unless I delete and re-define (actually cut/paste) the variable.

Magician Joined: 17 Apr 2005 Posts: 496

I haven't noticed this, and I think I would. I use defaults for a lot of things that otherwise wouldn't need it, for the (admittedly minuscule) speed gain, for example my variable storing character details (health, mana, etc.) has a default of empty, and I would definitely notice if that was getting reset.

Posted: Wed Jan 06, 2010 4:49 am

Umm, no, I cannot reproduce this at all. As usual, please provide a step-by-step procedure for reproducing this problem.

When using the "Use Default Value" with a variable, that just prevents the variable from being stored in the database for a speed gain. But CMUD doesn't restore this default value unless you are using the #RESET command somewhere. The scripts that depend upon a variable don't need to be compiled when you change a variable value. The compiled scripts have a reference to the location of the variable. Changing a variable value doesn't change this location, so no recompile is needed.

Magician Joined: 02 Feb 2004 Posts: 364 Location: USA

Like Zugg said, you might have a #reset command somewhere in one of your scripts. If you use an invalid ID/class/name with #reset, then it will apply to -everything-. On that topic, is that a bug, Zugg?

Posted: Thu Jan 07, 2010 12:37 am

I have not had any reason to, nor have I ever, issued a #RESET command.
The problem was observed in the script sequence that runs off the #ONLOAD event. Perhaps there is an implied #RESET at the end of event processing, I don't know.
This is not a spurious problem. I labored over it until I realized the only way to get rid of it was to remove the default flag from the variable. Immediately before the script ends the variable contains the appropriate value (as demonstrated by an #ECHO). As soon as the script ends, the variable goes back to its default value (blank). This script has been running unchanged since 2.37.
On the other matter, I can understand how using a compiled reference to the variable would preclude needing recompilation. However, again, after trying to figure out why as soon as I saved the variable it went back to its original value (more or less the same thing as above, except that in the that case this didn't happened until the script ended), I finally removed the default value and things worked.
The first case occurred while running a script within my standard package. The second, in a blank session.

Posted: Thu Jan 07, 2010 4:52 am

It's possible the OnLoad event runs before variables are set to their initial defaults. I'll check into that.

In the meantime, as I've said many times, if you have reproduced this in a blank session, please post the exact script and step-by-step instructions. The more time it takes for me to reproduce a problem, the less likely it will get fixed. That's why *you* guys are the beta testers here.