You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Linking by socket indices breaks forward compatibility #161
Describe the bug
this is what the node Evaluate at index looks in 4.5
in 4.4
blender 4.5 has make changes to the socket index with some node, this problem will cause some socket link error when using codes from older version to 4.5
To Reproduce
Steps to reproduce the behavior:
add an Evaluate at index , link the input to some node
generate the code in 4.4
use the code in 4.5
you will see the switch link of this two input
Expected behavior
I am not sure this should be a forward problem problem.
Apologies for the delayed response, that's rather unfortunate.
NodeToPython's currently setting links by the socket index. In previous versions of Blender, setting links by the node name was unreliable, as you'd get collisions between sockets of different types (for example, the Map Range node in Blender 3.3 had two sockets named "From Min"). I want to say they changed the behavior so that setting links by names was more reliable back around 4.1 or 4.2, but to maintain compatibility with old versions of Blender it wasn't an option to switch over at the time.
That said, Blender's oldest LTS is now 4.2, and the majority of users seem to download NodeToPython from the Extensions Platform, which is 4.2+, so I'm leaning towards deprecating older editions of Blender. I'll create a discussion to see if there's any serious objections to it, but I think at this point better forward compatibility for scripts is probably more important than supporting old Blender versions
changed the title [-][BUG] new socket align style in 4.5 makes input socket broken[/-][+]Linking by socket indices breaks forward compatibility[/+]on Jul 15, 2025
Agree.
Also, a new version addon should have the ability to load the old code generate from the older version , a version manage is need. Maybe we should check out how blender store the new changes for links
I was hoping to give this a proper implementation before v4.0, but unfortunately I've run out of time. Referencing by identifier mostly works, but it seems to fail for nodes with a dynamic number of sockets (group nodes, menu switches, zone inputs, etc.). Not as clean a solution as I was hoping, but still something there to look into
Activity
BrendanParmer commentedon Jul 15, 2025
Apologies for the delayed response, that's rather unfortunate.
NodeToPython's currently setting links by the socket index. In previous versions of Blender, setting links by the node name was unreliable, as you'd get collisions between sockets of different types (for example, the Map Range node in Blender 3.3 had two sockets named
"From Min"). I want to say they changed the behavior so that setting links by names was more reliable back around 4.1 or 4.2, but to maintain compatibility with old versions of Blender it wasn't an option to switch over at the time.That said, Blender's oldest LTS is now 4.2, and the majority of users seem to download NodeToPython from the Extensions Platform, which is 4.2+, so I'm leaning towards deprecating older editions of Blender. I'll create a discussion to see if there's any serious objections to it, but I think at this point better forward compatibility for scripts is probably more important than supporting old Blender versions
[-][BUG] new socket align style in 4.5 makes input socket broken[/-][+]Linking by socket indices breaks forward compatibility[/+]atticus-lv commentedon Jul 15, 2025
Agree.
Also, a new version addon should have the ability to load the old code generate from the older version , a version manage is need. Maybe we should check out how blender store the new changes for links
BrendanParmer commentedon Nov 18, 2025
I was hoping to give this a proper implementation before v4.0, but unfortunately I've run out of time. Referencing by
identifiermostly works, but it seems to fail for nodes with a dynamic number of sockets (group nodes, menu switches, zone inputs, etc.). Not as clean a solution as I was hoping, but still something there to look into