Setting up a macro to run on startup

Sorry, just replied to your other post.


I just started a new class today, and my lesson plan was the various ways to customize Zbrush, and I finished up with Creating a startup Macro. Nothing radical, changing startup material, brush settings and the like. SO I recorded the macro, save it, test it, all normal and working. I showed them how to open the macro in the text editor, isolated the section where the 3D object was created, deleted it, saved it…Then the weird part. I re ran the edited macro, and the creation of the primative, conversion to polymesh, drawing to canvas and entering edit mode were still running in the macro. Odd. So I opened it in the text editor again, and that portion was deleted. So I reloaded all macros, re ran it, and it was still running in the macro. So, I quit Zbrush and relaunched, ran the macro, and the 3D object was redrawn and put in edit mode. So I deleted the macro, and recorded a new one, same steps, same results. Thoughts?

Oh yeah, the workstation is a Mac running mountain lion. Zbrush4R5.

Did you delete the .zsc file? The software ran the macro from zsc rather than the text file you edited.

(Slapping my own forehead) Doh! Yeah, that was it. Thanks Doug!

Yes, as Doug says (thanks Doug :slight_smile: ), sometimes the ZSC will not update so it’s a good idea to delete it and restart ZBrush.

Sorry for digging this out again, but I need help again, please. My current version is ZB 4R6.

I have disabled the auto-launch of the lightbox at startup.
When I start ZB without my startup macro everything is fine, but when I’m using my startup macro the lightbox always pops up.

This is what I have in my startup macro:

