How to handle preservations of linked IDs when they are effectively unused. #106321

New Issue

133dde41bb refactored how linked data 'directly linked' versus 'indirectly linked' status is handled in code, such that only linked IDs effectively used in current blend file are tagged as 'directly linked'.

This broke some existing use-case, where previous broken behavior was 'abused' to keep linked IDs in current .blend files even if they did not have actual real local usages. E.g. Texts data-blocks, or node groups... See #103867, #105687, #105786, and 'fixes' commits a60f651502 and 3d49d738b7.

A better solution than these temp hacks is needed. Here are two different proposals.

1. Keep track of IDs explicitly linked by users.

The idea here is to add a new flag to IDs, which would only be set for linked IDs that were actually selected by the user (as opposed to these implicitly linked as their dependencies).

These explicitly linked IDs would then always be kept in current blend file, unless users explicitly delete them (through regular ID deletion or Purge operation e.g.).

The 'Fake User' flag would then be fully ignored on linked data.

This solution would also help in case 'fake user' gets removed in the future? See #61209.

2. Make 'Fake User' Editable on Linked Data.

'Fake User' would be editable on linked data. Linked IDs with this flag set would always be considered as directly linked.

When linking a new ID, the value of the 'Fake User' flag in the library file would be ignored. Instead, the Fake User flag would be set or cleared based on the ID type (in a similar way as some ID types currently get a fake user by default on creation, e.g. texts)
This would imply adding a new IDType flag to identify such ID types, which would be a good side-cleanup thing.

This task is closely related to #99262.

133dde41bb refactored how linked data 'directly linked' versus 'indirectly linked' status is handled in code, such that only linked IDs effectively used in current blend file are tagged as 'directly linked'. This broke some existing use-case, where previous broken behavior was 'abused' to keep linked IDs in current .blend files even if they did not have actual real local usages. E.g. Texts data-blocks, or node groups... See #103867, #105687, #105786, and 'fixes' commits a60f651502 and 3d49d738b7. A better solution than these temp hacks is needed. Here are two different proposals. ### 1. Keep track of IDs explicitly linked by users. The idea here is to add a new flag to IDs, which would only be set for linked IDs that were actually selected by the user (as opposed to these implicitly linked as their dependencies). These explicitly linked IDs would then always be kept in current blend file, unless users explicitly delete them (through regular ID deletion or Purge operation e.g.). The 'Fake User' flag would then be fully ignored on linked data. This solution would also help in case 'fake user' gets removed in the future? See #61209. ### 2. Make 'Fake User' Editable on Linked Data. 'Fake User' would be editable on linked data. Linked IDs with this flag set would always be considered as directly linked. When linking a new ID, the value of the 'Fake User' flag in the library file would be ignored. Instead, the Fake User flag would be set or cleared based on the ID type (in a similar way as some ID types currently get a fake user by default on creation, e.g. texts) *This would imply adding a new IDType flag to identify such ID types, which would be a good side-cleanup thing.* ------------------ This task is closely related to #99262.

Subscribed

*Subscribed*

@brecht @dfelinto you guys have any opinions regarding proposed solutions, or other ideas? Think it would be good to properly address that issue for 3.6 LTS.

@SimonThommes @eyecandy @Mets You guys may also have some ideas here?

I think we should have a discussion to figure out where we want to go with fake users and reference counting in general, and what we can change in 4.0, before committing to a solution here. Since it might change the conclusion.

(1) and (2) in a way are not that different. If "explicitly linked" is user editable it's like a local "fake user"? And the "fake user" from the original .blend is not relevant when linked, so in the UI that can be replaced with this.

For both #103867 and #105687 I think the proper solution is not to rely on this though. If a rig needs a script, we should have some way of attaching that script to the rig instead so it comes along and gets removed automatically as needed. For an add-on using a node group, it should also be linked through a custom property I think.

I think we should have a discussion to figure out where we want to go with fake users and reference counting in general, and what we can change in 4.0, before committing to a solution here. Since it might change the conclusion. (1) and (2) in a way are not that different. If "explicitly linked" is user editable it's like a local "fake user"? And the "fake user" from the original .blend is not relevant when linked, so in the UI that can be replaced with this. For both #103867 and #105687 I think the proper solution is not to rely on this though. If a rig needs a script, we should have some way of attaching that script to the rig instead so it comes along and gets removed automatically as needed. For an add-on using a node group, it should also be linked through a custom property I think.

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

How to handle preservations of linked IDs when they are effectively unused. #106321

1. Keep track of IDs explicitly linked by users.

2. Make 'Fake User' Editable on Linked Data.