GH: Merge component doesn't preserve order - Bug?

What sort of visual cue do you have in mind to distinguish between values stored under {0} and values stored under other paths?

Consistency is gold. I think think that the entire problem is solved by making that detail more visible.

I’m not sure of what would be best, and how easy you can change the visibility of the wires, but perhaps a dotted line would distinguish a bransch {0;0} from a {0}.

Dashed (- - -) would still show the different bransches, so probably no need to specify the individual bransches in more detail since they already draw you attention as is, while dotted (…) or Dash-Dotted ( - . - . -) could indicate single branches {0;0} ?

Indicators only on Outputs could easily be overlooked while working on the other end of a large definition, while an indicator on the Input would work better. But increasing the number of indicators on input/outputs tends to make the diagrams look messy. Dotted or dash-dotted wires would be a fairly clean indicator I think.

Perhaps dash-dotted wires would be preferred as the wires would then remain more “wire like”, since dotted already seems to have some kind of “pulse” meaning with the Timer components.

// Rolf

1 Like

This just messed head for 15-20 mins!! I didn’t think Merge reorders like that, i was just quickly reordering a list of text by exploding the tree and Merging, Entwine did what i would expect.

This comment/topic saved me. I have been breaking my brain on one single value that didn’t want to mix in with other branches. It would always create {0;0} despite anything I threw at it and the Merge component kept on putting it in the middle instead of at the end (in between {0} and {1}, so it looked like {0}, {0;0}, {1}).

Anyway, I managed to fix this with a simple flatten on the input of the Replace items component. It took me a while as I was messing around with the Suirify component, thinking I had to simplify the branch.

Here is where the single point data came from, as you can see, there is no tree data anywhere in here:

And here is the solution where the branch would cause problems otherwise:
(coming in on the ‘Item’ input on the Replace Items component)

The {3;0} was fixed by doing a Match Tree, and then I used a path mapper command to one-up the branch numbers so that I could merge the tree with another tree later on:
Screenshot 2022-03-01 122651

It was necessary to start at {1} because further down the {0} that was split off at the start mixes back in with the rest.