MAXScript supports a limited form of persistent global variables. You declare a particular global to be persistent and the value it contains is always saved to and restored from scene files as they are opened and closed. Therefore, you can keep direct references to objects in the scene in variables and those references will persist across scene save and reload.
You declare a global variable as persistent by prefacing its declaration with the reserved word persistent .
declares the variables foo , baz , and bar to be persistent. From then on, the values in foo , baz , and bar at the time of a scene save are stored in the .max scene file. When that file is reopened, the values in foo , baz , and bar are restored, with an implicit declaration as persistent globals if they are not so already declared.
The current limitation with persistent global variables is that only certain kinds of values are storable in a scene file, and only those types of values are saved and restored across scene saves and loads.
The supported value classes are: AngleAxis, Array, Boolean, Color, Double, EulerAngles, Float, Integer, Integer64, IntegerPtr, Interval, Matrix3, Name, OK, Point2, Point3, Point4, Quat, Ray, String, Struct, Time, Undefined, Unsupplied, and all the MAXWrapper classes (nodes, modifiers, controllers, materials, and so on). All other types of values restore as the value undefined .
In the case of Array, only those values in the array that are in the previous list are correctly saved and restored; others appear as undefined in the restored array.
IntegerPtr loading and saving support was added in 3ds Max 2015. When saving to a previous 3ds Max version, IntegerPtr values will be stored as Integer64 values.
Persistent globals are removed from the persistent globals pool when a File > Reset, File > New, or File > Open is performed, but they will remain in memory as ordinary, non-persistent global variables for that MAX session. Subsequently, persistent global variables declared during a MAX session do not "stick around" and get stored with every other file saved during that session.
When merging or XRef-ing in a file (scene/object XRefs are a special case of merge), when reading in persistent global variables,
If the variable being read from the scene file already exists as a persistent global variable, the value of the persistent global is not overwritten. (It was overwritten in versions prior to 3ds Max 8).
If the variable exists as a non-persistent global variable, the global variable's value is overwritten.
If the variable does not exist as a global variable, a non-persistent global variable will be created. The last 2 behaviors are the same as in previous versions of 3ds Max.
If needed, you can install persistent globals in each new file using a #filePreSave callback. See General Event Callback Mechanism for more information.
However, this behavior also means that variables originally declared as persistent global variables may remain defined as ordinary global variables over multiple scenes while a script is being created or run, yet show up as undefined when these saved scenes are reopened in another MAX session.
Below are two examples illustrating the use of callbacks to handle such situations:
The critical variable is simply re-declared, leaving its value unaffected but ensuring that it is saved as a persistent global within the scene.
During File > Reset and File > New events the critical variable is re-declared and assigned a default value, but during a File > Open event the variable first becomes undefined and is then tested after the file is opened. If that persistent global variable was already present and defined in the scene being opened, the variable would have already been restored as a persistent global variable with its old value. In that case, there's no need to re-declare it as a persistent global since it is already in the persistent global pool and will remain there forever until explicitly removed.
There is one potential problem with both of the above examples: the persistent globals will continue being created by the callbacks for the rest of the current MAX session. Unless this is the desired behavior, this should be avoided by having the created callbacks removed when the script is closed.
FOR EXAMPLE, |
if the script exists in a utility or dialog rollout then the associated close event handler should include a "callbacks.removeScripts" command to remove the callbacks. |
This example also illustrates the advantage of using id: parameter whenever possible. This not only makes removal easy but specific as well, since it avoids accidentally removing callbacks that belong to other scripts. See General Event Callback Mechanism and Utility and Rollout Properties, Methods, and Event Handlers for more information. |
For methods to create, collect, test, show and remove persistent global variables, see the topic Persistents Structure.