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)
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
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:
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.
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.
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
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):
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.
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?
This thread is a little hard to follow as there is a lot of information to digest. But, I’ll do my best to try to explain how the component was laid out and then maybe we can have some discussion as to whether this is behaving the way it should.
First, I think it would be helpful to look at an example. Let’s say I have three objects in my Rhino document, each which contain the following keys: 1) Color, 2) Number, and 3) Shape. We can use the Query Model Objects component to retrieve all the geometry and then feed that into the Content input of the User Text component to retrieve the keys and values. This part is all pretty straight forward.
Now, let’s look at what happens if we add a text value to the Keys input of the User Text component (“Color” for example). This time the Keys output only returns the word “Color” and the Values output returns the value that matches that key on that particular object. This works a bit like a query or a filter. It’s important to note that the other keys and values (ie. Number and Shape) still exist on the object. It’s just that since we’ve passed a value into the Keys input, it will return the matching outputs that meet that input criteria.
Now, let’s say that we wanted to update all of the objects so that the value that corresponds to the “Color” key returns the color of Purple. This time we right-click on the center of the User Text component and set the mode to be Update. Then we pass both the key that we want to update and the value we want to set. The result of that operation is shown below.
The important thing to note here is that we haven’t done anything to the other Key/Value pairs that already exist on the objects. Since we are in Update mode, it only went and modified the value of a key that already existed in the collection. If we add another User Text component downstream of the first one, and leave the Keys and Values inputs blank, then you will retrieve the full collection of key/value pairs on each object.
Andy, thank you very much for this thorough explanation!
So the Key/Value outputs are providing just the “relevant changes” taken to the Key/Value list in combination with the selected Mode (Merge, Update, Replace…)
I think the way it works is understandable, but is somehow different from the way a “standard” pass-through component was described to work?
if I have a content of some kind in the central Model Object parameter with blue arrow (which already contains 3 key/value pairs) by merging a 4th Key/Value (A) I would expect to get the output in B, not the output in A’
the output in B would always show the full list of all the Key/Values in the Content, regardless of the Mode
[edit] this image is the example you gave in the awesome AECtech2023 webinar (from which this screenshot is taken) and the outputs show the full-data that was modified by the inputs: as far as I understand, I believe this is the standard behavior the pass-through components should have
this image shows instead the different behavior of the User-Text Pass-Through if it was applied to the Point Pass-Through: only data that was actively changed by the input is shown as output (as far as I understand, this is certainly useful, but it’s an exception to the standard behavior of pass-through components: all the updated data should be shown as output, not just the reflection of the changes eventually done by having data plugged to lower inputs)
The component should output the results, not just the changed result. If I were to modify a point’s X coordinate, I wouldn’t want to see just the X coordinate as output.
Reason is that this makes it harder to match data trees and check data flows in and out.
Likewise, I think that a mode should be added that allows for renaming of Keys.
Say you have values inherited from other geometry. For example, you start with a circle that has an area. For some reason, you want the area to propagate to a rectangle. I would rename the key “Area” to “CircleArea”.
Now this is a silly example, but have a script that places trees based on trees on adjacent curves. These trees need to use Curve Closest Point and there it makes sense to inherit keys and values from a curve that drives the values from other curves (e.g. the driving curve’s GUID).
Of course this could be done with a Replace Items component, however, without the full User Text output, you need additional User Text components to make sure that the Key and Value pairs you operate on are indeed complete. And as shown above, this gets messy.
