I’m working on a complex generative design tool in Grasshopper with Rhino 6. In one part, I create a list of rooms on each floor of a building, and separately, a DataTree containing the number index of each room that each of those rooms connects to. The problem is that “rooms” that are open-to-below spaces do not connect to any other rooms, so their length is 0. Normally this doesn’t cause any problems, but when the final room on the top floor of the building happens to be an open-to-below space, the final list in the connections datatree has 0 length, so grasshopper automatically removes it, which causes a list indexing error in my custom c# component, as the room list and connection datatree now have different lengths.
Is there any way to prevent grasshopper from automatically removing this 0-length list from the datatree? Simply putting a 0 there wouldn’t work, as I use 0 as the index for the first room on the first floor, and forcing the algorithm to put an unused number there, like -1 or 1000, would be a lot of work, since I would then have to code in exceptions for that value in every case that this list is checked (which is many many times). Is this my only real option, or is there a simpler way to allow grasshopper to have a 0-length list as the final list in a datatree?
It’s a little hard to say without seeing a definition, but you could for instance code the Vanilla Grasshopper parts to be part of your scripting component. This gives you more control of how the data is handled at each step!
I honestly don’t think that there is a way of prohibiting certain components from getting rid of empty tree branches. Some components do and some don’t!
Have you identified the component that gives you trouble?
You could always try to rebuild the original tree structure with Match (Match Tree), after another operation has culled the empty branches. This could potentially reinstate the empty branches for some cases.
Instead of keeping two lists you could potentially look into better data structures that could be a good fit, like doubly linked lists or binary search trees.
Each room could be a node that has a list of pointers to connected nodes, or something like that.
Does each room have a fixed number of possible neighbouring rooms?
Well I did manage to solve the problem, though the solution was very strange. I’m using a cull pattern component to remove all numbers that are not one of the room indices, which occur due to connections to the exterior. For whatever reason cull pattern does not normally get rid of empty tree branches, but I had this set of components in a cluster, to keep my solution easier to read and manage, and for whatever reason, a cull pattern component within a cluster DOES get rid of empty tree branches. Anyways I just took it out of the cluster and it works now.