Implement new node parameters without breaking existing scripts

Just spent an hour in confusion as to why all my scripts are creating incorrect materials, turns out it’s the new emission strength parameter that’s changed all of the principled node’s socket indexes.

Would it be a better idea to always give new parameters an unused sockect ID? For example in this case emission strength should have been given socket ID 22.

If the visual order is dependant on the socket ID, then perhaps it could be decoupled?

Just for the record https://wiki.blender.org/wiki/Reference/Release_Notes/2.91/Python_API#Compatibility
It’ll probably be added to 21 sept meeting notes/new features too.

Thanks, but why is it a better idea to require thousands of scripts to be updated instead of just using an unused socket ID? Is the visual order of the properties dependant on the socket ID or something?

Is number based socket selection robust or readable, as compared to the following ?

node_principled_bsdf.inputs["Emission Strength"].default_value

The node definition for p-bsdf is in
source/blender/nodes/shader/nodes/node_shader_bsdf_principled.c
https://developer.blender.org/rBb248ec9#change-39K48buuDDXW

No, but I thought it might be more future proof :smiley: Either way, scripts that use both socket name or ID could be catered for if new parameters used previously unused ID’s no?

Decoupling the visual order from the socket ID would mean one script needs updating, whereas overwriting previous ID’s could potentially require thousands of scripts to be updated.

There is no socket ID (identifier) number. The name is the identifier. There is an index in the list of sockets, and that indeed can’t be relied on to remain stable, even at runtime since sockets can be dynamically added and removed on a node.

1 Like

Thanks, I’ll only use the name from this point then. Can you organise to have the name added in the developer tooltips if using the ID should be discouraged?

1 Like

In some cases I found no way to refer to the socket by the name. For example, in CompositorNodeMixRGB and some other nodes there are two “Image” input sockets, to the first one I can refer by either name (inputs["Image"]) or index (inputs[1]), but to the second “Image” socket (inputs[2]) I found no way to refer by the name. I guess this is why an index is shown in the developer tooltips because it is guaranteed to be unique. Of course using the name when possible is still a good idea, at very least it makes the code more readable and probably more future-proof.

Perhaps a unique ID would be a better option then. That’s why I initially opted to use the socket numbers, I expected them to never need to change, but didn’t realise they were generated on the fly. The name system is definitely not very developer friendly or future proof in my opinion. Give every parameter a unique ID and there can be no errors or requirement for mass updates to addons/scripts. Database 101.

3 Likes