Fix error when renaming affixes for objects referenced in read-only file.

[jack-yao91]

Originally opened by @SalamiArmi #153

Scenario:
There are two blender files, big_library.blend and small_asset.blend. big_library.blend has a bunch of heavyweight resources which small_asset.blend can reference. Meshes, materials, whatever. When exporting small_asset.blend with the 'affix' extension enabled, the script will attempt to directly modify the name of the object, which is read-only.

This originally worked in Blender 3.6 (LTS) but was broken when testing Blender 4.4.2. I imagine the API has changed between then and now.

[jack-yao91]

Looks like we need a condition to check the blender version so we can maintain 3.6 compatibility.

[JoshQuake]

ID.rename was introduced in Blender 4.3 so compatibility would need to be maintained for 3.6 to 4.2

[SalamiArmi]

Brief report of my findings.

I attempted to fix the rename() API issue with an intermediate renaming method like so:

def safe_rename(scene_object, new_name):
    if bpy.app.version[0] >= 4 and bpy.app.version[1] >= 3:
        # v4.3 introduced new API for mutating object names
        scene_object.rename(new_name)
    else:
        # v4.2.x and earlier
        scene_object.name = new_name

I haven't fully tested it but my understanding of the behaviour is as follows.

• Versions earlier than 4.0.x will work. They'll use scene_object.name as before.
• Versions 4.3.x and onwards will work. They'll use scene_object.rename().
• Versions 4.0 to 4.2 will not work. They will still attempt to change their object names with scene_object.name but the object in the read-only will have a read-only name. This is the original issue.

A couple of potential solutions, both quite extreme:

• Detect objects as read-only and copy them before renaming, then delete the copied objects and reconnect the original references on cleanup. Not ideal, on an incomplete export might leave the user's file in a bloated/corrupted state. Also probably horiffic performance.
• Don't actually rename anything during the export phase, instead try to apply the logic to the importer. Not ideal (for me right now anyway), would involve tearing apart and re-writing the extension. I don't have the time to do something like that.

I've got some other obligations to catch up on for the moment. Can come back to this in a couple of days. If anyone has any better ideas let me know and I'll take a crack.

[SalamiArmi]

Oh... I might've made a mistake. I've created another pull request (here: #157) to attempt to patch the issue. I didn't realise that pull requests don't quite work that way...

Either way, the sum of the changesets provided should fix the affix extension for users running < v4, >= v4 to < v4.3, and >= v4.3. The behaviour of >= v4 to < v4.3 remains dubious but is an improvement; it previously didn't work at all and now logs warnings.

I'll be running 4.2 LTS for the next 6-12 months so if you guys can't figure out a better approach maybe I'll come up with something in that timeframe.

[JoshQuake]

merged #157. I think you can commit directly to the affixes-read-only-fix branch instead of creating a PR?