Seems like a very powerful tool, but it’s missing some key features which would allow this DAT to be the “central” for managing all user/component interactions from inside the component. So here are some RFEs:
A new “On Created” mode, triggered on initial creation (copy/paste, loadcomponent,…)
Have the “On Deleted” mode work if the opexecute DAT is located inside the container that gets deleted
Have the “On Inputs Rewired” mode automatically check all contained in/out ops and report the changed input as an argument.
(Currently you need a seperate opexecute DAT foreach in/out operator instead of just monitoring the parent)
A new “On Inputs Data Change” or “On Inputs Cooks” mode would be very helpful. It should supply arguments in which input op the change/cook happened.
A new “On Current Switch” mode, which gets executed when the monitored operator itself is made current. Alternatively, a change to “On Current Child Switch” mode so that the monitored operator is included. Useful to load/display a components UI when it’s selected in the network editor.
A new “On Clone Start” and “On Clone Finish” mode which get executed right before/after the monitored containers updates itself to the master definition. Very usefull if you, for example, need to delete immune nodes which are not longer existent in the master or if you need a very fine level of control over your clones.
Right on for the OnCreated (like the one I’ve been begging for and instead I’ve got all these hacks lying in scripts…) and also I’m with you on all the other flags, they all look very useful.
I’m trying to compartimentalize cooking , which right now springs up in my self-contained templates, a little everywhere.
While I understand there are ops that force cooking just because of the way they’re set up (ie I just found a select dat using a var ${myvar}_NAME to select, and being watched by another dat for changes, was cooking every frame no matter where it resided… - while I know this there’s just a LOT of combination of things that can trigger slowdowns and they’re hard to track down.
If there was a way to compartimentalize cooking - now… that would be the cooking flag but not really, because first of all the cooking flag seem to take a LONG time to wake up the internal cooks. Then there needs to be something turning it off - and maybe the OpExecute triggered by an op’s input changes!
anyway I’m with Achim on this RFE - and would like to point out I’ve made (partially just for on execute) the same RFE… hopefully it has almost has much value as a Bug report then?!
