Script not running in the right order

I recently made a script which first places a family on all grid intersections and, second pushes the grid numbers into said family.

The script works, it runs fine however I have noticed on the first run it pushes the wrong grids numbers into the family, running the script a second time works as expected.

Grid identifier.dyn (110.7 KB)

I used some passthrough nodes but that didn’t seem to matter. Anyone able to shed some light? I feel like the script can also be ran better, up to the placement is fine but it then checks all placed families against all grids to determine its position, something the script looks for earlier on but I’m not sure how to extract the grid names based on coordinates.


I am not sure what is going on, for some reason the script doesn’t work as expected at all. Even trying a known working version from last week the script pushes the same grid reference into the family. All I did was run the script in Player, could this have changed/broken something?

The family I used with the script
CA_00_GA_UN_Grid Reference.rfa (412 KB)


I think it may have been geometry scaling related, once set to the largest the script runs ok again (still have to run it 2x though)

@BJozi ,

at the first view…

you wait and pass the same values … ? can you modify that ?



1 Like

Its not necessary, I added it hoping it would mean the next part of the script doesn’t run before it should (I know probably makes no sense). Similarly, I have a passthrough just before it writes the parameters are the end of the script.

@BJozi ,

can you show the script in the run mode… and fly out the keynodes ?

could be a List-Lacing issue…



The first image is from the script when first ran and all the families read grid B2

The second run all the families are identifying the correct grid reference

Comparing both, the clockwork node Element.Location is returning 0 values on the first run, while on the second run there are coordinates. I might have to find another way to get the points for each of the placed families instead of the Clockwork node.

Try using a Transaction node instead of the passthrough right before the clockwork node.

Curious though. You are placing elements at pre-defined points and then trying to get those points again with the get element locations node. Instead of using the element location node, just push the pre-defined points forward into the Point.X and Point.Y nodes.

If you are also having issues with the set parameter nodes at the end, then you will probably need to replace those passthroughs with transaction nodes.

1 Like

I will give that a try later if I can make time for it.

The later part of the script, I think can be better. As you note, I’m placing elements at predefined locations and then calling up those later.

The script places the families at defined grid intersections, but in the script I have to find the grid position again (it does this by checking the X/Y distance to all grids and finding the nearest). It seems like this could be executed better but this is what I found while researching how to do this.

The set parameters nodes are working fine, its earlier in the script where (Element.Location) where it goes wrong and the set parameters node is writing the wrong info.

@staylor that was a quick edit. Transaction End worked (tested once only), however, as you noted, I also skipped the transaction end and used earlier coordinates from the families which also worked.

Is it somehow possible to tidy this last bit up, it grabs each family and measure the distance to the grid lines, then uses this to determine the nearest gridline to the family - the coordinate of which I already know from earlier in the script.

1 Like


I tried to simplify it a bit but hope it helps towards the end goal.

Hi Josip, thank you for simplifying the graph, from looking at it I think that will work. I would have some filtering to with the grids and I think you are taking the grid names and feeding that straight into the family, I’ll have a better look at this portion as I didn’t know how to do it.


Started working my way through the script, your approach is a little different to what I was doing. Will have to take some more time to figure it out step by step so I can learn from it as well.

1 Like

I had some time this morning to try out the script @Josip.Komadina made earlier in the thread.

It didn’t quite work, the grid reference being written to the family parameters wasn’t correct, however, it did put me on the right track!

Looking at the output from the Geometry.Intersect node I made a few smal changes at the end of the script where the grid values are written to the parameter. I noticed it was writing a ref but either in the wrong order, only the first few families etc. Some list levels and a transpose node later it all seems to work.

I think it’s much more efficient now thanks to the script from Josip. I’ve only tested it on 2x projects and it seems to work as well

Grid identifier_20230927.dyn (337.0 KB)


Nice implementation, but I think a few flatten nodes would solve the need for transposing and levels in nodes after.

Hope this helps.

The list.count and list.repeatitem, I didn’t quite understand what they were doing earlier. Maybe I didn’t read the graph right!

I added in a few flatten node, earlier I didn’t because I was having problems with populating the parameters. After adding the flatten nodes the horizontal parameter worked fine, however the vertical was in the wrong order. I noticed it was in the wrong order, which was fixed with a transpose node. I have it all working now.

Thanks you for helping with this one! I was nice to dive into Dynamo again and learn a little more!

Here is the final graph.


Really glad this helped you,

I’ll just explain the logic behind my approach below so maybe it is more clear why I used List.Repeat@L1 and @L2.

I think this topic is closed, just mark something as a solution, glad to help.

Thanks for explaining the graph further and I will mark this as solved