ZBrushCentral

Button toggle/switch

I hate asking this as I feel I should be able to get a grasp on this from the Command Reference and documentation on the site. I’m creating some smaller button versions I can drag into the interface to make more room. The thing I’m having trouble is creating a toggle/switch button so that it can indicate it’s state like the ones in ZBrush. The Activate Symmetry button is a good example. Its large and I want to create a smaller version so I can easily notice if I’ve accidentally slipped out of symmetry mode.

I know from the documentation that there’s an issue with switches and I’m guessing that’s the command I need to use to have a button change it visual state.

Does anyone have a simple code example showing a button set up for on/off toggle state like I’ve described?

Thanks!!!

:ex:below For smaller buttons

I appreciate the post Jawa. Unfortunately, I don’t think it really hit on exactly what I needed. But it did prompt me to try a few things out which did lead to a partial solution.

The simple code I got working is below. I’m not sure what I did differently from my first attempt to tinker with the ISwitch command before I made my original post. But this time it worked except for one small problem.

First, what works is that I have a smaller version of the Topological masking button that shows a change in its state when pressed and it turns on or off the topological masking.

The problem is that if the status of the topo masking is changed elsewhere, such as clicking the actual button in the brush menu or switching to a brush that has topo masking on by default, my button’s state isn’t updated. That kinda makes it an unreliable indicator and I’m not sure how to fix that or even if it’s possible.

[ISubPalette,ZPlugin:ProxyTest1,0,,0,,0,0] 
[IConfig,4.31]
[IShowActions, 0]



[ISwitch, "ZPlugin:ProxyTest1:TopoMask" , 
[IGet, Brush:Auto Masking:Topological],
"Topo Mask", 
[ISet, Brush:Auto Masking:Topological, 1], 
[ISet, Brush:Auto Masking:Topological, 0], 
0, 
.5]
[IEnable,"ZPlugin:ProxyTest1:TopoMask"]

It isn’t possible to monitor the ZBrush UI from within a zscript plugin so I’m afraid you can’t do what you want. Although there is a command ([Sleep]) which will trigger code within the zscript when the interface changes, only one zscript plugin can be active at any one, so when another zscript is loaded the previous is turned off completely.

I was afraid that might be the case. I suspected there was reason I couldn’t find ZScripts that did that. Thank you, Marcus for letting me know for certain.

There are a couple of other interface customizing scripts I was thinking about working on. I don’t like tossing them into the forum without having done some work to figure them out on my own but they might not be possible either. If anyone knows that these ideas won’t work in ZScript, let me know. It’ill save me some time at least.

The first is a button that can be used for common settings for a slider. For instance, lets say I typically use the settings of 1, 1.5, 2, and 2.5 for the Alt Brush Size slider. I could create 4 buttons, one for each amount. But if I wanted to save space, maybe I could create a single button that cycles through the 4 different settings. The problem, and what I’m doubting zscript will do, is finding a way to have the button indicate what amount its currently set at. My first thought was to use a variable in the button name that could change the text of the button. But I’m assuming that since the button name is an important anchor to the command, there’s no way its going to let me change it on the fly. (Try not to laugh too hard at that idea if you actually know what you’re doing in zscript. :D)

The next one, assuming the previous idea can’t work, is finding a way to use an ISlider to do more or less the same thing. Instead of the new slider having the full range of the slider I’m basing it on, it could be limited somehow to just the settings I typically use for it. That way the slider could display the amount as part of its basic function. Thinking about it, this might actually be a more efficient way than the first idea and probably more feasible.