Hi, as in title. Is there a way to search what nodes are being used in my deployment script folder. Then I can if possible from some packages. Extract the nodes. Create a specific package for deploying onto computers that’s smaller for running.
Open the .dyns in a text editor and look for the ‘dependencies’ section.
Thanks Jacob. We went through something similar awhile ago. That seems to show me the package which I have something in dynamo to find out all packages in scripts. But I’m keen on knowing the specific nodes used from the package in the script
Post a screenshot of your dependencies section (not at my PC so I can’t look).
The list of GUIDs in the nodes section of each dependency should tie to a node and eventually a human readable name so you know which nodes are in use. 
Not too bad once you learn the structure. Python is well suited for the application too. Doubly so as you can leverage the json structure of the file to build the tools out.
I’d recommend that the script developer (assuming you) becomes a template machine for a robocopy setup to other machines. Easier than trying to mine scripts. I make a habit of adding an about note in scripts listing dependencies also which monocle helps with.
Got something similar set up. I’m trying to find the quickest way to get dynamo player opening faster on user machines. Most people arnt using dynamo inside so I thought if I can get all used nodes from custom packages and make one that gets deployed. It could reduce start up time for simple users.
1 Like
I think the challenge you face there is that you’re sort of messing with package structure. Some packages using zero touch wont support deletion of nodes and it’s a bit iffy on terms of use for some i think, as you’re misrepresenting a package’s contents (e.g. if a user wants to learn dynamo and finds clockwork with 3 nodes, they might think it’s a bad package).
For me the better approach may be to develop and maintain a company internal package, borrowing from nodes where needed but using python to develop nodes to suit.
If dynamo is noteably slower you likely have too many packages. Try to cut back any you are using only a few nodes from into native Python maybe
2 Likes
Agree with what Gavin’s saying. However I need a quick fix in the interim as my scripts need an overall and that’ll take what I think is a huge amount of time. However copying used nodes into one package for deployment is working. I know a sin and not all packages have the ability to do that BUT works and could get peoples dynamos opening faster while I build up the courage to rebuild my scripts.
@jacob.small I have no idea how to translate a GUID into human readable but would be super helpful! I can see every script and what packages it uses. But if I had the name of custom nodes then I can build the temp package for deployment much quicker.
I think a newer dynamo shows what custom nodes are in a script? 
I’m going through each script and looking at whats being used and cleaning out a bit anyway. But its scary. Theres an OOTB node and your unsure if didn’t use it because it didn’t work as well 
As noted by Gavin, this might mess with terms which could put you in violation of the copyright for some of the packages.
Also the number of DYF nodes won’t really impact opening all that much - zero touch nodes do but you can’t strip stuff from them.
Also you now have to own the updates and deployment on these going forward forever.
Also this process won’t catch nested nodes.
Also you are making a LOT of work for yourself here.
1 Like
There’s me and one other who’s interested in dynamo in a company of 100 so copywrite should be ok? Also dosn’t get used much. This is a temp solution as I background update scripts to use more inbuilt nodes. When its sused ill move back to packages.
Is 0 touch nodes the ones without dyf files?
Yes, such as Rhythm, Archilab, etc…
Not really. Well unless your lawyers are much better then those of the copyright holder, some of which work at firms with two more zeros worth of employees and therefore likely two more zeros of legal power behind them. Others might be small but they also might have more free time to for such issues.
So if it were me, before I strip anything out of a package I would contact my legal business partner and have them review the license of each package I was about to modify to see what the potential issues are.
That or just not do it.
1 Like
I think some managers might care, others not as much. Personally do what you want with Crumple just don’t ask me to fix it if changing it breaks anything 
For the most part the reasoning most hold for not modifying their packages is along those lines. Often someone will lift in code that still points back to the package developer, and eventually it will break, and someone will go back to them vs the people lifting the code.
1 Like
I shall avoid then. You make a good point. If its the zero touch nodes slowing down opening. What ya gonna do, unless make the particular nodes again.
The biggest slowdown is actually the geometry library (30 seconds on my machine). There is a LOT to that one.