OK, more tree management grumbling.
I have this strange behavior whereby a “List item” component will either use the tree structure of the “List” or “Item” input depending on the number of main branches, everything else being the same.
How can a poor soul manage trees if the behavior of the components is not consistent ?
You can bypass whatever grasshoppers automatic way is by right clicking an input parameter and setting it to be the principal parameter.
Hi Michael,
I never quite understood what that “Principal” option meant ; in all the attempts at using it, it did essentially nothing, and it’s also the case here.
Rather, I used “Match tree”, and it did the trick.
Here’s yet another problem I need to worry about to make robust tree management, as if the “raise branching level” behavior of certain components wasn’t enough of a pain in the neck…
So ? What is that “Principal” option supposed to do ?
Sorry, forgot about this.
When GH has to decide on the paths of the output trees, it picks the input that is most complex as a template, seeing as it is probably a good idea to retain as much information as possible. However sometimes that’s not what you want as a user. Instead of pre-processing an input to make it simpler so it no longer becomes the inspiration for all output trees, you can mark a different parameter as the ‘principal’ one from which the data tree layout is harvested.
It’s very geeky, and it was probably a mistake to expose this as an option in the first place.
No, the approach is not a mistake. Why not just call it “Use as output template” … 
// Rolf
Hmm… This is what I guessed it would do, but in fact, it doesn’t work in the above screen capture :
The “L” input in the “List item” component has two levels of branching, and the “i” input has 3.
Using “Principal” as an option in the “i” input does not produce an output with 3 levels of branching, unlike using the " Match trees" component.
