SUBMITTED: #1 bug: renaming nodes does not update references

yes to me this is the #1 bug currently in Touch, because it puts complex systems in jeopardy everytime you rename a node.

ie.

I have constant chop node:

  • in it, channels have formulas like:

tab(“$pTOP/STAGE/bg”+chop(“select8/bg_sel”)+“/CONFIG/bounds”,0,1)

  • obviously there’s a select CHOP named select8 right there next to the constant chop.

now I rename the select chop, and the above formula doesn’t get updated!!!

this is happening all over my network and it’s truly undermining Touch’s reliability. I’m not sure if the problem is only with constant chops, but I reported another problem with text TOP’s not updateing if there’s opname("..") in their text field, so it seems to be pretty pervasive, yet random since sometimes it seems to work. very unsettling.

(yes I’m in play mode).

d

Hey Dani,
Just to be clear, you are renaming the node Select8 to something like Select9, and you want the expression in the constant CHOP to automatically reflect this correct?

This is different than the opname() bug you’ve reported, where the issue is that the node with the opname() doesn’t recook when the target node of the opname() expression is renamed.

Am I understanding the two issues correctly?

yes you’re correct - they’re two different issues, and yes, I most certainly want any reference to select8 to be renamed to any new name I may give to select8, otherwise renaming becomes impossible (without breaking something that may depend on the old name)

It’s defintly a huge stability issue.

thanks,
dani

i’ve found this too - i dont mind having to go fix expressions manually as i imagine its a pain to do automatically- but i’d love there to be a visual indicator that an expression in a OP is broken

Agree as well. Not only for renaming, also for copying to another location. If I remember correctly I hardly had to worry about it in Houdini.

Anyway, I’m sure derivative could cook something up, but it gets more complicated when you have to support custom components. For example, you might store the actual expressions/paths in a DAT and use eval(tab("myDAT",0,0)) in the actual parameter. Then touch would also need to search table entries for strings matching the changed path to your op.

Achim

The bug where nodes that have expressions like opname() in them didn’t recook when the targets of opname() (or others) name changed, is fixed.

We should be getting a better error reporting system at some point which will make tracking down bad expressions (as well as other erroring nodes) much easier.

thing is that sometimes - and I apologise for not having spent the time to create a test case - when I rename a node I’m asked if I want to change all references (or just the one I’m prompted about).

the window seem to be popping up randomly, sometimes it pops up (ie. if I define an out chop, then rename it, a lot of times it pops up even though in theory there’s nothing referencing it yet), sometimes it doesn’t.

When it does pop up, what I don’t like is that it seems to find “references” that are not really references.

I.e. I had a constant chop with a channel called “sel”. I then created some other chop and called it “sel” as well. Then renamed it, and I was asked if I wanted to change the references - I usually say Yes to All, because I’d love to assume that it’s asking me to change relevant references to the chop I’m renaming - in that case, I was it actually renamed my constant channel from “sel” to the new name! It really didn’t have anything to do whatsoever with that chop I was renaming. So that basically told me I can’t rename anything (unless I’m ready to step through each rename prompt to discern the good ones from the bad ones).

the bottom line is that there’s a process out there that looks for the name that’s being changed. That process is not doing it right, in that it catches names that are NOT part of expressions, or are not part of expressions pointing to the object being renamed, so that process should be looked at and improved.

txd

Ok, no need for a test case on this one. I’m pretty sure I can recreate it. Thanks

I added a check that makes the rename prompt only work if the parameter is looking for an OP of some type. So wierd cases like the channel name example you gave Dani won’t happen anymore.