I’d like to open up a dialogue between maxscripters about some of the best practices when writing a script that doesn’t use the reserved words tool, utility, macroscript, or plugin. I’m looking for “the best way” to code maxscripts outside of those formats, which I know is completely subjective to the person writing the code, that’s just the particular way I’d like to script things. After collecting and studying a lot of scripts, I compiled a few examples that I’d like to use as discussion pieces. My aim is to open a talk about why these scripts were built the way they were, and how they could be built differently, so that people can determine their own “best way”. The focus here is not on the code that performs operations, rather how the script was built, called, executed, you get the idea…
Also, I think that all of the authors below are really awesome.
Example 1:
1. used by "GARP" for the voroni fracture script
--------------------------------------------------------------------
( -- start script
global rltFractureVoronoi
try destroyDialog rltFractureVoronoi catch()
rollout rltFractureVoronoi "F.R.A.C.T.U.R.E" width:120 height:207
(
...code
) -- end rollout rltFractureVor
createDialog rltFractureVoronoi 120 207 100 200
) -- end script
Example 2:
2. used by Leon "Melak" Scharnowski for HexLattice script
--------------------------------------------------------------------
fn createHexLattice radius spacing x y Up Poly Grille =
(
...code
)
rollout HexLattice "HexLatttice"
(
...UI
)
try(destroyDialog HexLattice )catch()
createDialog HexLattice 120 155 20 100
Example 3:
3. used by Panayot Karabakalov "Anubis" for baketransform_11 script
--------------------------------------------------------------------
if classOf ro_bakeTM == RolloutClass do DestroyDialog ro_bakeTM
rollout ro_bakeTM "Bake TM"
(
...code
local...
fn...
group...
on... do...
)
CreateDialog ro_bakeTM width:166 \
style:#(#style_titlebar,#style_sysmenu,#style_minimizebox)
Example 4:
4. used by Martin Breidt for overscan 0.2 script
--------------------------------------------------------------------
rollout os_ro "New Image Dimensions"
(
...code
)
rollout about_ro "About..."
(
...code
)
try (
closeRolloutFloater overscanDialog
) catch ()
overscanDialog = newRolloutFloater "overscan 0.2" 200 166
addRollout os_ro overscanDialog
addRollout about_ro overscanDialog rolledUp:true
Example 5:
5. used by Allan McKay for create_animVolume_v06 script
--------------------------------------------------------------------
rollout myGUI "Anim Box"
(
...code
) -- close mygui
createdialog myGUI
Example 6:
6. used by Aaron Dabelow for DebrisMaker1.0 script
--------------------------------------------------------------------
(
try(closeRolloutFloater debrisMaker)catch()
...globals
)
rollout DebrisVariables "Debris Variables"
(
...code
)
rollout DebrisCreate "Debris Creation"
(
...code
)
debrisMaker=newrolloutfloater "Debris Maker" 175 462 198 82
addrollout DebrisVariables debrisMaker
addrollout DebrisCreate debrisMaker
Example 7:
7. used by Martin Dufour and Gabriel Beaudin for newton reactor 1.02 script
--------------------------------------------------------------------
(
Global NewtonRoll
try (destroyDialog NewtonRoll) catch()
Local...
fn...
rollout...
on execute do
(
createDialog NewtonRoll 240 431 thePos.x thePos.y fgcolor:(blue/0.6)
)
)
Example 8:
8. used by Paul Hormis for TiM_Lib scripts
--------------------------------------------------------------------
global TiM_Lib
struct TiM_Lib
(
...code
)
TiM_Lib = TiM_Lib()
Example 9:
9. used by Paul Neale for PEN_SkinTools script
--------------------------------------------------------------------
struct PENskinTools
(
...code
)
penSkintools=penSkintools()
Example 10:
10. used by Neil Blevins for pointTracker script
--------------------------------------------------------------------
(
global...
include...
fn...
)
My first questions:
I was pretty surprised by the similarities between examples 8(Paul Hormis) and 9(Paul Neale). The code is roughly the same with the exception that Hormis creates a global while Neale doesn’t. What is the reason for this? I’m leaning towards using this kind of layout for future scripts.
I was wondering about example 7’s (Martin Dufour and Gabriel Beaudin) use of ‘on execute do…’ as I’ve heard that execute should only be used in a few cases. Is this such a case? If not, why was execute used in this manner? Is this related to how scripts used to be coded (a legacy format)?
I’m also interested in example 3’s (Anubis) use of: ‘if classOf ro_bakeTM == RolloutClass do DestroyDialog ro_bakeTM’. Why test to see if the rollout is of a rollout class? Is this related to global variables in some way? example: if there is another ro_bakeTM global variable present. Am I way off on why this was used?
I wonder about Example 1 (GARP) as well. This particular script seems to be very neat and tidy as everything is enclosed in starting and closing brackets. I think it does the same job as declaring a struct then placing all the scripts code inside of the struct (like Hormis and Neale’s example scripts). Is there a fundamental difference between the struct declaration and just using ( ) to wrap a script’s code in? I’m not talking about accessing a struct’s function like struct.someFunction(), but rather just using the struct as a way to handle the scope for the script. Is there any difference in scope between these approaches?
I searched far and wide, but couldn’t find a script written by Bobo that wasn’t a macroscript – otherwise he’d be on the top of that examples list. Much thanks to any responses/posted thoughts.
To answer your questions,
Example 7 use’s the on execute do method to execute the creation of the dialog whenever you execute the code. This is the same as if you are creating a macroscript. I believe you are confusing this with the Execute command, to execute a string as maxscript code. The execute command is bad because it is all global scope.
Example 3, I believe is using the if statement to check if the dialog has been created. With out being able to see the entirety of the code, my guess would be he creates the dialog in a global variable called ro_bakeTM and by checking to see if that variable is of the class of rollout he can determine if the script has been executed before and if so, destroy the previous dialog created.
Hope that helps.
That helps out a lot! Thanks Chad!
Some of this is kind of covered in the Help, but here are my thoughts about it:
- Example 2 won’t work as designed, because the attempt to close the rollout is made after the rollout is defined. The correct way is to try to destroy the dialog BEFORE it was defined. This way, if an existing rollout class instance is found in the same variable from a previous run, it will be closed. Once the new rollout instance is defined, it is stored in the same variable as any previous dialog and will overwrite it. The new instance will be guaranteed not to be in a dialog, thus the closeDialog() call will always fail and the try()catch() will mask that fact. Chances are hexLattice would leave orphaned dialogs if executed multiple times, at least that’s what the code says. This does NOT apply to RolloutFloaters, you can close the floater after the rollouts have been defined. Thus, Martin Breidt’s example 4. will work as expected.
*Enclosing all code in ( ) brackets is a GOOD THING TO DO. It ensures that any variable inside the code will be implicitly local unless declared explicitly as global or already existing in global scope from other scripts’ declarations. This is NOT THE SAME as enclosing all functions in a struct. The idea behind the struct is that it lets you have one global “namespace” containing all functions and thus it lets you keep all functions global while not having all function names as global. Imagine a library containing 100+ functions (similar to, say, the built-in polyOp struct). If you want them to be visible to any other script, you would have to make them all global, which means 100+ global variables in the global scope. Compare to one global variable containing a struct with all 100 functions – you can still call each function from inside any other script by prefixing the function name with the global struct name, but you have just one global variable and less chance for collisions with other scripts. This also allows you to use relatively short function names “e.g. fn printValue = ()” without worrying that another script might be defining a similar function with the same name – as long as the struct name is VERY unique, you will be safe.
*Back to your first question: If you are defining a library of scripts that is intended to be global, you have two possible syntax approaches (as seen in 8 and 9): You can skip the ( ) outer brackets since you want your code to be global anyway and all the rest is in the struct’s scope, or you can use the ( ) brackets, declare the struct variable as global and then define the struct. Both do exactly the same, but the latter is more conservative and allows for further expansion of the code without accidentally polluting the global scope with undesired variables. Also, it is much clearer to read as it spells out what is global and what isn’t. But ultimately it does not matter.
Bobo – everytime you post I learn a tremendous amount! Thankyou for being awesome!
Ok, I’m back again to bug everyone.
Here is some code I’ve been working on that I plan to use as a template for developing future maxscripts from. Please feel free to rip it apart and tell me if what I’m doing is silly. The code works just fine, I’ve just structured things in a manner that is a mashup of the examples above.
I’m trying to retain the ability to destroy an open version of the script while still allowing the UI to function the way I want it to (via rollouts that can collapse). I can’t do this with a single createDialog, instead I’ve had to resort to using a main rollout, then adding subrollouts into the main rollout. I’ve also tried to keep the struct and the main rollout global, in case another script wants to access either of those. I’m not sure I’m doing that right though, so please let me know if this approach may cause problems in the future.
global SBCcontainerRollout
global stretchyBonesCreatorStruct
--destroy any currently open SBCcontainerRollout
try destroyDialog SBCcontainerRollout catch()
( --start script
struct stretchyBonesCreatorStruct
(
fn searchForSBCchains = (
print "test"
),
fn closeDownWeights = ()
)
stretchyBonesCreatorStruct = stretchyBonesCreatorStruct()
--rollouts for UI
rollout SBCcontainerRollout " Stretchy Bones Creator v1.4"
(
subrollout stretchyBonesCreatorSUB
)
rollout stretchyBonesCreator "Ctrl Options "
(
--define UI
radioButtons ctrlTypeBTN "" pos:[5,10] width:180 height:16 labels:#("Spheres", "P.Helpers") columns:2 default:1
colorPicker ctrlColorPicker "" pos:[230,11] width:45 height:16 color:(color 0 114 255)
spinner ctrlSizeSPN "Size: " pos:[168,11] width:50 height:16 type:#integer range:[0.01,1000,10]
editText ctrlsLayerNameEditText "" pos:[3,36] width:190 height:18 text:"controls"
button setCtrlLayerBTN "Set Layer" pos:[210,36] width:64 height:18
)
--create dialog and add subrollouts
createDialog SBCcontainerRollout 320 710 100 100 style:#(#style_toolwindow, #style_sysmenu)
AddSubRollout SBCcontainerRollout.stretchyBonesCreatorSUB stretchyBonesCreator
SBCcontainerRollout.stretchyBonesCreatorSUB.height = 700
SBCcontainerRollout.stretchyBonesCreatorSUB.width = 300
SBCcontainerRollout.stretchyBonesCreatorSUB.pos = [10,1]
--init
stretchyBonesCreatorStruct.searchForSBCchains()
) --end script
Is this a bad approach? Will this allow the struct and main rollout to be global? For example, lets say that I had another script open that tried to access a function of the struct that is declared above. Would this work because I declared the struct as global? Can scripts even share structs functions in this manner? Sorry if I come across as naive, I’m learning.
Here are some notes:
- The first 3 lines (global definitions and destroyDialog() call) can be inside the script’s body. It does not matter, but it makes things cleaner.
- When a struct() definition contains only functions, you DO NOT need to create an instance of it! Thus the line
stretchyBonesCreatorStruct = stretchyBonesCreatorStruct()
is not needed and actually confusing.
- Since you declared both the rollout and the struct global, you will be able to access them from any other script that is EVALUATED AFTER this one. If a script was run before this one, it won’t be able to see the global struct and rollout unless it provides the same global variable definitions, or uses the :: syntax to specify global variables when accessing them.
In other words, you can either copy the lines
global SBCcontainerRollout
global stretchyBonesCreatorStruct
into any other script you intend to access them from, or you can call them from any other script using something like
::stretchyBonesCreatorStruct.searchForSBCchains()
Since you are prefixing the call with ::, MAXScript will look ONLY in the global scope and if it does not find that global variable when evaluating the script source, it will create a new one with a value of undefined. When the real definition comes later in the loading process, it will also write to the SAME variable in the global scope and suddenly the script run earlier will be able to see and access the struct when actually executed. This obviously assumes that the evaluation and the execution happen in two stages – if the former script actually tries to call the function during 3ds Max startup, it will fail. But if the function call is inside a MacroScript which is only evaluated but not run until a button is pressed, or inside another function that is not run immediately, this approach will work.
In cases where you need the functions to be seen by all other script even at Max booting time, you have to put the global struct definition in an .MS file saved in the \StdPlugs\StdScripts\ folder which is the first folder to be evaluated during startup. If the function calls are done from scripts located anywhere else (like Plugins folders, \Scripts\Startup, UI\MacroScripts and \UserMacros etc., they will all find the struct already pre-loaded.
Several years ago, I had a MasterClass entitled “Rapid Tools Development” which showed a MAXScript template with some UI managing code including automatic saving and restoring of any UI settings, dialog position and size etc. If you have 3ds Max Subscription, you should be able to watch it… You might find it helpful.
Thanks again Bobo!