Hi All,
I’m having trouble understanding why linked objects sometimes display different icons. I know what the two circled icons represent ( see picture below), but the third one is unfamiliar. When I attempt to use a library override, it seems to create a duplicate of the object rather than making it freely animatable.
Thanks for your help
Third icon representing links of a chain means that data is linked.
The other icon is same symbol with an arrow above. It means that there is an library override on linked data.
Bright icon means that override is active on data. Greyed out icon means override is active on data at another level of hierarchy, but not on this level of data.
So, if you link a collection containing a linked object and make a library override on that object ; the library override icon is greyed out on corresponding collection, but it is bright at object level.
You should be able to move or animate the object.
But if you create a library override at collection level, that will be the opposite.
you will be able to change properties of collection in Collection tab of Properties editor, but you cannot move or animate the object.
Could you post a more full view of the hierarchy? I have my suspicions about what your issue is with the duplicating, but need the full picture please.
Assuming the collections shown are inside an overridden parent collection: The non-overridden collections shown at the bottom may be nested linked non-overridden collections in the source file. Open up the source file of what you’re linking and check to see if those collections have overrides defined on them.
@zeauro: I think that you should submit “just what you said” to the Blender documentation team. Because it is both a very important point, and(!) a totally obscure one. “Unless you are a computer programmer,” as of course I am, it would not be “intuitive” – first of all – that you can “apply a library override” at the “collection level,” as well as “(separately(?!?!)) the object level.”
To my mind, the entire documentation of the very-important notion of “library overrides” is almost non-existent. This properly deserves its own section. (For example: that you must override “the armature.”) The documentation needs a “user’s guide” section which spells out(!) these many subtleties. I’ve already suggested it: add your voice.
“Can’t understand Library Override behavior?” The OP is exactly right.
What do you think of this video? It covers the general workflow fairly well I think. https://youtu.be/Ghl_glWr8xk
The key takeaways in terms of the visual indicators include:
Chain icon with no arrow = Purely linked data with no override defined. You will not see this often if you follow the workflow of linking collections, then overriding the collection instance.
Dimmed chain/arrow icon = Non-editable. You must right-click and override this to make changes.
Bright chain/arrow icon = Editable. This is the result of the above.
Are you sure? I don’t see this behavior in 4.2.1…
When adding a library override on the collection itself:
-I loose the ability to move the collection around, and it will get the brighter override icon,
-The object(s) in the collection show the dimmer gray override icon, and the regular linked icons for the vertex data and materials.
In this case, I can select the object but it still unavailable to me. I have to add another override to ‘drill down’ to this level so I can e.g. move it.
Even when there’s a hierarchy this will work.
When I add a override on the object -inside- the collection, the workflow is exactly the same for me.
And I have to agree with @AMC_Albert on this.
Some of the functionality of Blender is horribly bad explained in the docs, or cryptic at best…
The reason why you can move around the collection before doing any overrides is because it is initially placed in your scene as a collection instance, which is essentially just an empty (this catches a lot of people but I can see why it’s done this way, it could definitely use better explanation though).
When you override this instance, the instance is removed and the full real collection is placed into the scene. The collection will have an editable override (bright icon), but the objects inside will not. This is where you need to pick and choose what you want to override. Or, if you just want everything editable, you can simply right click the collection, and go Library Override > Make > Selected & Content to make all objects editable at once.
Could also use a better default setting when it’s pulled into the scene.
From the artist perspective, if I don’t want it to be moved, I won’t freaking move it. Why do I have to go through an extra step to override some stuff, so that I can move something?
In an ideal world, I think the best solution is you start off with a collection instance, in which you can transform freely as a whole, and reduces complexity of the scene. Then, when you decide you need to make changes to the individual objects inside this specific collection instance, you do a library override, and the transform of the instance should be retained and transferred to the real collection. This is the small piece that’s missing in my opinion, a seamless transition from instance to overridden collection.
I’m guessing the reason we don’t have this is due to complexities with parents and constraints modifying the instance’s transforms in unpredictable ways, or if objects in the collection have no definitive parent, or multiple top-level parents, etc.
Hi All,
I’m working with a complex scene that combines elements from various sources into a single, large file. This allows me to easily update any individual component. The model represents a large press with numerous systems that require frequent updates.
as for the problem i had with the pipe linked collection (shown in the image at the top) when I opened a new file and imported it as a link, this problem didn’t occur. As demonstrated in the picture below, I can now successfully override library references without encountering unexpected object duplication.
but i still don’t get it why when i add it to the "master file that have other linked collection only this object have a different link icon that not let me to library override it.
The link options in the file manager are not always clear, as is the manual.
Maybe you can explain the File>Link>'instance object data' checkbox.
The manual is very cryptic on this one, and both don’t really make sense to me…
Instance Object Data
Create instances for object data which are not referenced by any objects.
I don’t see any difference when linking in a Collection with this checkbox on or off. Overrides work exactly the same. Or am I overlooking something really basic here?
I honestly don’t know this one, my best guess is that it could be like setting ‘fake user’ on object data (like mesh data?) that have no users to protect them from deletion. In what situation would object data somehow have no users when linked in? I have no idea.
Me neither tbh…
Like I said, having it on or off doesn’t make much of a difference, not even with overrides applied. So… 
I figured it out, it is relevant when you link/append the object data only. So not Collection or Object, but Mesh, Curve, etc. With the option checked, it will create a new object in the scene to assign this data to. Without it checked, nothing will be added to the scene.
Ah… Not Collections or Objects…
Not very obvious, but I tried it and it makes sense now.
It would have been nice to have that tidbit in the docs. 
thanks!! 
The people who initially write the docs “know the subject very well.” More well than you do, when you read what they have written and strive to understand it.
Documentation teams are always looking for user feedback and sometimes writers. There’s always a lot of work to do.
Oh I understand, but sometimes the docs are written from the perspective of the programmer, and not for the user.
It’s often very cryptic, and they should have someone who does documentation a a full day task.
It also should be easier to suggest changes and/or additions to the docs. Especially in the more technical areas, where confusion reigns imho.