Hello!

Back again with quick one.

I'm basically putting some controls of my network in place and testing it. Along the process I came upon this situation where a "parent" toggle param should not only disable a "child" toggle when value is 0/off, but also reset it to the default value (in this case being also 0/off). Both toggles are linked to some "Switch-if" nodes, but currently if the child toggle was on and I disable the parent one, this value of 1/on remains as such, therefore feeding inadequate data in its corresponding "Switch-if" node.

I tried writing VEX in the Callback Script and the Action Buttom tab, but I really don't know what's expected as logic in either of them. Plus, from what I understand by looking around in Internet... Python is expected, and thus far... I really try stay away from snakes as musch as I can xD.

Is there a way to make this rule alternatively work? If that ain't the case, can someone be kind enough to explain to me how it is done properbly with the provided channels built in Houdini?

It's a rather simple thing and I thought the value would return to default when the "disable when" condition was met, but it doesn't work like that.

Thanks in advance!

* I realized the menu says "cruve" instead of curve; Already changed

That's generally a bad idea for 2 main reasons
1. If you reenable you would have to set the child parm values again, making it a nightmare when you want to toggle just for comparison for example
Which can be even more tedious if for example you control such child parm with expression and your callback would remove it
2. Callbacks setting parm values will make it much more difficult to use that node within other HDAs as setting Parm requires permissions so such Parm would have to be promoted and most likely you would also have make sure to have your code act on referenced parm


better solution is to simply handle the logic inside and if the parent checkbox is unchecked simply ignore the child one that is disabled in UI
Disabling should simply reflect that the inner logic ignores the disabled parm

Yep, I get your point .

Had to read it several times thou xD. But writing some VEX conditions on a spare Attrib Wrangle... I managed to feed that into the Switch-if that handles the incoming curve type (eiter from a file or a drawn curve). Basically if the parent toggle is "on" and so it is the child one, then Switch turns to "1".

I think I also should have shown the curve behavior in each case, as the problem was that in state #3 (from the image I shared) the Switch-if value remained as "1", therefore showing the incoming drawn curve still, while the UI shows it should be one of the presets above (that are also fed from "Switch-if = 0"). So... disabling the parameter didn't re-state the value to default ("0"); that's still something I can’t get my head around.

Also, isn't it funny that referencing a toggle parameter in a parameter expression is taken as an int, but in VEX comes as "off/on" string, and you know... you have to translate that into an int attribute to be fed in a channel. I mean, I keep discovering the subtle (very relevant) differences in approaches between VEX and parameter expressions xD.

Tamte, thanks again; you're becoming my pocket dictionary, beware! xD

Even easier!

Just add another condition to be met in the Switch-if node, right?
So both parent and child toggle have to be "1" for the switch to output a value of 1. I mean, multiple conditions are built-in the Switch-if node de facto, why complicate ourselves : )

It's all up to the logic required
Multiple conditions are definitely easy way to combine conditions that result in a specific stream

But there are also cases when it's easier to branch multiple switch ifs or sometimes even have switch sops with more than 2 inputs, it all depends on the complexity of the controls and how interdependent those options are

Manuloti
Also, isn't it funny that referencing a toggle parameter in a parameter expression is taken as an int, but in VEX comes as "off/on" string,

Not sure what you mean by this, chi() VEX function brings in toggles as 0 or 1 int value

Yeah, there's a great flexibility in "how to build" a network and... control its functions with whatever combination of controls on a menu. When you mentioned this I thought several times on what cases I'd use a Switch with multiple inputs instead of a Switch-if, and it all came down to how different these inputs actually were, etc. This Houdini flexibility to each potential personal scenario is genually amazing.

tamte
Not sure what you mean by this, chi() VEX function brings in toggles as 0 or 1 int value

My point here is that when you retrieve a toggle (boolean) param from a node's interface (right-click, "Copy Parameter") its representation changes depenting on the destination workframe. If I paste it in an attrib wrangle it arrives de facto as chs(), but when being pasted in some other parameter, it does arrive "uncasted" as ch(), an does return a 0-1 value. Yes, it comes with both representations built-in, but if you just paste it in VEX, it firstly comes a chs() and you have to modify it a bit in order to extract the proper 1-0 info.

Here's some example of that:

you are injecting expressions into VEX code, which get resolved into values before code is compiled
it will also not update if you animate the values

so don't use injected Hscript Expressions through:`ch()` or `chs()`
use VEX ch() functions (without ticks) directly, chf(), chi(), chs(), ...

also I usually create parameters directly on the wrangle that are referencing asset level values
and then just chi("corrugated_profile")
instead of reaching to different node's parameters using chi("../CONTROLS/corrugated_profile") as VEX doesnt track dependencies, even though both methods would technically work

Oh, now I see why it's common practice to create these parameters in the wrangle itself, feed them with the reference to the control parameter, and then use them as variables in VEX; so the info doesn't get loaded as Hscript, with the ` `. That or editing when you paste them in the VEXexpression, but... again, the former way you ensure it's gonna get loaded properly.

These back and forward really help me to understand what's the logic behind the functionality of it all.
From a newbie with love, thanks indeed : ).

Manuloti
feed them with the reference to the control parameter, and then use them as variables in VEX; so the info doesn't get loaded as Hscript, with the ` `

it's not necessary to have parameter on the wrangle itself to be able to use VEX ch() functions as mentioned you can use relative path to different node's parameters and still avoid Hscript ``
my main reason is to keep traceable dependencies
and to be able to copy paste the wrangle node as a self contained unit without VEX code directly referencing other nodes