Bad practice to have red nodes?

Hi, bit of a general question, but is it okay to have scripts where nodes are sometimes red depending on the data passed to it? Or is it better to aim for always grey nodes? In this example I test to see if a series of curves are closed. For any that aren’t, close them - but in scenarios where all curves are already closed, the node goes red (and I’m then forced to run a ‘Clean Tree’ node afterwards). Should I be scripting this differently?

I mean, usually, red is no go, and orange is just a warning, but if it works for you… It doesn’t really make sense that the component should go red.

I experience this a lot when doing 3D-printing-related definitions and making EXTENSIVE use of Sift Pattern, which leaves a trail of nulls that have to stay there in order for the Lists to be Combined again later

every time Move or Scale are applied to a List with nulls, the component turns red :upside_down_face:

in most cases, red components can be easily avoided by adding a few components to the canvas, usually Stream Gate and Stream Filter, but sometimes also expressions with IFs and similars… but it can become painful, and I often found myself just accepting that a few components will just be red, period

one note on your screenshot, by connecting multiple inputs together into the very same Surface parameter (or even using a Merge component to visualize the wire-connection order) the initial order of the curves might change into something like: {all curves that were initially closed -followed by- all curves that were initially open}, or the opposite, depending on the order the wires were connected

in these cases I would always use Weave with the very same Pattern that “is Closed” provides
this is how it looks with Weave (number on the outline are original curve indexes, while numbers inside are final surface indexes)

while if you Merge or just connect wires sequentially, this might happen:

I also believe if you Weave, you might avoid the Clean Tree?

3 Likes

I do this ever since I learned that the order in which you shift-add wires to an input changes list order. It is explicit and good practice.

Nope. Weave will not stop the Connect Curves component from creating nulls.

Thanks, I was wondering the other day if the order of connecting stuff has an impact. Excellent, I’ll avoid that in future.

Can’t you just put all the curves through Connect Curves? I mean, I haven’t tried this, but won’t it just spit out the closed curves at the other end, or does it try to connect the closed to curves to the open ones?

Unless I’ve misunderstood you, this doesn’t seem to be working - using Weave results in a Null list rather than anything useful?

Firstly, you’ve mismatched the Stream inputs. Curve from Connect Curves goes in Stream 0, List A into Stream 1.

1 Like

Thanks, that was it :slight_smile:

To answer this thread’s title, it depends on whether or not you understand the error message (and component output) or ignore it. I wrote this GH yesterday which uses a Line param to separate lines from other curves. Perfectly valid IMHO:

1 Like

I agree with that, but if you use Weave then those nulls are not picked up in the weaved list in first place :+1: which means that no nulls should be going downstream

Ah. I see. I thought you had meant that using Weave might stop the Connect Curves component from showing red. My mistake.

1 Like

If it was me, I would use a Control Point count to separate lines from other curves but I agree, red doesn’t always mean bad.
Example: if you slice volume with series of planes and one is out of range you will get the red tile too.

My question is, is there a system to the madness? Like do components show red when there is only nulls in the output list, orange on empty output, etc. or are the warning different from component to component?

An error is mostly shown when there is an exception. That exception could happen on many levels within the code involved. It could come from the lowest level. The OS, Framework, Rhino or from Grasshopper. Basically the component has a big try-catch statement and forwards any exception to the output. Both, an error and a warning usually can also be triggered by code. So often the in- and output is validated by some checks and if the developer decided that it qualifies for a warning, info or error, that persons explicitly triggers a message to pop up. Sure this can be very inconsistent. This becomes a bigger problem when you create odd situations, like empty or null containing trees.

I think the whole topic of branching (if else) is not very well implemented in Grasshopper and could be improved. I mean “dispatch” is not even named as “if”. Why?! In any case, it helps to write code for branching, and of course any form of errors are bad. It is not obvious for someone else to judge if you can ignore errors or even warnings. If so, you should definitely comment on this. I would never ignore errors. But if it is the only way to go for, you can/should of course ignore your concerns. In the end its all about documentation. And somehow you need to get the job done…

1 Like