Springs.HostedInstance.ByPoints - is it broken - or at least... fussy?

Hi all - I’m having some difficulty with the Springs.HostedInstance.ByPoints node - this all started when I was trying to create a graphical representation of each door type in my project - I started by generating wall segments for each door type, and then wanted to host the door types in the walls using the custom node. It worked… sort of, except that no matter what I did with lacing, list levels, etc., it either placed the same door type at each wall or placed three or four door types in the same wall, or placed 3 or four door types in different walls and ignored the rest. So… as a test I froze that node and switched my family and types to furniture - this worked just fine - a unique furniture type instance was placed at each wall segment. At that point I assumed there was something funky going on with the custom node, so I put it on the back burner while I did some other things.

Today I decided to revisit, but take things a bit slower - baby steps. And I’ve run into another snag with Springs.HostedInstance.ByPoints. In the graph below, I’m simply getting a list of all wall segments in my project, finding a point on the walls, and adding a single door type to all wall instances at that point. The graph works just fine in Manual mode, but as soon as I switch to Automatic, it hangs until I use Task Manager to kill Dynamo and Revit.

Has anybody experienced similar issues with the node? If I freeze it and use an “out of the box” node to place non-hosted family type instances, I have no problems.

Thanks in advance, and Happy New Year!

Have a look at the attached file: HostedInstance sample.dyn (25.9 KB)

The node is definitely set up differently than the built in nodes and the reason for that is that it’s a custom node with python script behind it. Back wen I originally set it up, I wanted to make the node performant with large numbers of objects and one of the things that helped with that, was limiting the number of times you launch the python interpreter.

If I’d set up the node in a way that each input is a singleton, the node would work fine with the built in lacing and would behave like the native nodes. However it would start a new interpreter instance for each window in each wall. Instead I chose to do some of the replication directly in the script and handle the rest with a bit of list management.

If we feed in one wall and multiple points, all windows will be hosted on that wall. Similarly, if we feed in a list of points and a list of walls, the node will pair each wall with each point at the same index. Both of these cases would be a single script instance.

Finally, if we want to have multiple windows in each wall, we need to chop the list of walls so that we end up with sublist containing just one wall each. That way we still do just one script instance per each wall.

Dynamo has improved since then, so most likely this approach is not necessary any more, tho I haven’t gotten around to changing that node.


Thanks, Dimitar - so in my example (not the one I posted, but my first test) I was taking it one step further - mulitple walls, one instance per wall, but each wall had a different family type associated with it as the hosted object. Perhaps that’s what threw it off?

The type assignment is handled in a similar manner as the host assignment. Try restructuring the lists of types in a similar manner as the walls in the sample and see if that helps.

Will do - I’ll try the List.Chop node on the doors - may be awhile before I can get around to it though.

Dimitar, I wanted to get back to you finally on this. I had a chance to revisit and it’s now working beautifully - I removed a couple of nodes that were from other packages and replaced them with standard “out of the box” nodes. I’m still using your Springs.HostedInstance.ByPoints in the same way I was before. There was something goofy in my logic with those other custom nodes that was causing the problem. I’ve learned a LOT in the weeks since I first started this graph - most of those custom nodes were not needed at all, and after replacing them with a logic flow that uses standard nodes for the most part, it runs much better.

Thanks again for your helpDoor Catalog.dyn|attachment (120.7 KB)