A “picked” panelvalue which pulses 0-1-0 whenever an op is selected, so we can do stuff like showing a components UI whenever the component is picked in a network (just like with regular ops and their UI).
Alternatively maybe a global variable which defines a DAT which gets executed whenever you interact with a node. The kind of interaction could be submitted as an argument (args[]: path_to_op, picked, entered, exited, deleted, added, cloned, renamed, …)
Got a feeling this is gonna be my preferred forum
Achim
Ive submitted it to the database.
Im assuming the OP can be of any type?
A real hackish solution for now:
Place down a mouse, cook always.
Have it execute a script whenever the x or y coordinate change.
The script will track the changes. (opset, opscript, etc)
Cumbersome to be sure.
The “script run when you interact with a node” RFE targets a broader problem area, but can therefore also be used for the “show UI stuff”. What I mean is that it would help to be able to react on changes to the scene. For example, in some component you store paths to other ops in a DAT. Now if you move/rename the target, you got a problem, as the automatic expression renaming you have for standard touch parameters doesn’t work. *1
So if this change would trigger a script, we could use our own routines to figure out what other components need to be changed to compensate for the change. Same for stuff like op added (deleted). If necessary, the script could then additionally load it in a hidden location and set it to clone the definition in that hidden location. In return, when an op is deleted, it could search for any of those master definitions and delete them if no more instances are used in the scene…
Regarding your proposed hack, how will it track changes? I get the script executed, but I only get the CHOP path, names and values as arguments, but no additional info which I could use to find out what changed in the scene.
Achim
*1: By the way, the last time I checked, this automatic parameter renaming seems pretty unreliable (changing wrong parameters) and the UI for it isn’t very friendly (You can’t navigate your scene to check what’s actually affected while the “Change Parameter” window is open). I think in Houdini, I almost never had to worry about this, all was automatic.
maybe the request for an “On Current Child Switch”/“On Current Switch” extension for the opexecute DAT (see viewtopic.php?f=17&t=835) is a better solution to the problem, so this one might be redundant and could be deleted.
