Code Tutorial Request: How to make a property override-able?

For some months I’ve seen this line of text in the Library Override task:

Define much more RNA properties as overridable (this is easy-monkey work mostly).

I’ve done my first bit of playing around with Library Overrides, now that they are a little more supported, and I think I’m ready to try and help out, since I noticed a couple of things I’d like to be able to override. I’m sure making a property overide-able is probably only a line or two of code and maybe an ifdef or an include. I’d like it if someone can show me how it’s done.

My first goal is to make X-Mirror, Relative Mirror, and Auto-IK available in overrides. Perhaps I can help with the “easy monkey-work” after this!

Should I poke Bastien Montagne here? He is the owner of the task.



I’m gonna go ahead and ping :smiley:
@mont29 I’d really love it if you could show me how to do this simple monkey-work. Even pointing me to a commit that does this would be good enough for me… I think I might get confused if I try to find one for myself.

Also: It looks like the motion paths’ properties aren’t overriden either. :triumph: I’m starting to get a list of properties to fix! If you have a list of properties available, maybe I can try and help with that if I can figure out how to do it in the first place.


1 Like

@sybren Can you help with this, please? Even a link to a relevant commit should be enough for me, I’m pretty smart :smiley:

I want to add override ability to a few properties that I think are necessary for animation.

As far as I know, it’s not yet possible to override individual properties, which is why Andy is making his own add-on for such things, called Fine-Grained Library Overrides.

The basic concept behind the add-on is that with Python you can change properties of linked datablocks. This is possible even when the user interface blocks such changes.

1 Like

Hello Dr., thanks for your response!

What I want to do is help with the monkey work, by making these properties override automatically when using the operator, since they’re things that an animator should never have to touch manually.

I’m thinking: X-Mirror, Auto-IK, Relative Mirror, and Motion Trail controls. Actually, I’m preparing a document that goes over some feedback I have after playing around with auto-overrides. I want to help with the project in any capacity I can.

If these properties are already override-able in Blender’s code, then good! I’ll just need to modify the operator code (which is Python, isn’t it?). Otherwise, I suppose it’s only a few lines of code to tell Blender “you can override this”.

Perhaps I misunderstand the way it works, but I assumed that (in Blender’s C code) ID structs have a property "IS_LIBRARY_OVERRIDABLE: = True or something along those lines, and I just want to know a) what to include, what property to add (and where to add it), and what to watch out for to avoid introducing changes that will break Blender.

If I can do this with a few properties I encounter in my own work, then I can help with other things, too.

Thanks again!

This is not what overrides are for. Overrides are for allowing an artist to override a linked-in datablock (i.e. add local changes on top of linked-in data). In other words, overrides add possibilities, but you seem to want to use them to take away possibilities.

You’re misunderstanding what I mean. The monkey-work I was referring to was the code work, marking many properties as library overridable in Blender’s Code. In C. The part the animator should never have to touch is making overrides on properties that are always expected to be used, e.g. the transform channels on a bone.

When you link in a collection instance and make the override, the properties I mention do not override and are thus locked (because they are linked). So, an animator cannot use X-mirror or auto-IK without making the data fully local or using the old proxy system.

To make it worse, if X-mirror is marked, the animator can’t turn it off!

When I make an override, the transform properties of every bone in the armature are modifiable, I want to mark these other properties with whatever tag the transform properties have that make it so the rig just works when an animator links it in.

Once I’ve done that, I want to help by doing the “Define much more RNA properties as overridable”.

In that case you’ll indeed have to talk with @mont29, he’s the developer working on the library override system.

1 Like

Thanks, Dr.

I have been playing around with it, and I was able to make the properties overridable by adding a line of code to each property definition, however, I am seeing some problems (shapes are not visible in the armature object)… and I don’t know enough about what is going on to know if it is my fault or not! So I’d really like to get in touch with Bastien, since I think this is one of those things that really is easy enough for a user to do.

I really want to author my first commit, also!

The line I added was:
RNA_def_property_override_flag(prop, PROPOVERRIDE_OVERRIDABLE_LIBRARY);
where prop is a pointer to some relevant property, this is being set already and all I have to do is use it.

It doesn’t seem to be my fault. I’ve had the same problem in 2.83LTS and it seems to go away after save/reload or reopening Blender… I’m assuming this is a known issue? I think I’ve seen something about this on the developer site. Here I am referring to custom shapes sometimes dissapearing on an overridden armature

Well, I think this was a successful experiment, then.

(In case you are wondering why I didn’t just do it sooner, it’s because I didn’t know where to look, and then I replied to your message with this “Once I’ve done that, I want to help by doing the “Define much more RNA properties as overridable”.” and I realized – it must be in makesrna. A little poking around and I think I found what I was looking for. Still: I want feedback because I don’t know what most of the DEF_RNA functions are doing with the properties.)

Hi Joseph, and thanks for the help proposition.
Thing is, adding overridable properties in itself is dead easy, and very quick to do. You can even do it by “block” now, see e.g. If I have not done it yet, it’s mostly because I am still addressing issues and corner cases underneath that need to be fixed first.
This will be slowly addressed in the coming weeks, as will more and more props be tagged as overridable.


Actually, after looking at the commit… I had awarded a token on it, so I must have seen it already! I’ll look at it again a little more closely.

I went ahead and authored a differential revision for the change, because it is so simple and because it will make animation just a little easier:

If this is correct, then I’ll keep a look-out for other properties that should be overridable.

Thing is, adding overridable properties in itself is dead easy, and very quick to do

I figured that this would be the case, but the reason I wanted your feedback in the first place is because I wanted some advice about how to avoid causing bugs, how to decide if a property should allow overriding, and how to decide which override flag to use.

Thanks again!

Edit: is it OK to mark you as a reviewer for this?