# SolveInstance Call Count

**URL:** <https://discourse.mcneel.com/t/solveinstance-call-count/67536>\
**Category:** Grasshopper Developer\
**Created:** [July 24, 2018, 3:02pm UTC](https://discourse.mcneel.com/t/solveinstance-call-count/67536 "2018-07-24T15:02:21Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![peter.ciganek](https://sea3.discourse-cdn.com/mcneel/user_avatar/discourse.mcneel.com/peter.ciganek/32/655907_2.png) [@peter.ciganek](https://discourse.mcneel.com/u/peter.ciganek)\
**Post date:** [July 24, 2018, 3:02pm UTC](https://discourse.mcneel.com/t/solveinstance-call-count/67536/1 "2018-07-24T15:02:21Z")

</div>

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).

I guess I’m using the wrong input logic?

Thanks for any help,

Peter

 ![image](https://global.discourse-cdn.com/mcneel/original/3X/8/9/89b00174b4ad6d9d151999cc8de4f0915a96d35b.png)

---

<div class="post-metadata">

**Author:** ![Dani\_Abalde](https://sea3.discourse-cdn.com/mcneel/user_avatar/discourse.mcneel.com/dani_abalde/32/759411_2.png) [@Dani\_Abalde](https://discourse.mcneel.com/u/Dani_Abalde)\
**Post date:** [July 24, 2018, 3:12pm UTC](https://discourse.mcneel.com/t/solveinstance-call-count/67536/2 "2018-07-24T15:12:40Z")

</div>

You have to set Graft in those inputs of item access when they have more than one item.

---

<div class="post-metadata">

**Author:** ![peter.ciganek](https://sea3.discourse-cdn.com/mcneel/user_avatar/discourse.mcneel.com/peter.ciganek/32/655907_2.png) [@peter.ciganek](https://discourse.mcneel.com/u/peter.ciganek)\
**Post date:** [July 24, 2018, 3:21pm UTC](https://discourse.mcneel.com/t/solveinstance-call-count/67536/3 "2018-07-24T15:21:07Z")

</div>

> [@Dani\_Abalde](#):
>
> Graft

Thanks for responding so quickly!

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.

Peter

---

<div class="post-metadata">

**Author:** ![DavidRutten](https://sea3.discourse-cdn.com/mcneel/user_avatar/discourse.mcneel.com/davidrutten/32/755688_2.png) [@DavidRutten](https://discourse.mcneel.com/u/DavidRutten)\
**Post date:** [July 24, 2018, 3:59pm UTC](https://discourse.mcneel.com/t/solveinstance-call-count/67536/4 "2018-07-24T15:59:08Z")

</div>

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):

1. {A, Distance, 46.089852}
2. {B, Name, A}
3. {C, Name, A}
4. {A, Distance, 107.826009}
5. {B, Name, B}
6. {C, Name, B}
7. {A, Distance, 74.396898}
8. {B, Name, C}
9. {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.

---

<div class="post-metadata">

**Author:** ![peter.ciganek](https://sea3.discourse-cdn.com/mcneel/user_avatar/discourse.mcneel.com/peter.ciganek/32/655907_2.png) [@peter.ciganek](https://discourse.mcneel.com/u/peter.ciganek)\
**Post date:** [July 24, 2018, 4:13pm UTC](https://discourse.mcneel.com/t/solveinstance-call-count/67536/5 "2018-07-24T16:13:18Z")

</div>

Hi David - thanks for answering.

> [@DavidRutten](#):
>
> but whoever is providing the input data hasn’t structured it correctly.

Unfortunately, this is me…

O

> [@DavidRutten](#):
>
> 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.

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).

Thanks for helping,

Peter