Especially the clusters cause a particular headache. The really weird thing is, the clusters do not actually remove empty branches when in a GH-script. When in the cluster editing all would insinuate they are gone but they are still being processed. Caused hours and hours of debugging and unnecessary workaround before realizing.
There have been many topics about that. Itâs a shame that this problem still stands. If itâs too complicated to fix I would like to have some component to put before / after the cluster that could do the workaround and recreate the tree structure for me. Iâm not an expert on datatrees, clusters add some obscurity to making it even harder - the whole situation makes me somewhat anxious and avoid clusters. I would really like to use clusters and do not worry about that.
@dale bumping this. Itâs an old, super annoying bug, please address this.
Empty branches going into a block are removed, i have to populate all my empty branches with nulls before parsing to blocks and then removing them afterwards.
On issue 2: I have a python component failing inside my cluster (when NOT editing it) but i can see it turning red on the mouse over preview. I cannot debug what is going on, because as soon as I enter the cluster it works!?
Just want to add my +1 to get this fixed. I had to come up with various solutions to work around this in the past.
Donât have any examples on hand right now though.
@Alexander_Radne I have looked into the first three bugs you reported above. I believe I MAY have found the error in the empty branches when editing clusters issue. I still need to do some more testing there.
However, I wanted to address the other bugs you mentioned (which I donât believe to be actual bugs). In bug #2, you are feeding the expression component a tree where the first path contains data, but the last three branches are empty. When you pass this into the expression component, it throws an error saying, "Expression generated an error for (x): Left hand value of operator + is Null". This is telling you that the empty branches are getting evaluated as a Null and this is why youâre getting an error. The expression component doesnât necessarily know how to deal with the empty branch, so itâs just returning a Null item in this case (which is also what youâre seeing on the output side). This isnât a bug, but rather how the expression component was coded to handle empty branches.
In bug #3, you have a similar setup as #2, only this time youâre using strings and your passing it into the concatenate component. This time, the concatenate component tries to parse the empty branches and rather than throwing an error (like above) it decides to treat the empty branch like an empty string (basically like itâs nothing). So, then it tries to concatenate the strings together and an empty string plus the â;â character just returns basically the â;â character (which is again what youâre seeing on the output side). Again, this isnât a bug, but rather a conscious decision as to how to treat empty branches (basically show them as empty text strings rather than throw an error).
I hope this helps clear some things up in your original post.
Regarding bug 2, 3 and 4:
Thank you for clarifying that this is actually intended behaviour.
However I do find it unintuitive that the list length of branches is changed i would expect it to work sort of like this. So that an empty input branch would yield an empty output branch.
I donât want to outbid you, but this problem has been bothering me since at least 2020⌠but thatâs nothing⌠the earliest mentions of it date back to 2014⌠Although, honestly, I think I just accepted not using clusters in Grasshopper 1.
Saying all that, check what David Rutten himself wrote about this problem. My hopes for better clusters moved to Grasshopper 2.
The bug involving empty branches when editing a cluster has been fixed. This should be available in the next release of Rhino 8.30. Sorry for the delay!
