User text - Simplify adding key/ value pairs to objects

I’ve been wondering about this for quite a while, but why does merge replace User Text when setup with a new Key/ Value pair? The tooltip states that:

Clearly that’s not the case in this simple example below:

Instead, you have to perform data tree manipulation to get the key/value pairs added:


This makes complex definitions harder to read, so I’m wondering whether there could be a new mode or change to user text to allow for this sort of thing without the data tree shenanigans (like matching data when all you want to do is add a simple key/value pair to all of the content in fed into the component).
Key Value Sample file.3dm (53.0 KB)
Add key-value Attribtes.gh (46.2 KB)


It doesn’t seem so

Shouldn’t the new keys already appear on the middle merged User Text output?

as far as I understood (and I didn’t have chance to use this set of new components as much as I’d love to), either you use any of those wired like A to write Content, or you use them wired like B to read content:

if you write content, the K / V output of A would be the bare reflection of its own same inputs: the whole merged/updated data is packed in the Content output

classical self-explanatory example :slight_smile:

1 Like

As far as I understand the other components, the input writes (or filters) and the output reads.
This is the third option: filter to read (it does not write).

What I don’t understand is why the read and write have been split in this particular component. If I want to read the input, I might as well use the merge component before the inputs or use the outputs. I don’t see why I would need the right hand side to output my inputs for a merge. In this simple case below; I would use the merge component’s output, same as the input. The User Text component doesn’t affect the data here, except that it matches the tree data structure.


So especially with a flat input of a single key/ value and no individually computed values for curve length, area, etc. I don’t see the added value of the read output as it is now (as it ignores set key/value pairs and you won’t be using the output without the complete set of attributes).

User Text update mode drops key/ value pairs
However, a problem emerges when you add, modify and remove keys in sequence, because it can lead to drops in key/ value pairs with the mode set to update:

The problem then becomes that apart from having to manage a data tree, you can’t see the immediate result, so you don’t know if the right amount of keys were removed, added, replaced or updated. This then affects the data tree management, because the error may be within the tree structure or the attributes from user text. There is no clear immediate culprit to check if something goes wrong and to resolve errors, you need to add User Text components left and right:


I basically had to backtrack all of the User Text components just now due to its inconsistencies in a particular scrip and I’ve been using these as key component in all my scripts since it first emerged in the R8 WIP…

tl;dr
I think there’s something wrong with the User Text Update output, because it drops all attributes on the subsequent component.
Issue is here:


In the example below:
Add key-value Attribtes.gh (54.6 KB)

1 Like

The guide leads me to believe that’s not how it is supposed to work, left hand side writes/ filters, right hand side reads the end result.

But with User Text, the Key/ Value output is an intermediary step: it doesn’t read the actual attributes of the content. Rather, it shows how the attributes were modified.
It’s like the move component’s transform output in that sense rather than the transformed geometry output. And when you need more of the same components to read the key/value pairs you are after, this quickly becomes confusing.

1 Like

I think I figured out the issue. So I had one curve which I use to push attributes to one or more curves. In the 1st User Text, I read, in the 2nd I replace the Values (which creates the data Tree for two objects), then in the 3rd, I read, 4th replace the geometry. With it set to update in case these curves already have the Key/ Values assigned, the Tree structure is retained (and doesn’t show missing data on hover), but they are empty. This caused all the other shenenigans further down the road.

And this is a simplified file:


User Text Key_Value drops.gh (29.2 KB)

E: Simple test file:
User Text test.3dm (43.2 KB)
User Text test.gh (28.5 KB)

why this set to Update?

the Content comes from a new (Rectangle) curve, so it is not carrying any already existing key/value data to be updated… if you change that to Merge everything works fine:



[edit] by looking at this video from November 2023 (so something has changed for sure [I’m pretty sure Content Cache behavior has changed for instance] ) I would be led to think the User Text component is either an exception to pass-through component standard behavior (maybe due to the presence of the optional Merge/Replace/Remove…) or there’s indeed something wrong

minute 06:30 → https://www.youtube.com/watch?v=nXHBtoBM7Z4

what I wrote in my earlier post comes indeed from my experience as a user, in particular the thing that the User Text output reflects the effect of the data in its inputs combined with the Merge/Replace/Remove option

but to be fair, the output should be directly the updated list of Key/Values, without the need of using a new component just for reading those…

So, I think you are right all along from your very first post in this thread, unless there’s some exception in relation to this very component, despite it being a pass-through one

the way pass-through components are described, this should not be necessary:

and the following should be the standard behavior (this image is Photoshopped):

1 Like

The update got there in my file for a particular condition, I just showed here that it can lead to ‘corruption’ of the User Text when used this way and when people are unaware that User Text behaves differently as a passthrough component than the others. :wink:

Then again, Japhy liked your initial post, which leads me to believe McNeel intends the User Text component to be different from any other passthrough component and prefer it to be confusing. I’ve reported key/value drops before in the Beta, but it can still do this, which is not what I, as I user, expect.

@AndyPayne could you perhaps share some insights for this discussion?

1 Like