@Brecht Van Lommel (brecht) as far as I can see dirty applies here: internally ID_RECALC_TRANSFORM / ID_RECALC_GEOMETRY means this data needs to be recalculated, and that the current state isn't ensured to be up to date.

@Campbell Barton (campbellbarton), please revert rB45fdf41be8 and rB6d38d824377.

well, no shading at all, but that's to be expected since you don't seem to have implemented any drawing in view_draw yet.

This is the conventional terminology in computing. Read "is dirty" as meaning "needs cleanup" or in this case, "needs updated".

Confirmed on 168a6a4bfc1 on windows. Running the script AND setting the renderer from the command line does not update which engine is used in the renderer shading mode in the 3d viewport, despite the mode being set:

>>> bpy.context.scene.render.engine
'custom_renderer'

It seems contradictory when something called is_xxx_dirty being True actually means "not updated".

Hmm, more weird behaviour:

The problem is the message does not correctly show all the valid enum values. For example, 'CONSOLE' is truncated.

Thanks for the fix. The operation bvhtree .fromObject now works when executed once. But it crashes on second run of operation each time:
Steps to reproduce:
run in console:

from mathutils.bvhtree import BVHTree
BVHTree.FromObject(C.active_object, C.depsgraph) 
BVHTree.FromObject(C.active_object, C.depsgraph)  #it will crash here (no error)

Seems like VIEW3D_HT_header calls
VIEW3D_MT_editor_menus.draw_collapsible(context, layout)

Please do not merge reports just because they use the same general 'end tool'… applying armature modifier has little to see with applying one using curves.

For the record, the API changed, see e7c3f7ba6f1385a2138862de8568e571fa97b5b4.

For the records, this also causes T58917 to happen. I will see there if I can change the stored data to pointer (don't recall why I used strings in the first place).

This appears to be fixed.

object.hide_render does not tell you if the object is hidden, it only returns the value of the property as set by the user. This is the same as in 2.7x.

Curve shapekey data is more complicated than coordinates, and even more so in 2.8 after rB12788906. I suspect python API wrappers don't take that into account.

Maybe the description of ID.name should be changed.
So we have three types of names in the api now?

• object name
• object name + library part
• prefix + object name + library part

And I do not think prop_search storing extended name is fine, it's just way too complicated to change this to store actual full ID name, so not worth the effort imho.

Making name collision impossible with a single string is close to impossible (guess since ID names have fixed max length, we could force lib part beyond the 67th char to get that result, but would not be very user-friendly display then).

Ok, I think that .prop_search uses the extended names is fine. (If it is documented somewhere what all the letters mean exactly. I have not found any docs for that yet.)

But if you are interested in diving into the search_prop & friends maze to avoid that behavior, be my guest. For now I think we have something that works well and easily in all decent cases. If user wants to start naming their object L Cube [untitled.blend], that’s their issue. Just use Pointer prop to store IDs then.

If you are crazy enough to name your objects that way, there is no miracle indeed. That’s why I said that ID should be stored in Pointer prop, not string one, unless absolutely not possible to do otherwise.

Well, this little trick does not make id names really unique, right? When I have two local objects named Cube and L Cube [untitled.blend] and one linked object called Cube (linked from a file called untitled.blend), then I can't access the linked object object from bpy.data.objects[...].

Eeeeeh… well, thing is, for UI display, we use those three-chars prefixed names (having some info like linked, orphaned, etc.). It will also append the library name in case of linked datablock. This ensures fully unique ID name (identifier, inside of a given ID type) across whole .blend file.

I looked into the code and it seems like these three letters are used to differentiate e.g. linked objects.

It sounds like a bug to me, can't think of a reason why it should be like that.

I can confirm that. Is it supposed to be like that, @Brecht Van Lommel (brecht) @Bastien Montagne (mont29) ?

Oops sorry, I had searched for any "make_single_user" bugs, which did not output anything. Will search for more keywords next time.

@Campbell Barton (campbellbarton) Fair enough. I can see how changing it to work with sys.path could be more effort than it’s worth. It’s good to know what the issue is, this was bugging me for weeks! If I find a solution I’ll pass it along.

@Benjamin Humpherys (brhumphe) if you get this working, it'd be good to apply changes to CMake.