Following this discussion on how to list packages and nodes in use in a graph, I thought it could be a good idea to share here what I have tried so far - from what was initially shared by ScubaMan - and see if any improvement could be proposed. For the moment, the graph should list the paths of custom nodes, where the names of the packages can be found, but I have still no idea how to identify which packages the Zero Touch nodes belong to. Any idea, link or contribution are welcome…
You have definitely improved on my original script and have shown so really cool ways to cull data. Thanks for the improvements. I imagine the people on this forum can help with the zero touch nodes.
Not something I have thought about it but I am sure something could be done very similar to to what is being done above.
Just took a quick look at one of the .dyf files and they seem to use the same coding that a .dyn file uses. so you could use this scrip to give you all the nodes names used within a node itself. If you just want the nested custom nodes you would need a list of names to look for.
I think that it is very doable though and another great use for the script.
I made a node that taps the graph’s view model and displays the unique categories (as displayed in the library window and specified in each node’s definition) of all placed nodes. It should work for zero touch nodes. Hopefully it can be of use:
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.
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)
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. (dynamonodes.com 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
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
Options:
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!
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
Lookng forward to trying this tomorrow @Ewan_Opie 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.
@jacob.small it sounds from this statement that this node will do what you are describing to some degree I suppose we’ll both find out once we have Dynamo to try it out!
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?
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)
I think this Audit DYN File node 
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