Tomas Slancik

You may need to be more specific in what you are trying to do

Channel references are the way to reference values from other parameters

If you are talking about referencing parameters on your HDA from nodes within the HDA, that's the common practice and you should always use relative reference

if your HDA parameters are referencing parameters on nodes outside of HDA, then they would even follow if those nodes are renamed as there is direct dependency between those parameters

However if parameters on nodes inside of your HDA are referencing parameters on nodes outside of the HDA, that's not encouraged and you even get warnings upon saving rhe definition as those nodes may not exist when you create new instance of your HDA in the future

toonafish
So I guess it's basically the same was with UV's ?

I still don't get why it's considered a good thing everything downstream breaks after adjusting a group or uv name

Its the same for all attributes and groups

And it's considered good because it's predictable

What you are asking for would modify your scene in ways you can't keep track of and even then it wouldnt be able to modify everything as the amount of ways to procedurally define which attribute name or group any particular node or HDA will use is vast and is not limited by defining the name as a parameter

So if you want that flexibility, referencing all names from single control parameter is much more predictable, or from the same detail attrib or any way you want to pass that information to other nodes
However this is not always needed, so really depends on usecase

Changing the group or attribute name upstream will not propagate the new name to all nodes downstream, that would be extremely dangerous so really the same answer as here [www.sidefx.com]

This has nothing to do with locked HDA, since any group name parameter can be promoted to the top of the HDA
However the group name in that HDA's group parm will not change automagically just because one of the nodes upstream had it renamed at one point, same reasons as explained in other thread

you can't

addpoint(), setpointattrib() and many other functions that allow creating/writing data to new or non-current element are queued to be executed later as a single threaded operation

furthermore point() or other functions that query data currently query the input geometry even if geoself() is used, as currently geoself() just returns 0 which is the cached first input geo

so currently writing/reading the newly written values within a single wrangle is limited to current element only using @ binding

EDIT: or if you are running within Detail wrangle you can probably store the values in an array to keep track of them yourself