Currently it appears that an object has to exist within the Rhino document in order to have User Text assigned to it in Grasshopper and then you need to bake said objects for the user text to appear on the Rhino document objects.
While the latter part makes sense, can we please have the ability to set User Data on Model Objects PRIOR to baking, allowing us programmatic control over setting up our desired Key/Value pairings and then having to bake the new attributed Model Objects only once. (Similar to how Elefront allows you to assign Elefront attributes prior to baking)
Obviously the Model Objects node replaces the assign Elefront attributes node with the distinct difference that the Elefront version allows user text to be set and the Model Objects and Element User Text are two separate nodes/operations in the new Rhino WIP nodes.
@AndyPayne what are your thoughts/intentions with the User Text node?
Thanks for bringing this up. We actually found a few bugs earlier in the week in the User Text component and have been fixing them. Hopefully the issue youâre seeing will be fixed in the next WIP.
Thanks for the update Andy, the User Text now works prior to baking as expected!
It no longer allows you to show/hide the passthrough outputs as it did before though, perhaps you are already aware of that but just wanted to bring it to your attention in case you arenât.
Hi Michael, Are you saying that you canât use the âHide all unconnected parametersâ and âShow all parametersâ in the User Text component? We have different ways to telling a parameter whether it should participate in the hide/show methods and I went through all of the components last week and double checked to make sure the parameters had the right setting. I believe I made the User Text component make all of their parameters always show up (and thus negating the hide/show procedure)⌠but I can change it back if needed. My reasoning for changing the input/output status was that in almost all cases for this component to work, you need all the inputs/outputs. Thatâs a bit misleading because if the User Text is in âRemoveâ mode, then all you really need are the âKeysâ and no values and the component should still work. But, regardless I can change it back if you think there is a specific use case for showing/hiding the inputs/outputs.
Yes thatâs correct Andy, thanks for explaining your thoughts with the design.
Personally, I like any solutions that save on graph space, even minimal space.
I utilize the âUser Textâ node as a âgetâ style component to query all values or keys of a model object but typically am only interested in seeing the values and not the keys or vice versa.
It is fine to have all connections showing at all times but it is nice to be able to hide what isnât being used.
In this image when collapsed we can see explicitly which inputs/outputs are influencing the node operation but if these were âalways visibleâ the user doesnât know if the default values have been overridden or not and have to check each one when troubleshooting/studying a node operation.
Separately a wishlist item would be to be able to set the user text node to âSearchâ where an input Key or Value would act as a filter and return corresponding Key/Value pair.
I made a user object cluster to do this but would love to have this be a default feature of the user text node.
Hi Michael,
Ok, I think I can revert the input/output param status for the User Text component. Typically, the pattern weâve followed for pass-through components is that the very first input/output is usually always shown (meaning they donât ever get hidden). This is because the first input/output is usually the âmainâ data type for that component. Also, if all input/outputs were able to be hidden, then there are cases where the component can get completely hidden with zero input/outputs which can be awkward and useless⌠So, Iâd prefer to keep the pattern of having the first input/output always shown⌠but I think I could make the âKeysâ and âValuesâ parameters hidable so Iâll make a YT for that.
In addition, I think the search feature is pretty great. Iâll definitely make a YT for that as well. I guess the big question is whether this should be itâs own separate component⌠or simply a 4th âmodeâ in the existing component. Iâll need to think through this a bit before I implement it, but I definitely think itâs something we can add. Thanks for the suggestion.
Thanks Andy, yes I agree that the the first input and output (âCâ in example of the âUser Textâ node) should be shown always. I believe this is how the âModel Objectâ node works and this makes sense to me as well.
Thank you, and yes, not sure if the search feature should be itâs own node or not I guess it just depends on how you all (McNeel) like to think of âGet/Setâ operations with the nodes and whether or not the âUser Textâ node is intended primarily as a âSetâ Node or if it can serve dual purpose.
I appreciate the response and look forward to seeing what you all come up with!
