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.