I put together a gh component to bake blocks from e.g. name, point, scale etc… Each of these input parameters is registered as GH_ParamAccess.item and the solution runs as expected.
Now I would like to add random attribute texts. I thought the best way to structure the input parameters would be as parallel key/value list inputs (GH_ParamAccess.list) - then zip through the lists to add attributes. The values filled from GetDataList have the expected number of items - so the component logic seems to be correct.
However, the solution inserts the total count of the input collection for each item (e.g. - in the image below, 3 inserts are added for A, B and C - if the input was A, B, C, D then each would have 4 instances).
Do you mean in the GH solution or the code? There’s a DataMapping enum named Graft for the IGH_Param object - but this didn’t change anything. If I graft the input directly on the component in the solution, then I get 2x collection count instances.
I think your component works as it should, but whoever is providing the input data hasn’t structured it correctly. If each input has item access, then your SolveInstance will be called with the following combinations of values (only looking at Names, Keys and Values now):
{A, Distance, 46.089852}
{B, Name, A}
{C, Name, A}
{A, Distance, 107.826009}
{B, Name, B}
{C, Name, B}
{A, Distance, 74.396898}
{B, Name, C}
{C, Name, C}
If keys and values are supposed to be handled as lists, then you need to change their access accordingly, but you will still have to graft your Names data.
I think your component is a bit too complicated (it does too many things at once), especially if keys and values are supposed to be equally long lists.
I’d merge the Rotation and Scale inputs into a single Transform, which can be one of your own data types if the native transformation data doesn’t do what you need. Then write one or two components which create this Block Transform data.
So the same with the key+value data. Add another component which accepts a list of keys and values, and outputs a single blob of data which is a collection of all these key+value pairs. Then that blob can be exposed as an item input in your BakeToBlock component. This keyvalue data could even play nice with regular text data, so it can be formatted (and parsed) from strings like "{Distance=46.089852, Name=A}".
This will reduce the amount of inputs to 5, each of which can easily be treated as an item access.
Indeed, I grafted all of the other inputs and it generates just one instance. I’ll start putting together item access as you suggest (I was planning on adding separate X,Y,Z scales, i.e. + 2 inputs - so a single transformation makes much more sense).
