ZBrushCentral

Deeper into ZBrush--persistence of RoutineDefs, and recursive RoutineDefs

ZScripting Help
#1

Sorry for posting without doing further experimentation and code samples, but I’m on a bit of a time crunch, and suspect that someone here might be able to answer in 30 seconds, rather than the three hours it would take me :slight_smile:

I’m writing code that will enable a user to easily go between different orthographic projections of a model. I got it to the point where all of the views would import correctly into textures (done automatically once the user has located one view), and at that point I refactored all of my code into RoutineDefs, to keep things clean. (I’m a software engineer by trade.) After that, things stopped working. I’ve managed to track down and isolate several bugs. (Figuring out that

[RoutineDef, foo,
…commands…
,]

is illegal nicely occupied a few hours :slight_smile: ) But the ones I’m left with make me think that I’m not properly understanding the semantics of ZScript scope and persistence.

The script sets up several buttons in the user interface (in the Document palette). Originally, each button had its own commands group, all quite similar. I then refactored the commands groups out to a single RoutineDef, with an argument, and in the button definition, the single command in the commands group became [RoutineCall, myRoutine, arg]. Unfortunately, after this my script broke, and I can’t get it to function anymore.

Is this a no-no? Is there a similar way to do this?

In a similar vein, do global variables in a ZScript persist across calls to code in that ZScript? In other words, if I have a global variable set up when the script is initially loaded, will it still be available when my user presses one of the defined buttons? I know about memory blocks, but thought they were only necessary for one ZScript to talk with another.

Thanks yet again,
Ken

#2

If you define a global variable at the start of your script then it should be available to any command that needs it thereafter. If a button changes the value then that value persists until it is changed. Memory blocks are only necessary if you want to reload the script (or make data avaliable to other scripts).

Your code:
[RoutineDef, foo,
…commands…
,]
doesn’t work because you’ve indicated a variable with the comma but not defined one. You don’t have to specify variables with routines but if you do then they need unique names:


[VarDef,var1,0]
[VarDef,var2,0]

[RoutineDef, foo,
...commands  involving variables tmp1 & tmp2...
,tmp1,tmp2]

[IButton,"Press", "Do it",
[VarSet,var1,9]
[VarSet,var2,7]
[RoutineCall,foo,var1,var2]
]
#3

Thanks Marcus. Yeah, I actually did track down that comma/routinedef problem yesterday, it just took me a long time and I was surprised because it’s the only place I’ve found in ZScript that complains about that sort of thing.

Cheers,
Ken