Find nodes and packages in use in a graph

Is there a way to run this on scripts rather than on the open script? I only ask because you would have to freeze so scripts just to analyse them and lots of open close if you want to do it for a lot of them.

Great work though. Love your package and all the help you have provided on the forum.

I did some minor testing with this. I just converted the original graph into a custom node and had it run on the consecutive filepath outputs a few times. It’s not pretty but it does work, and I’ve rarely seen nodes with more than 2 or 3 layers of dependent nodes so it would probably work for the vast majority of graphs.

1 Like

Can’t think of a way. The above node will only handle nodes placed on the active home graph.

1 Like

It seems that the Sastrugi - Audit DYN File node from @Ewan_Opie can do that easily and also reports Zero Touch nodes (but not the associated packages apparently)

1 Like

Hi All,

I started to tweak the Audit node on Friday, with the intention of also including package info for each node. I am confident I have a workflow that will allow the package for each Node to be reported.

My only concern at the moment is that for identification to be successful the audit will need to be run on the script creators PC before being included in a distribution package containing the audit CSV and the DYN. This is because any reference to node package locations for data on which node is from where, can only be done if the packages are present with my old workflow.

Because there is no up to date full catalogue of dynamo nodes online for my workflow to reference this makes the next step interesting. Please correct me if I am wrong. ( is good, hence What.the.node, but I have experienced gaps in it being up to date, and reporting of nodes is wrong packages eg Core nodes being from Zebra… )

Embedding the catalogue of nodes within the script is something I am also looking at, as well as tweaking efficiency on Monday. Fingers crossed :crossed_fingers:t2:

1 Like

Hi All,

Here is my revised node (to be distributed in package in the coming weeks)
Please note that I have only had the ability to test this on my systems architecture, so let me know if you get any different results.


Node capabilities:

  • File Name
  • File Size
  • Workspace Version
  • Total Connectors
  • Unique Node Names, Types, Numbers and Packages (with versions if available)
  • Node Types and Numbers
  • Total Nodes


  • Export Report to CSV
  • Export an Audited DYN containing a code block listing Audit information.
    (Both are placed in the same folder as the original DYN)




This node will only generate package information when used on the creators PC before distribution. This is due to the need to reference script nodes to package node locations locally. (This does mean that the run time for this node can be a little long, as it explores the contents of your package folder/s each time)

So to make users aware of required packages, the Audited DYN could be sent in lieu of the original as no other changes to the script are made apart from adding a code block full of text.

Special thanks to @awilliams for some super python scripting advice!


Enjoy! :wink:


Big ask here, hopefully not too much trouble: Is it possible to also include a list of node names for nodes which are unresolved?

What do you mean by unresolved?
If the node can’t find an appropriate package for the type it will substitute a value, this may be used as a “heads-up”

At the moment it is as below:
Custom nodes = Package Not Found
Zerotouch nodes = The node type as what has been stated in the data already

At least that’s how it was working on my end. :face_with_raised_eyebrow:

1 Like

Lookng forward to trying this tomorrow @Ewan_Opie :grin: will be very helpful when I transition the firm over to Revit 2018 and have all my Dynamo Player workflows ready to go by having all of the correct packages on the server


I’ll try this out on my end once I get Dynamo installed (having some difficulty with the new laptop - bear with me), but my thought was to see if t could break the unresolved nodes (not installed on the system running the analysis) out into a separate list so you knew what nodes would throw issues so as a manager/organizer/lead/power user you could search for the node names you need when a user writes a script with a custom node from a package which isn’t yet in the office’s library, so that hypothetical manager/organizer/lead/power user could make an informed decision on the need for the missing package.

@JacobSmall it sounds from this statement that this node will do what you are describing to some degree :slight_smile: I suppose we’ll both find out once we have Dynamo to try it out!

1 Like

Bingo! Can’t wait to feed in an aggregated list of DYFs to see what happened…

Why do I get the feeling you’re going to make a bunch of valueless custom nodes, make a .dyn using all of them, then delete the .dyfs and then run this node on that .dyn? :rofl:

Just kidding, but I think it’d be cool to somehow integrate the What the Node capabilities within this node for unresolved nodes (and of course, replacing null outputs with something else)


Actually I was going to temporarily archive a useful package like spring nodes… but yeah the combination of ‘what the node’ with the output of sastrugi is more or less what I’ll be looking at. May even put out a blog post or some such type thing… that is after I get my laptop functioning.

1 Like

Just thinking out loud here… but if we’re able to export the audit report to Excel, you could potentially have another graph that checks a location for missing nodes and copies them to your main library.

This is assuming you have a staging or backup location for nodes/packages as well as a “published” library for end users.

1 Like

Good thought and worth consideration. :smiley:

All the scrips I create are saved to my personal drive located on our servers not my computer. Once they are done I move them to an accessible drive for others to use. I have successfully ran your node on scrips in my personal drive and on the open server.

I am able to run your node on the .dyf file you provided for the node. This only works on my computer it does not work on my personal drive or my firms open server. It will not create the .csv or the Audited DYN though. Not sure what’s going on with that.

The CSV files are of the same script. One from my personal drive and one from our open servers.
The image is your .dyf file being ran on my computer.

Thank you for the node @Ewan_Opie, I along with many look forward to your package release.

Add or Remove Revision on Sheets_Audit.xlsx (10.2 KB)
Add or Remove Revision on Sheets_Audit_from Surver.xlsx (10.2 KB)


Also in the spirit of breaking everything nice people give you. It does not work when you feed it 156 dyn files. :sweat_smile: not that it needs to was just checking. It does get the file size of each file though so thats something.

Hi All,

@awilliams informed me of a CSV export error, I believe this is now fixed
(Null Values being passed).

I have removed the last download link and here is the new one:

Sastrugi - Audit DYN File.dyf (251.4 KB)

Also, I have investigated integrating a similar search function to the “What-the-Node” in Rhythm. This got a tad intense, so I have adjusted the Audit node to tell users when a node’s package isn’t found and suggests using the Rhythm node separately.

@Steven I am glad that it functions on your PC. This node was written to process .DYN files, so feeding .DYF file will cause errors.

@JacobSmall and @Nick_Boyts The CSV export could be used for the workflows you describe, let me know how you go!

1 Like

I ALMOST have all my software up and running now (dynamo is the big outstanding one left oddly enough), and should be able to take a look soonish… I hope…

1 Like