I have that huge definition full of flags that trigger a refresh of some components by expiring them, or even recompute the whole definition.
But there’s lots of possible interactions that will send multiple “True” or “False” boolean triggers :
The result is a lot of unwanted refreshes which sometimes cause infinite loops, and I’m also worried that “False” boolean triggers also make come components recompute uselessly.
That’s why I’ve been looking for a way to filter those booleans as they are recieved to only send a trigger when the boolean switches from “True” to “False” or "False to “True” , which would produce something like this : Only let data pass when it changes.gh (9.5 KB)
You need a custom component that hacks the way GH works to avoid expire downstream objects when an input expires.
Probably is easier to change the way you work with the inputs to adapt it to the GH solver. You can explain better why and how those booleans, maybe there is a way to feed components with just the necessary data instead of trying to filter them.
The point is that if you feed your smart-ass component with two consecutive falses, the downstream definition will be expired two times, ie, each time the slider changes, it doesn’t matter what it outputs because it input is item access, so that component will be recomputed on each new input item and therefore update its outputs, that’s why you get extra falses. It can only be done with a compiled component making a hard hack, or change the problem and use a list access instead. The problem is not well defined to me to understand the global idea, that’s why I asked you a step back to see if there is a solution to your task.
My definition reads blocks (two levels of them) in the file, filters them, does all sorts of automatic properties editing (changing layer properties, adding attributes), allows the user to view the current properties, add some more, and all that by checking stuff out in a database, and has to refresh itself so as to always display the current state of affairs.
Many updates are triggered by “sensors” that only send a “True” when a change in properties or block names has been registered.
Multiple changes can be done at the same time… difficult to know when parallel streams of data run through the definition.
So… no, I don’t think I can really help that there are going to be redundant triggers.
I can funnel them, and use a smart-ass component, but the sad part is that I’m not a smart-ass myself.
You, on the other hand…
GH is not parallel, solutions runs one by one. When an event wants to change an output, what it should do is say to gh that runs a new solution and before that change the object and expire it, so in the coming solution that object will be computed again.
So, why are you recording this flags? or why you funnel them?
Couldn’t you consider a fixed-size bool list and by index to know which event has fired? So instead of getting a flag you get a list of flags with one true and by its index you can know where it comes from.
I’m having a hard time figuring exactly how the data streams in my definition.
If components can only run one at a time, this means that two or more “True” flags never pop-up at the same time.
Therefore, I would need a component that , when recieving a “True” would wait a little bit, and then :
-If it receives a “False” as the next input, would output a “True”
-If it receives a “True” as the next input, would wait a little bit, etc…
I have grouped my flags depending on what I want to update exactly , so I would need such a component on each of those groups :
Time is a measurement of motion, in computing motion is the change of state. Components runs one by one and GH runs solutions one by one, in each of it it runs all expired components. So it could be that two or more components that emits the flags has been expired before ask GH to run a new solution and you could get two or more trues at the same time/state, but that depends on how that plugin works, IDK.
I still don’t understand why you need to do it this way. But I don’t think it’s a good idea to play with time. Take a step back, think about how GH solves the definition, consider those events as state changes in the next solution, and rethink the problem. I cannot help further without understanding.
In the GH SDK, a solution is a run of the GH solver. What tipically component does is to schedule a new solution and just before it happens, expire some componentes to ensure those will be recomputed.
I don’t understand but it is a try, every bool component recorded two times than compared than we can know the one changed from True to False or vise versa.
I would need a simple, graphic representation of this process.
For now, it makes no sense to me because it looks like every component is able to control a recompute and affect every other, which sounds like a complete mess…
