How to better organize complex scripts so they don't get crazy messy?

Hey everyone,

I was just wondering if anybody had any hints or tips for ways to simplify/organize large grasshopper files. Obviously good layout and efficient and orderly component use/placement is key, but beyond that, I was hoping there might be some advice that people here could give on how they keep their complex GH documents laid out/arranged so that it doesn’t end up looking like this:

Any tips? Thank you very much in advance!

When you find yourself copy/pasting the same code over and over, data trees are often the best way to tidy things up.

1 Like

You can hide the wires in right click menu too but try not to hide major wire that you lose the flow
Also you could use group / bundle

1 Like

Something similar to this system has worked for me. That and using the Telepathy plugin to send relevant data where it’s needed, instead of spaghetti wires.

2 Likes

One thing not mentioned so far that helped me a lot, is to create “file-referenced” clusters (alternatively use hops, but I find it less easy to work with).
Those .ghclusters files can be edited once only and you can then easily propagate your fixes/changes for a certain functionality.
That’s useful when some clusters are often re-used, and are not all at the same “nesting” level.
For example your block would be once at root level, and once inside another block.

For example, let’s say you have a block of components that you need that more than once, I would suggest doing the following :

  1. Clusterize those components. Before doing so you can create small wire relays at your input / output locations. By doing so you can easily give names to your IOs.
  2. Selecting all components from your block, but not the wire relays, mouse middle click → cluster
  3. Enter your cluster just created, name your cluster inputs and outputs properly (you’ll thank yourself later).
  4. Save the cluster and go back to parent
  5. Right click on the cluster, fill-in properties (again, you’ll thank yourself later)
  6. Finally, right click again, and save & reference file.

If you have nested clusters, and blocks being re-used at different nesting levels, that’s super practical.

Because the files are referenced on your file system, it allows you to manage the clusters separately and propagate your changes quite easily. If you have such a case, I can recommend this post that provides a one-click solution to update your clusters automatically and recursively.

Hope this helps, don’t hesitate if you have questions.

All the best

To go even further than “file-referenced” clusters, you could use the DefinitionLibrary plug-in to save them in a library that keeps track of versions and adds meta data like tags so that you can search and find your own useful clusters again in the future quite easily.

When you publish a cluster to the library it displays the name and version above it like so:
image

And when you want to find and import a cluster into a GH file, here’s what the plug-in’s search/import pop-up looks like:

It even saves the descriptions you enter in the properties (which @Laoky mentioned) in markdown files in the library and you can also see the contents when you select a line in the search results (in the bottom-left box in the screenshot above).

The library is currently stored in repositories on the GitHub platform, but support for more platforms will be added in the near future. There is a one-off GitHub set-up process (I demonstrate this in a video on this page).

Full disclosure: I wrote this plug-in, and thought this conversation was a particularly relevant one to contribute this little ‘ad’ for the plug-in.

It’s currently free as it’s in beta, but when it goes into production if you want to use private repositories then there’ll be a small yearly fee of no more than US$20.

So if you’re open to that, and the efficiency benefits you get with easier re-use of your common logic, then it’s available on Package Manager (if you have the “include pre-releases” checkbox set).

Enjoy! - Nic

2 Likes