There’s a “shortcoming” in the way clones currently work. Malcolm might remember something similar from a recent clones discussion, but I wanna show that the same problem can occur when using TUIK. The assumption is that every gadget should be clone-able, even “container-gadgets” like the “BasePanel” component.
It’s hard to describe, so please look at the file
tuik.toe (32.3 KB)BasePanel == acts as a master definition for “BasePanel” component
holds_slider/panel/SliderVert == acts as a master definition for "SliderVert " component
“someComponent” uses (and clones) “BasePanel” and “SliderVert”
“cloneOfsomeComponent” clones “someComponent”, but the “SliderVert” never gets cloned, cause it’s inside a clone of “BasePanel” which naturally doesn’t have any SliderVert in it’s definition
Here’s a visualization of the problem(s) using my desired component design/layout and TUIK:
Any comments would be appreciated, as I think this is a totally valid approach which should be supported. Especially as a solid component/cloning workflow should be the base on which future-safe and scalable touchDesigner projects are build.
Assumptions:
Every component is clonable (or loaded from an externaltox)
Components can act as container type components, i.e. have a network immune container in which users can freely create their own networks
TUIK SliderVert will never be created in the Room Component clone.
(Similar problem if BasePanel and SliderVert would be loaded via externaltox: SliderVert would be deleted when BasePanel reloads the tox)
If I would make the roomComponent load an externaltox instead of cloning a master, then currently it would create all components (SliderVert), but all local variables would be “lost/reverted” and all nodes in the furniture subnet would be lost.
And if the externaltox feature would have an option to “clone” the tox, than I would again run into the “SliderVert never created” problem (so that’s why I revised/cancelled that RFE for now)
Matching local variables: When local variables are added/removed in the master, they need to be added/removed in the clone (but the values kept)
Ideally I could create the scematic’s network with externaltox references in every single component and touch would take care of eveything else. This way there would be no need to load/manage seperate master definitions, set clonestrings, find and delete master definitions that are not needed anymore, find a way to trigger scripts which try to match local variables, …
Does no one else ever run into these kind of limitations when designing their components?
Thanks for the nice and clear example Achim. In short, yes, we do run into these limitations as well. That is one reason the TUIK has not been implemented with any cloning thus far. We are working on some generalized solutions to solve these short comings, using TUIK and pre-build components as the test case. We are working on something that can be applied to internal and externally loaded Masters.
When using external master (externaltox) there’s another scenario that’s worth considering
A way to selectively allow/deny children-COMPs to update their externaltox references.
Here’s why. Imagine you have component “foo” which is build using a “bar” component. On disc you have multiple versions: foo1.tox , foo2.tox, …, foo.tox
Usually the latest version (foo.tox) is referenced. The nested comp “bar” also uses the latest version (bar.tox).
Fine, but now you wanna load an older version of “foo”, let’s say foo2.tox
As you specifically load an older version of “foo”, you don’t want the nested component “bar” to update to the latest version. Instead, you want “bar” to be exactly in the state it was when you saved foo2.tox
But at the time you saved foo2.tox, “bar” was of course referencing the latest “bar” version (bar.tox). So there needs to be a way to tell the “foo” component not to update it’s children (unless the children explicitly ask for it).
As this is similar to the allow drag/drop, maybe a similar menu could be incorporated: Update externaltox (Use parent, Allow externaltox, Block externaltox)
Then you could tell “foo” to “Block externaltox”, which would result in foo still loading the specified tox, but “bar” being blocked from updating. Something similar could be useful for regular clones.
Maybe not a general solution, but if clones-of-clones would be supported, then above example could (partly) be realized by controlling the clonestrings based on the path of the COMPs (i.e. set the clonestring for nested COMPs to be empty if the COMP is not in located in /masters)
This is a new way of building panels that should simplify control panel networks. Its not directly related to the cloning issues discussed here. However, it may lead to new way of building panels that will make it easier to work with clones.
yeah, seems like it. As far as I can tell, a slider wired TOP/BOTTOM from a (base)panel, will cause the slider to be visualled placed/layouted as if it would be located inside the (base)panel. Then it would solve most of my coling issue described here.
This is really exiting! One question regarding this. What if you have a (base panel) with size 400300, and inside you have a container with size (390300). Normally you would put any slider in this container, and it would therefore use the smaller size. Now using the new way to build panels by wiring the (base)panel to the slider TOP/BOTTOM, will the slider use the 400*300 size or is there a way to tell it to use the sire of the container inside the base panel? Guess we would need PANEL-IN/OUT ops for this.
