Unexpected result when grafting

I could have sworn that in the past, if I grafted a simple list, I got {0;0}, {0,1}…etc, regardless of how deep into my definition the component outputting that list was.

But I’m getting this:

From grafting this:

The seam component has a bunch of other stuff before it. Am I nuts? Has this always been the expected result? Or did I change a preference or add a weird plugin that’s changing GH’s behavior?

Also, here two simple lists, connected to point container, become two different trees of different length. Is this normal?

Can you send a sample?

I’m seeing this in both Rhino 7 and the WIP, which seems normal to me:


This is the standard behaviour, even though data is stored in a list it still has a path that is not necessarily {0}. Especially if you have a lot of components in a row.

There are workarounds… (flatten everything - usually a bad idea ; Trim Tree or Shift Paths - robust, but tedious ; Suirify - still tedious ; Smart Merge - my own solution to these tree structure problems).


smart merge? I did a search and it’s something you built, apparently. Is it available? Or would it be a bad idea for me to use it because it isn’t very widely used and it could break things if I want to share them with others?

Thanks for the reply. I think the reason I got surprised by this was just a lot of time away from GH. Looking back at older definitions I’d built, it seems I’d gone with the tedious trim tree/shift paths method most of the time, and I’d forgotten just how often I’d needed to use those components.

I think this remains the best practice when working with definitions, if you want to keep them the most stable/least brittle. The resulting behaviors are often annoying, but components add paths every time the possible result of a component would require it, whether it does or doesn’t in any given instance. This makes the definition behave predictably, even if you need to continuously manage the garden by shifting paths, so to speak.

1 Like

yeah that tedium has so far been the only way that I’ve been able to get definitions to be robust with varying input tree structures. I try to do my testing by having a stream filter up front, using it to make sure that a single input and multiple inputs both work every time I add more function to the end of the definition.