The “Create set” component fails to provide a helpful output :
Here’s an example : you’ve got a bunch of blocks and you want to reference only one instance of each.
First I create a set of the block names, and then I want a set of the geometry of those instances.
Each time I need to do that, I have to torture my gray matter to remember the twisted chain of components allowing to do that :
Sets are “unordered” collections of unique objects. So as soon as you throw a list of objects into a set, any kind of order you had before is gone. (sets in Python work the same way).
So you may need some sort of scripted component to deal with that uses something like a dictionary to keep track of object<>name relationships…
That’s my point : I’m fine with an output that allows to deal with all cases, except it leaves you with heavylifting to do for MOST PRACTICAL CASES.
Thus my request for another output that will do what folks want directly : something like the “Sort synchronously” feature of the “Sort List” component.
It could be called “Synchronous set” for example.
It’s exactly the same with the automatic grafting that goes on in most components.
Yeah, sure, it avoids problems in “all cases” but it’s a pain in the ass for most practical cases, and I spend half of my time adding “Suirify” (god bless) components to keep my trees nice and clean.
This is the stuff that makes GH such a stiff climb, once you’ve passed the initial fooling around, and it’s a bit sad because it would deserve to be more widely used, including by people who don’t have time to lose with useless intricacies and cold math stickling.
Hey, that’s MUCH smarter than the “Index map” of the “Create Set” component !
You still have the information of all the initial indexes of unique items, except they are each in a separate branch , which makes it DIRECTLY USEFUL.
I don’t mind using plugins, but I secretly hope GH grows a more mature set of native components, inspired by the great work of guys like you, Andrew, David Stasiuk,…
Namely :
-Smart tree management components
-Block referencing, management and baking
The example of blocks cries for pure GH tools as each plugin has it’s own data types, therefore components that are incompatible with either GH or other plugin’s components, etc…
It seems that none of the plugins dealing with blocks has a complete and practical set of components, meaning that one has to assemble them haphazardly to perform all the required tasks…
