Hi!
Referring to this other thread, which is relevant:
https://discourse.mcneel.com/t/how-to-manage-a-big-definition-any-tips
I still often find myself in a situation where my code is expected to “split” in two or more ways.
No. Or at least not for me, because I need to read and edit my code often … clusters are too cumbersome to have to deal with.
My solution of disabling every component in a group is not reliable enough, it triggers too many “expiration waves” downhill and many similar problems.
@DavidRutten
A “null” object or a parameter having “no sources” would not stop big parts of code from being executed.
Most trivial example:
and similar things happens with all kind of geometry intersections or point/vector/plane handling.
For example: counting the intersections of a line/ray with a mesh, the code is expected to throw an error if no intersection is found (list length == 0). Problem: if the mesh doesn’t exist, that list IS empty, but for a completely different reason.
More than that orange colored wire, if we could have a new type of “state”, maybe colored red, for example, that literally kills the component is is connected to, similar to “disable”, but more dynamic.
Current situation: (again trivial example, real scenarios are much more complex)
All 3 circles exist, every component actually expired, calculated, used CPU time
Wish: (or something similar)
a “killer” status that pseudo-expire the components, but actually just jumpt from the input to the outputs parameters and go on to the recipients components and do the same, killing everything.
No useless components are expired or calculated, not CPU time wasted.
Only one circle exist.
(then, of course, a couple of component able to read/detect this status might be needed)
I am not saying this is a good solution, just an idea…
Sorry for the text wall. I hope I’ve described the problem decently enough.
The problem is there, I have not find a solution if not “hard coding” every parameter with stream gates… doubling the components and wires in the canvas.