Hi @MichaelDonn ,
That’s not entirely your inexperience with Grasshopper List processing that is at fault there. I purposefully made the _rooms input have list access but the _vent_cntrl have item access because I had originally thought that the case of applying the same controls to all of the rooms of a list would be much more common that applying controls to different rooms.
So my thought was that people could just use Grasshopper data trees or copy the component if they really needed different controls for different rooms. Here is how you could do it with data trees, for example:
But I realize this isn’t nearly as intuitive as putting list access on the _vent_cntrl and trying to use some “longest list” logic inside of the component. By “longest list” I mean that:
- If one ventilation control is connected, it gets assigned to all rooms.
- If a list of ventilation control objects is connected that has the same length as the rooms, each room gets matched with the ventilation control of the same index.
- If a list of ventilation control objects is connected that has a shorter length than the rooms, each room gets matched with the ventilation control of the same index until it reaches the end of the list and all other rooms get the last ventilation control object.
Let me know if you think this case will be common and I can switch the component to use a logic like this. The main reason why it wasn’t done at first was that it can make the code a little messy and slightly increase the component run time. So I don’t like to implement it everywhere. But I recognize that there are many cases where the increased human time to figure out the data trees or copy the component isn’t worth the savings in computer time so let me know if you think this is one of these cases.