Reusing Cluster Inputs?

So I’ve been tidying up a simple function in a cluster, and came across something that feels very very simple. Yet I cant make it work and it actually looks like it might not even be possible.

In this example the green line would be superfluous and everything would be much cleaner if I could “re-use” the “Starting Point” cluster input in multiple places. Is there a way to “re-use” a cluster input? I want to put a second “Starting Point” input inside the cluster, (in this case, just below the angle input) while still only having the one cluster input on the outside of the cluster?

You’re already using the Starting Point input twice with regular component inputs (Move and Line), what’s stopping you from making a third connection without a relay?

The number of input hooks will equal the number of actual inputs on the cluster. There’s no way to mark two of them as ‘originating’ from the same source.

Yes I could do this, but that immediately makes the graph less readable as the line is tucked tightly behind the first move node. I’ve always found partially hidden lines to be untidy and annoying.

That’s disappointing. It feels like this would improve the ability to tidy up complex graphs without resorting to more complex indirection techniques like GH_Python and sticky variables, or C# scripts, or plugins like

But at least not complicated :slight_smile:

Relays were designed for tidying up, so my advice is to put a relay into the hook, and connect all your other objects to that relay, including more relays.

Can I add that I would put a data type parameter first, then place the cluster input (don’t connect it yet). Double click the cluster input and define name and nickname (what will be shown as the actual input). Then connect to the parameter of the type you want, but its usually better to use a slightly more generic type than you need, just in case.

That way you can make sure that your cluster inputs are properly defined both in terms of data type and name. Otherwise it just uses whatever you first connect it to and you can never change it. So especially when you use User Objects you have to be super careful. If you have to rename or change the data type of an input, you will have to delete the old one and create a new one. That means that if you have placed the User Object already you will lose all the connections to that input.

I find this behaviour super strange and quite honestly think its a bug (maybe not in the programming sense, but in the UX sense). What usually happens is you make a cluster, then work on it some more, at some point you realise it might be useful in more than one place so you create a user object. Then you update it some more as you go along. So its an iterative process where updating the inputs is an essential part. This also happens when you create a cluster from a selection. All the inputs are auto-generated and you have no way to update them.

@DavidRutten why was that again? Why can’t I rename an input? I mean you can’t even change the description afterwards, which is just ridicolous, because in reality means that nobody ever names their inputs properly or gives them descriptions, because its just too much hassle to have to recreate every single input every time you want to update anything about it, which also means you lose all the connections of the instances of that user object. I don’t get why it was designed like that!? I have never seen that in any node-based programming language that you can’t change anything about inputs/outputs, but have to recreate them.

Pretty please can we get proper Clusters in GH2: that means you can edit inputs and outputs and have the insides of a cluster evaluate the same way as a document (ie. it doesn’t recalculate the whole cluster if an input changes, but only those parts that are affected downstream inside the cluster). Then it would actually make sense to break large patches into smaller parts and not just use clusters for small utility functions.