Update: I also tried modifying the list created at line 284 of 'bricker/operators/delete_model.py' so that it simply stores the names of the objects rather than references to them. This didn't fix the issue - still got the same error.

Sure thing – I've attached the addon as well as an example file above. I double checked the code where the error occurs and there are no lingering references to the data after it's removed, as far as I can tell.

Ah, that's what I was missing. Thanks!

This breaks an addon of mine, where I was casting in a newly created view layer. The depsgraph of a newly created view layer returns None until I make that view layer active (scn.view_layers["background_layer"].depsgraph), so I can't pass it in to the scn.ray_cast() function. When I just passed in the view layer in the 2.90, it worked fine. Am I missing something simple @Sybren A. Stüvel (sybren) ?

The issue is not with the has_data property. The issue is that images not yet loaded in memory do not write to disk correctly with bpy.data.libraries.write(), which is a bug. At the very least, an error should be thrown if the image data has not been loaded to memory, rather than writing bad data to a file.

I don’t understand the latest comment from @Campbell Barton (campbellbarton); how is it the expected behavior that a face normal would flip when joined with another object? It's a very unintuitive behavior that seems problematic to me from a usability standpoint.

Ah, you're right! Pesky Google search results showing random Blender doc versions...

@Sybren A. Stüvel (sybren) That's fair! I went ahead and reduced the code quite a bit, and refined the description a bit to help clarify things. Happy to add/adjust anything else if needed.

This is great news. Would really appreciate if this fix make it to the next 2.83 LTS release!

I've updated the title and description to reflect the state of this bug in 2.83 – The steps to reproduce the error should be very clear.

I have a bit more information as I continue to investigate:

I won't have access to my Windows machine at the moment, but I believe it was something like this:

Perhaps it has something to do with the image file I'm using? Here's the image file:

When the blend file is saved and restarted, the following prints to the Command Line:

Ah, I have new information.

Please disregard. Found the fix: https://wiki.blender.org/wiki/Reference/Release_Notes/2.81/Python_API#Handlers

Closing this in favor of the preferred implementation: D1578

In D6272#145234, @Philipp Oeser (lichtwerk) wrote:

dont want to hijack, but reminds me of D1578: fix Custom Python Nodes dont draw their 'bl_icon'

Thank you for pointing this out – I've updated the sample script to reflect this. The issue still remains as described.

Operators like this should not change the active object automatically, as pointed out by Brecht Van Lommel. Instead, the operator checks for active object (if active object is None, mode cannot be 'edit')