It would be good if every Operator gets a unique ID (uuid) consitent over Saves and exporting and import, to be accessable via this ID. (Like an OP-Shortcut).
Hi, not sure how RFEs work, but im putting in a +1 here 
+1 For this! Would facilitate greatly the creation of dynamic systems with user-free reliable referencing.
This is something we’re looking at in regards to the new file format to help with matching and merging nodes; however, there are still a lot of issues to investigate with it so I can’t say for sure yet whether it will happen.
5 Likes
+1 from me. I think it is an important future that should be in the base implementation. I did my own system which generates GUID behind the scenes based on the number of child nodes, network structure, and other attributes. It works but I believe a native solution will be amazing.
It might be good to expand on how you all imagine you would use such a UUID. If you use it for referencing, this could be frought with issues. For example, you have a component using these IDs for some reference, as soon as you copy and paste, or import into a different project, those IDs would change.
Whenever we discuss this, this is the main issue. So how do you see UUID being useful when making copies and merging projects/.toxs?
A new ID would be the expected result in my opinion if you had that.
I guess you could run into issues when copying into a new project…couldn’t you do a sweep across the project to check for that ID and if it doesn’t exist keep it the same? In theory you should never have a situation where you’d want to copy 2 UUIDs that are the same. In some cases you want a fixed UUID and in some cases you want a fluid one.
What if you could toggle an op as a unique op key that would fix it’s UUID but then have others fluid? You can then just throw a warning whenever you have more than one of those in a project like op shortcuts currently do.
When I’m using uuid’s it’s generally with those purposes of copying a “master” object to allow for dynamic copies of that object in the scene. When creating those copies we can just get the new UUID from the copy on creation and use it wherever we need.
I’ve attached a screenshot of my current setup. There is an extension that renames an op by it’s ID and then a script DAT that takes that OP type and gets all the op parameters into a table. I can then keep track of copies in the system using this table.
In this scenario you can’t use a replicator as the ID system is just number based so if I delete object 2 then object 3 now becomes object 2. For my use case if replicators used UUID’s for their copies rather than numbers I wouldn’t even need this system.
I also use these UUID’s to build a relational database of objects inside TouchDesigner by using custom parameters to define keys to connect things like materials to objects etc. You can see in the screenshot I have a material ID field that has the UUID for the material I want to apply to that object.
Happy to show you through this system at some point if you think it’d be useful.
1 Like
Hey @Ennui,
how do you use the Replicator? Are you mostly in a “by Number” or a “by Table” mode? For me, when in “by Table” I always generate my own ids and name the replicants after that: to prevent recreation and reordering.
The sort is there to test that I can randomize the order and make sure it’s not recreating replicants.
cheers
Markus
It’s interesting that works…I’m pretty sure I’ve tried it that way in the past with issues. I might try it out and see if that now works.