Keying sets for armatures in library overrides break if unrelated objects are changed in source file #95601

System Information
Blender 3.0.1 with an Nvidia GTX2080, Windows 10
system-info.txt

Problem

In particular, the "Target ID-Block" field of keyring entries for bones on an armature is corrupted when objects in source file (not related to armature in any way) are renamed.

Real world example of why this is a problem: If you are using a rigged character in a scene, and need to make even a small tweak in your character file, the keying sets in your scene will all break.

I've made a pair of minimal files to reproduce the error.

This is a little inconsistent, behaving a little differently each time I do it, even when I do the exact same series of steps. It seems to only work if there are a few objects in the collection, as shown in the test files.

Reproduction
bug character.blend

bug scene.blend

Repro steps with test files "bug character.blend" and "bug scene.blend", which are a notional character, and scene with linked character, respectively:

Have both files in same directory, obviously.
Open "bug scene.blend" and create a keying set. Select "Armature", go into pose mode, select the bone, and add its "location" to keying set.
Hit "i" to insert a keyframe, and observe that it works as expected.
You can save and reload "bug scene.blend" and observe that the keying set still works as expected.
Open "bug character.blend" and rename the object "QQQ" to "PPP", and save.
Re-open "bug scene.blend". There will be a notice that the source file has changed.
Hit "i" to insert a keyframe. You should get the error "keying set failed to insert any keyframes" and if you look at the keying set, you will see that "Target ID-Block" field is empty, or has garbage text in it, or has another object's name in it, or possibly still contains the name "Armature", but attempting to insert keyframes still gives that error.

If you do this with two concurrent instances of blender, (one with character file and one with scene file open) so that you can just use the "revert" function on the scene file, blender will sometimes crash, or will seem fine but crash with an "EXCEPTION_ACCESS_VIOLATION" when you try to insert a keyframe, or when you try to select a path in the keying set, etc.

This is how the bogus name in the Target ID-Block looks like:
{F12855111 size=full}

**System Information** Blender 3.0.1 with an Nvidia GTX2080, Windows 10 [system-info.txt](https://archive.blender.org/developer/F12854711/system-info.txt) **Problem** In particular, the "Target ID-Block" field of keyring entries for bones on an armature is corrupted when objects in source file (not related to armature in any way) are renamed. Real world example of why this is a problem: If you are using a rigged character in a scene, and need to make even a small tweak in your character file, the keying sets in your scene will all break. I've made a pair of minimal files to reproduce the error. This is a little inconsistent, behaving a little differently each time I do it, even when I do the exact same series of steps. It seems to only work if there are a few objects in the collection, as shown in the test files. **Reproduction** [bug character.blend](https://archive.blender.org/developer/F12854709/bug_character.blend) [bug scene.blend](https://archive.blender.org/developer/F12854710/bug_scene.blend) Repro steps with test files "bug character.blend" and "bug scene.blend", which are a notional character, and scene with linked character, respectively: * Have both files in same directory, obviously. * Open "bug scene.blend" and create a keying set. Select "Armature", go into pose mode, select the bone, and add its "location" to keying set. * Hit "i" to insert a keyframe, and observe that it works as expected. * You can save and reload "bug scene.blend" and observe that the keying set still works as expected. * Open "bug character.blend" and rename the object "QQQ" to "PPP", and save. * Re-open "bug scene.blend". There will be a notice that the source file has changed. * Hit "i" to insert a keyframe. You should get the error "keying set failed to insert any keyframes" and if you look at the keying set, you will see that "Target ID-Block" field is empty, or has garbage text in it, or has another object's name in it, or possibly still contains the name "Armature", but attempting to insert keyframes still gives that error. If you do this with two concurrent instances of blender, (one with character file and one with scene file open) so that you can just use the "revert" function on the scene file, blender will sometimes crash, or will seem fine but crash with an "EXCEPTION_ACCESS_VIOLATION" when you try to insert a keyframe, or when you try to select a path in the keying set, etc. This is how the bogus name in the Target ID-Block looks like: {[F12855111](https://archive.blender.org/developer/F12855111/image.png) size=full}

Added subscriber: @AdrianPreston

Added subscriber: @lichtwerk

Changed status from 'Needs Triage' to: 'Confirmed'

Can confirm.

This is how the bogus name in the Target ID-Block looks like:

Was not able to reproduce a crash though.
Not sure if loosing the Target ID-Block is somewhat a known limitation (even though the block that has gone missing is not the one having been renamed)

Can confirm. This is how the bogus name in the Target ID-Block looks like: ![image.png](https://archive.blender.org/developer/F12855111/image.png) Was not able to reproduce a crash though. Not sure if loosing the Target ID-Block is somewhat a known limitation (even though the block that has gone missing is not the one having been renamed)

It is possible that it's a deeper issue, and the renaming thing is just triggering it. I say this because my rigged character files trigger this same behavior 100% of the time even when the source file is not changed. I've just been unable to get a minimal test case to upload, because I can't make it happen with simple test "characters" like this cube-and-bone setup, so I can't get you repro steps. But t DOES happen outside of just this renaming case.

Not being a developer, I'll butt out now.

It is possible that it's a deeper issue, and the renaming thing is just triggering it. I say this because my rigged character files trigger this same behavior 100% of the time even when the source file is not changed. I've just been unable to get a minimal test case to upload, because I can't make it happen with simple test "characters" like this cube-and-bone setup, so I can't get you repro steps. But t DOES happen outside of just this renaming case. Not being a developer, I'll butt out now.

Added subscriber: @mont29

This is a critical missing piece of code in our 'foreach_id' code, that exists basically since forever... not related directly to overrides, as usual those simply expose an underlying defect. ;)

The fix is simple, but backporting it to the older LTS releases is going to be... interesting.

This is a critical missing piece of code in our 'foreach_id' code, that exists basically since forever... not related directly to overrides, as usual those simply expose an underlying defect. ;) The fix is simple, but backporting it to the older LTS releases is going to be... interesting.

This issue was referenced by 3a9a37d6dc

This issue was referenced by 3a9a37d6dccb0a981b1fad0cda977b4a445341a1

Changed status from 'Confirmed' to: 'Resolved'

This issue was referenced by 3a9619af80

This issue was referenced by 3a9619af80e1c95d4789fbccccbce6575e4cce0e

This issue was referenced by ff05921099

This issue was referenced by ff059210992621ca5e3c8e59152b67d711888ed2

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Labels Milestones

Keying sets for armatures in library overrides break if unrelated objects are changed in source file #95601