As already reported here [BUG] Cluster input/output names disappear when creating User Object and in countless other topics about issues with cluster i/o properties change after their creation, or during export (either as User Objects or Clusters) I came up with a decent workaround that allows to:
- Export as User Objects, but still export correctly without losing any info on the i/o (1:1 export) without recurring to workarounds like deactivating “draw full names”
- export ancillary blocks, like sliders, buttons, value lists, graphing blocks. In this way the user gets the tools ready to set the meaningful values for that specific input, or short components sequences which allow to keep the input as most generic as possible while still providing the easy way to use that data in the way that it’s supposed to be 90% of the cases
- group all or some of the above and export them too
Say that, I want to quickly reuse this group:
It consists of just ensuring your group has no links outside it, then cluster it again with no i/o:
In this way the cluster of interest (“core”) is contained in a dumb cluster (“container”) and achieves all the bullet points listed above.
Of course, the first time the “container” is created, all the Properties of the core cluster must be manually copy/pasted to the container (icon, description etc..), there’s no way to do that automatically, not even in Metahopper. When updating the core cluster, the container can be updated by just adding anoter instance of it, and editing its content by copy/pasting the new one inside it and saving. If creating multiple instances of the container and then exploding, the GUID of the core cluster is kept and they are correctly instanced.
In my case this improved my workflow a lot by allowing a “group” to be 1:1 exported as user object and grabbed from the tool bar, it is also relatively easy to update (user objects can be deleted via the toolbar and exported again as updated version while Rhino is running)