Replacing old nodes

We have recently updated all our in-house nodes in the company family to Python 3. This has meant that the existing nodes in the graphs no longer link to them as the upgraded nodes have a new Unid. What would be the easiest way of replacing the old nodes with the updated ones in the graphs or linking the nodes in the graphs to the new updated ones? Is it a good idea to over-write the Unid in the new nodes to be the same as the old ones by editing the .dyn file?

Ps I hope this makes sense. I’m newish to dynamo.

Personally I’m a bit lost - it may help if you post an image showing an example of what you are having to change in the UI.

Typically if you edit a custom node in a package you can replace the underlaying Python and then you just need to deploy the new package.

This is a pic of one of the nodes that isn’t work with the link to the package where we have updated all the nodes to Python 3. If I repath my links to the old version of the package that has not been updated it works fine.


In looking closer at the .dyn files of both the new and old node and the script I noticed that the updated node’s .dyn has a different Uuid to the old one and the .dyn for the script refs the old noe’s uuid.


image

We haven’t published an updated version of the package or re-published it. Just copied it to a new location and modified the nodes to upgrade them to python 3. Is there another way we should have gone about this?

I believe that the ideal process is this:

  1. Publish the first version of the package (either internally or via package manager) using a directory of custom nodes saved in a repository.
  2. Edit the custom node by opening the original dyf from the repository, saving over the previous version.
  3. Publish a new version of the package with the updated node and any new nodes you’ve added.

I think (perhaps wrongly?) that if you edit the node by double clicking on it and then do a ‘save’ or a ‘save as’ to make a new DYF you’ll get a new Uuid, and therefore you’ll have the situation you’re in now. It may be that you can overwrite the Uuid with the previous value, but this might make things worse - could be safer to archive the previous version of the nodes and then move the python string from the ‘updated’ version into the old version. I have more faith in moving that then the Uuid as the ‘new version’ might have new IDs for stuff like the input/output nodes, or even a different order as a result of the ‘save as’.

Either way you’re into an area of experimentation here. I know submissions are closed this year but whatever you learn would likely make a great Autodesk University session proposal session next year.

1 Like

Thanks for your help and taking the time to reply. The nodes were modified by opening up a script first and then selected to be edited. This prompted them to be ‘saved as’ and wouldn’t allow them to just be ‘saved’. This created a new ‘UUID’ even if we overwrote the original node. I opened the node directly in Dynamo and modified it, and it saved without issue keeping the same ‘UUID’. I think we’ll just re-upgrade the nodes the correct way than editing the .dyn. It’ll take longer but avoid any issues that may arise from editing the .dyn down the road.

How many nodes? I have a ‘bulk upgrade’ tool posted on the forum which will change over the Python engine for you and keep the rest of the node still. If you know Python well it wouldn’t be hard to edit it to change the code over from the new version at the same time.