Windows. version 099 2017.13460
Attached is the file I’m testing this on.
Not sure if this is a bug or a misunderstanding on my part.
I have a script CHOP inside of a Base container.
Its onCook() method adds 1 to an entry of a table DAT on the same level, so every time it cooks, this value should increase by 1.
As input to the Base I have a button.
So, Button -> Base[In->Script->Table->Out]
Whenever I click the button, I see no sign of activity, until I dive into the Base node, then I see the updated value. If I click multiple times on the button and then dive in, I only see the value increase by 1, not the number of times I clicked on the button.
Likewise, if I attach a node to the script that is always cooking, for example Clock, then what happens is that whenever I copy and paste the Base, the new one does not cook until I dive in to it, then it cooks for the rest of the session. If I restart Touch, I have to do this with every Base container to get their script CHOPs to start cooking. I can even verify with the Performance monitor that cooking does not happen until I dive in.
ScriptCHOPInBase.1.toe (4.81 KB)
Script Ops are tricky, for sure, so rest assured that you’re not alone in fighting with them.
Cooking is often related to data flows in your network. Touch is a pull based system, so things that aren’t being used / visualized don’t cook. Your script CHOP isn’t cooking until you dive into your network to look at it, which is why the value updates only once you’ve looked inside. You’ll see the same behavior if you turn of the viewer of your Script CHOP and click the button - the value won’t update. All that to say that what you’re seeing is actually the expected behavior of the Operator.
What to do then?
I think the better op to chase for this use case would be the CHOP Execute DAT or Panel Execute DAT. You can use these to fire a script when a value changes (CHOP Execute), or when a panel is interacted with (Panel Execute). Similarly, the Count CHOP does exactly what you’re doing here and might be worth looking at using.
Hope that helps.
Thanks Matthew for the reply! I would do the CHOP Execute DAT, but I need to always be cooking, or have some way of calling a function as long as some value is true, is this possible, looks like it only responds to impulses?
Basically I am creating a custom timer object, but I want it to only make downstream nodes cook whenever its value changes, so this script CHOP looked the solution since in its script I have it to only send its value to the table DAT if the timer is turned on. All the other timer based CHOPs that take an impulse and send out a value over a specific length of time (timer, trigger…etc) are always cooking even when they are not in timer mode, forcing my downstream nodes to cook as well.
Maybe I am too concerned about having all my downstream nodes cook, but it seems like a wasted optimization since I’m using timers to animate properties all over the place.
Ahhhhh - I see.
Before you pull your hair out on this, consider adding a null with the cook type as selective. Nodes connected after the null, or exported form the null will only cook when the value changes, but not all the time. I think this actually does what you’re looking for and means you don’t have to re-invent the wheel, so to speak.
Does all of that make sense?
Interesting! I didn’t know about this feature, that does exactly what I want and makes my life much easier. Thanks again for your help!