I was editing a Clockwork node and did a save as, little did I realize this updated the associated Clockwork library node with this new file, and I can’t figure out how to reset it back to the default as-installed library node file. I tried uninstalling and reinstalling the package to no avail.
I’m also experiencing a couple bugs. The settings menu does not appear on my menu bar, and when I try to change the node properties to a different name and library so I don’t save over the library node, it tells me I can’t have special characters in the name even though there are none in the name. Should I update Dynamo?
Sorry, I think I am not being clear. I’ve never seen a program behave like this so it is a little confusing to explain.
Dynamo saves the file location of package nodes somewhere. For instance if I open AppData\Roaming\Dynamo\Dynamo Revit\2.12\packages\Clockwork for Dynamo 2.x\dyf\Element.CutGeometry.dyf and save it in my documents as Element.CutGeometry.Test.dyf, now anytime any script looks for the Clockwork Element.CutGeometry node, it goes and opens the file in my documents, even if it is already in a saved script.
I was able to fix it (I think) by reopening the original file and saving as itself.
Unfortunately I don’t seem to be able to save a Clockwork node into a new library as no matter what I put for the name it says there are special characters in it, even if it is a single letter. This is definitely a bug.
Your settings have a specified path for package installs. This is the roaming profile location @staylor mentioned by default.
Any file you open or load into a session of Dynamo will be maintained for the rest of that session. When you save a copy of the Clockwork to a new location, Dynamo now uses that location as a loaded path for the rest of that Dynamo session.
If you open a dyf in something like Notepad, you’ll see that it contains a lot of identifying information - more than just a file name. Simply renaming a custom node will often not be enough to detach it from its package. You either need to remove that information from the dyf or copy the contents of the custom node to a blank new file. The latter is usually much easier.
The error with the special characters may be related to something else with the node, but it’s hard to say at this point. There’s also a discussion of why you would need to rename a custom node and whether that’s a valid use of someone else’s IP.
I did close and reopen Dynamo and the issue persisted, perhaps if I restarted Revit entirely it would have cleared this change. Thanks for the info, I will be sure to do this properly next time if I modify a custom node.
The Clockwork license if free of any stipulations and gives unlimited rights to do anything you want with it. See here:
I can’t see any argument that it is ethically wrong to modify it if it doesn’t meet your needs, either, and I can’t say I have ever heard this regarding open license open source software and I am surprised to hear it here, in fact quite the opposite. Regardless, I was just testing something out here.
It’s just something to be aware of. Most packages use this same license and while everyone I’ve heard from has been pretty open and willing to share their work, it’s not always this cut and dry. In most cases people still at least want credit.
My question was more around what’s the intent of copying a node and removing the original package identification. We can only make suggestions based on the information you’ve given us. With more information we might be able to give you a better solution or even direct you down a new path. If the goal is to modify (and maintain two versions of the node) then it’s easier to copy the contents to a new node and make changes. A save-as is only going to complicate things.
The reason for removing the original package identification is so that I can keep the original library node as-is, for use and reference in the future, that’s all. I am not trying to remove the package identification specifically, just save a separate version of the node, which I can apparently do in the package library, though this seems to come with its own set of questions (I am now implying work I modified was made by the original author.)
And I would not be sharing anything – if I was I most certainly would give explicit credit for anything it was based on, of course – I agree completely it would be wrong to publish new derivative work and not give proper credit to the original author.
That’s what I assumed was happening. This is a fairly common occurrence for certain nodes/situations. If possible, it’s best to keep the custom node in question intact so that it can update with package changes. If the core logic has to be modified then it’s best to copy the contents and create a new node (not save-as). In cases where you have just a python node, like Element.CutGeometry, you may not even need to create a new node unless you plan on reusing the logic in multiple graphs.