What is the best practice when you want to modify a node from the CoreLib or any node that is included in Gamma?
It looks like when I open a node from the corelib, I can modify it.
But if I save, it would affect the whole program, and potentially break other projects?
What would be the best practice to create a duplicate of a library node without affecting the original library?
I tried a simple copy paste in a new node + searching for all the right dependencies + deactivating/activating some toggles until it’s not pink/red anymore.
This is a bit complicated and can have strange results (like changing pin order)
Sounds about right what you did. You’ll need to duplicate it by placing it into your own file and best give it a different name or category so you (and others) know that it’s a modified version. Even better, if you think your version is doing something crucial start a discussion here so in the best case scenario the changes find their way back into the CoreLib.
That would be nice to see a little locker coming with internal libraries. Click it if you know what you are doing.
When using a program, I like to dig and modify things to see how it works.
I shouldn’t be allowed to break the whole program and other projects doing that!
Or at least the UI should show that the node has been modified compared to the original one, and provide a way to come back to the initial state.
The best example I could find is in Houdini.
You can dig into library nodes as well, but they are greyed out until you press “Allow Editing of Contents”.
And even after that, you are only modifying this instance of the node, not the original node from the library.
When you create the same node again, it’s the original node.
The workflow of copy/pasting a node in your own VL document to be able to modify is not ideal.
For some nodes it’s ok, but for most of them it involves dependencies, “subpatches”, links to other things that are beyond my understanding of the architecture of VL.
“Right click on a node / Clone in this vl document” should do all these steps for the user.
Just had a quick look at their documentation and once you unlocked and save your changes to disk you have modified it forever, no? Or is it saved under a new name in your own project?
I just tried in Houdini, and yes you are right, if you unlock + modify + save the node, this node is modified forever and everywhere (other instances of this node are now modified in the current project and other projects).
The interesting workflow here is, if I just unlock + modify without saving the node.
Here, bend1 and bend2 are automatically named (incremented) by Houdini at creation, and are two different instances of the same node.
I can unlock Bend2, modify it (not saving it), and saving my project.
When opening the project again, I find the two different nodes bend1 and bend2, with different behaviours, and the original untouched (if I create another Bend, it will create a bend3 node with the original behaviour).
I think it’s a good example of an intuitive workflow, that allows for a lot of freedom while avoiding dangerous mistakes.
Hmm so if you unlock bend1 and modify it you have another iteration of “bend”? So after that you have three definitions for bend, two of which are specific to their respective instance? Honestly I’m confused now :) Say you fix something in the original bend, those two “private” bends will never get that fix since they are private copies?
You see those little lock items on the bend nodes.
The closed lock for bend1 tells you that it’s following the saved definition for this node. If you go inside that node everything is greyed out and you can’t modify anything. You have to unlock it first.
The open red lock for bend2 is referencing the same definition, but it has potentially been changed.
From here you can either apply the changes, so every other bend will adapt to these changes as well, or you leave it unlocked like so and you have a second “local” definition that’s just being used by this single node. If you were to copy bend2 (say, the new name will be bend3), you end up with a third (also local) definition, which you can also change and which is disconnected from bend2.
Only if you were to Save+Lock or Lock+Discard changes on any unlocked node, it will go back to using a shared definition.
For me the main problem right now is that the UI doesn’t show any difference between nodes placed in my document (what we call “Definitions” in VL?), and nodes who are belonging to other documents.
Some of them are safe to modify, the others are not, and as a user it’s difficult to figure out which one are safe.