//ZBRUSH MACRO - Recorded in ZBrush version 4.6
[IButton,???,“Press to run this macro. Macros can be aborted by pressing the ëescí key.”,
[IPress,Document:New Document]
[IPress,Material:MatCap Red Wax]
[IPress,Material:MatCap White Cavity]
[IPress,Transform: Edit]

How can I make the lightbox stay hidden?

Hello, and sorry for digging the thread up.

It is not exactly at startup, but is there a way to launch a script when an object is sent back from Maya with GoZ, as soon as it is updated in ZBrush ?

Not that I’m aware of; But, you could just click a button to run your script.

No, that’s not possible. You’d have to do as Doug suggests and press the macro button, or assign a hotkey.

Erf, that’s too bad… I have a lot of files to process (395), I didn’t want to have to click to relaunch my script each time the object was sent back from Maya. Thanks anyway, I’ll try to find another solution !

a new button called StartupMacro ? where can i find it? Tks

If you followed the instructions at the start of the thread and saved the macro to the ZStartup\Macros\Misc folder and called the file StartupMacro.txt then it will be in the Macro palette.

Hey Marcus, I noticed you or whoever wrote the docs for this page used the same method:


I’d like to point out a couple issues though.

The script on that page is written incorrectly, it has an extra comma after the ISet line, causing it to not compile properly. So the “Home” menu does not actually popup on start. Now if you fix it by removing that comma, there’s another issue, the code will be re-executed if you open up the ZScript view at the bottom of ZBrush, and will continue to try executing. This can be solved by removing the code in the True return of the MemGetSize, but then, you can no longer press the “DefaultZScript” button up top to execute that startup code whenever you want, as that button’s description says it’s meant for.

I believe the correct methodology that should be suggested is to be using VarDef and VarSet, instead of MVars, that way when you press the DefaultZScript button, that function can return false again and redo the code, but won’t keep executing if the script window is opened, making it safe for production.

[VarDef, defaultStartMem, 0] [If, defaultStartMem,, [VarSet, defaultStartMem, 1] //Execute your startup code ][pd]

that works for me :
//Your Startup Options




[TransformSet, (Document:Width*.5), (Document:Height*.5), 0, 100, 100, 100, 0, 0, 0]


[IUnPress,Preferences:Lightbox:Open At Launch]


be careful with the Zstartup master plugin which make the DefaultZscript button on top of Zbrush ui to do nothing.

Hi Invertex,

Thanks for pointing that out, I’ll get it corrected.

The point of using MVarDef is that the memory block persists, so that you can have code only run once per ZBrush session. Your code will run any time the script is reloaded, such as after another script or plugin has been run. (Your code is fine - this may be what you want.)

The new DefaultZScript file I’ve written is:


[IPress,“Zplugin:Misc Utilities:Home Page”]
[IPress,“Zplugin:Misc Utilities:Home Page”]

(I’ve left out the [pd] at the end because no code will run after the Home page button is pressed - control passes to the Home Page launcher script.)

The issue you were seeing with the code running every time you opened the ZScript Window is I think because some commands were outside the [If, statement.

This code will always return true, so if you expand the ZScript menu at the bottom of ZBrush, you’ll notice your script will execute again. This is not behavior most would want, especially if being used in a production setting. (though given the info below, in this particular case it won’t because Lightbox ends up taking control)

Hi Marcus, there was no code outside of the conditional. There seems to be a deeper issue here with how the DefaultZScript file is being handled. Your code works if calling that Home Page button, which you mention is taking control after, so that is shining light on the issue here. I guess by default, ZBrush is not passing control off after the DefaultZScript runs, and thus it will continue to be there to execute when certain interface features are interacted with.

If I swap out the Home Page IPress in your example with a simple material change:


Then the script will result in the behaviour I mentioned, executing whenever the ZScript console is opened, which I assume now is because control is no longer passed to anything else? This is unexpected behavior that isn’t really explained. And I’m not aware of any commands that can tell ZBrush to “unload” the current script, as far as I know you’d have to set next file name to some blank script and call a load on that instead. Is there something we can call to pass control that the user wouldn’t actually see, nor change any settings?

when I tried to download the file from support website, it was impossible to download it, it works now, I can finally see what you expected.
But anyway, I don’t get the point with your not good for production argument.
sorry but what kind of second behavior you want the defaultZscript button to have after the if you click on it after the session has started ?

  1. at session start, the script setup some option for you .
  2. click again after the session start, if you want to reset the zbrush environment even if this do not erase tools which are stacked in the tool panel like it would if you press init zbrush.
    the only thing is that you want to have the homepage script to popup at startup but not if you press the default script button.
    IF yes then my method is not correct, but I safe for production as the code don’t retry endlessly to execute it. it will always return True, and for that reason I prefer to use my method, as I just prevent Zbrush to create persistant mem block when I don’t need that.
    Also it better to have a naming convention for memblock naming, generic name can collide with other plugin which also create memblock at the startup process.

I think you are completely missing the point in my last post. I can already get the intended behavior I want by using a regular Var instead of MVar, I said this in the beginning, this is not the issue. I don’t want the Homepage menu either. The issue, like I explained in the previous post, is that if your startup script does not call something that forces a different script to load, such as Home Page does, then the Startup script never gets unloaded, and thus will be repeated any time the ZScript display is opened. I’m pointing out behaviour that goes against what you would expect the script to do, which is to run, and then unload itself, only reloading when you press the DefaultZScript button.

I believe you are not understanding the issue, because the issue exists even with your script. I will show you a video of what I mean and why I said it is not “production safe” if your code can do things that might mess up a user’s work.

This is your script exactly. ZBrush launches and the star is there. But see what happens when I “accidentally” click the ZScript console expansion at the bottom? Your script runs again and tool is set to Star again, even though I did not click the DefaultZScript Button. So surely you can see how, depending on what a team is doing in their startup scripts, this could easily lead to losses of work.

The key point here is that this does not happen in the documentation example, because in that example, calling the “Home Page” causes a different script to be loaded, preventing this issue from happening, but most people would not know that it works specifically because of that Home Page IPress. I’m saying that this behavior should be documented and now asking if there is some other, more clean method to “unload” our script after it runs without having to bring up the Home Page or load some other script file.

(also I do use my own memory names… But we’re discussing the example here, so I stuck with the generic names to avoid any confusions)

yeah I totally misunderstood the issue sorry.
if you want it to work with a varset then you can try out that

[VarSet, zbTime, [ZBrushInfo, 2]]
[If,( zbTime <= 15.000 ),//cmds
[Note, “a New Zbrush Session starts…”,.1]
[Note, “do nothing”,.1]

here if it check the Ztime info from the top title bar, and if the returned value is less or equal to 15 seconds, then it mean the Zbrush startup a new session.
if the value is bigger, then I run the second part of the if condition.
my personal opinion about all that is that Zbrush should use two different scripts
one for the startup , one else for the script console.
there is no bug, or any issue its just normal behavior, but it make me confuse a lot as yesterday the example code wasn’t unavailable and my personal defaultscript.txt has that issue, that prevent to execute the second condition when pressing the Default script from the top menu.

Hi Invertex,

Many thanks, I get the behaviour you describe with your code. (I’m not sure why I didn’t see it before but I’m not going to spend time trying to find out…)

The behaviour is not restricted to the DefaultZScript. Moving the ZScript Window divider will reload the current zscript, whatever that happens to be. In the normal way this won’t affect the user; only if the current zscript runs code on loading. So, for example loading a zscript with:

[Note,“Hello World”,1]

will display the note every time the divider is moved.

I think this behaviour is left over from early versions of ZBrush when there were no plugins and zscript was used mostly for tutorials. If I ever knew about the behaviour I’d certainly forgotten.

There’s no way to simply unload a zscript, that I know of. So, apart from loading a second zscript, the best way I can think of is to specify behaviour for only when the DefaultZScript button is pressed, so that moving the divider does nothing:

[If,[IGetID,DefaultZScript]==[IGet,Preferences:Utilities:View Window Id],
//code to run when DefaultZScript button is pressed
//code to run once at startup