Not sure if this is a good idea or not, but it does seem to result in a lot of people breaking their XOD installation unintentionally.
There might be the rare case where someone really does want to over-ride the built-in nodes for all programs they run, but in general, if you want a new implementation of a built-in node, you should be creating your own node for the customization, especially when future versions of XOD are likely to need updated copies of built-in nodes and changing one built-in node results in a copy of ALL built-in nodes in that folder getting copied to your workspace.
Maybe a compromise would be to allow an over-ride folder to be created in your workspace (manually), but giving an error if anyone tries to save a change to a built-in node so they can’t do it accidentally? This might mean that you can’t even make a change to a built-in node since you don’t want to prevent users from saving their project, but that might be harder to code…you do want to be able to view built-in nodes to see how they are coded and make copies of the code. Maybe the over-ride for the built-in node could just be saved as a local node for the project (changing the path for the node when a built-in node is modified, but what do you do with other copies of the built-in node for this project)?
Sorry…this idea seems to have more questions than solutions, but it seems like something that should at least be considered since it has resulted in broken XOD installations after upgrade for so many people.
