User Details
- User Since
- Dec 13 2018, 10:03 PM (116 w, 17 h)
Sat, Feb 20
@Ankit Meel (ankitm) Thanks for merging my report. I was aware of this one here, but thought a more generalized phrasing would draw more attention to, what looks like a very pressing issue.
If you think it makes sense, maybe rename this one here to reflect that?
Anyway, thanks for the fix, hope it gets committed quickly!
Fri, Feb 19
Jan 5 2021
It does not seem to happen when setting custom normals using Blender's native tools, for instance using mesh.set_normals_from_faces()
But it will happen when doing it from python. Here's a sample implementation for setting custom normals from the active face:
Dec 13 2020
Thank you!
Nov 22 2020
Nov 20 2020
Thanks for pointing that out, much appreciated!
Nov 19 2020
Nov 17 2020
@Robert Guetzkow (rjg) Just wanted to comment as well, in case this is in response to Eric, whom I've sent here. His crashes are related to adding/removing ID data using layout.template_icon_view and so changing ID data from enum update callbacks. This is still unresolved, yet my reports about it were all closed.
I was told conflicting information: 1. Don't change ID data from update callbacks and don't run operators from them, 2. If you change ID data use operators. Following this advice means the template_icon_view layout element has become useless for its most popular use case: adding external assets. Since Blender is crashing when undoing after such an operation, it also risks data loss for a huge amount of Blender users.
Nov 4 2020
Nov 3 2020
Read all of this, still don't have a working solution to prevent Blender crashing when appending using the layout.template_icon_view() as the interface (followed by undo)
Oct 28 2020
Oct 23 2020
Thumbnails not loading at all is not a known problem to me.
Oct 4 2020
Sep 14 2020
Understood, thanks for clarifying!
Since this is crashing Blender, and since it never was was problem before 2.83, I feel like this warants more than "don't do this".
Sep 7 2020
Sep 2 2020
Aug 31 2020
Understood, thanks!
@Robert Guetzkow (rjg) Shouldn't this be BF Blender (2.90) too? It's confirmed two times to crash 2.90.
Aug 29 2020
Aug 25 2020
@Philipp Oeser (lichtwerk) I'm not sure either so I appreciate the input. The addon throws and exception when rendering in the compositor, the fix is easy and done already. So why not bring it to LTS, considering it will be in use for the next 2+ years.
Hi @Campbell Barton (campbellbarton), can you take a look at this please?
Look, you have your addon supplied with Blender. You are responsible for it.
Right now, Blender 2.83 is the latest stable release. Please consider getting this into 2.83 as well. 2.83 is the long time release and will be supported for the next 2 years. Since your addon is officially supplied with Blender, and since this is just a fix, not a new feature, it should go into the next bugfix release, so 2.83.6.
Aug 24 2020
I've noticed that Blender 2.90, doesn't seem to have this problem anymore, yet Blender 2.83.5 still has. So can we get this fix into 2.83 LTS too? Also, why hasn't the version changed at all?
Jul 30 2020
I see, thanks!
Jul 29 2020
Jul 5 2020
Jun 27 2020
Jun 25 2020
Is 3ada1949f863 not going to be a part of 2.83.1 (or future bugfix releases)?
Jun 24 2020
Jun 20 2020
It does!
Jun 18 2020
Jun 16 2020
Thing is I only export some images in the file, theses ops would make all paths relative/absolute, which is overkill, as I can easily have hundreds of images, but save out only a handful.
It's a bit cumbersome to first collect all images in the scene that is to be saved, then change the paths, then save out the scene, then change the paths back to what they were before (absolute).
So I really liked the way it worked before and wish there was an option that would restore that behavior. It was a lot simpler and just worked.
Thanks for the info!
Jun 13 2020
Why not at least prevent the error using the ignore_errors arg?
Jun 11 2020
Jun 3 2020
Thanks for clearing that up.
Jun 1 2020
May 25 2020
This is consistent behavior with the error message as well as with what you are allowed to do manually.
This is working as intended, pass --python-use-system-env for previous behavior.
I can understand that, but honestly, this is a terrible thing to ask of addon users.
May 23 2020
It's a worthy cause for sure :) Good luck with your thesis and thanks for your input!
"Defaulting to user installation because normal site-packages is not writeable"
As it should be to be honest.
I'm ready to close this but can somebody offer a suggestion what addons relying on non-supplied modules should do?
I can just append the path to sys.path when registering of course. @Brecht Van Lommel (brecht)?
Apparently, its intentional? https://developer.blender.org/rBS79a58eef059ffc3f12d11bd68938cfb1b4cd2462