i.e. it creates a primitive mesh (and corresponding object) and then tries to rename the object. This works when I run the script from command line using --python command line parameter.
When I run it in the debugger it however crashes at the obj = bpy.context.object with:
I found an issue reported here #63 which seems related except in my case, it does not crash at bpy.ops.mesh.primitive_cylinder_add call but at bpy.context.object and only when running in debugger.
The only workaround I found is instead of using bpy.context.object I am simply searching for Cylinder named object in bpy.data.objects and then renaming it there. But this seems like wasting performance. Is there a way to fix it, or what would be the best practice to handle a pattern like this (so it runs in both the command line and the debugger as well)?
I am facing a strange behavior when debugging a Python script (i.e. not and add-on) which uses the following pattern:
i.e. it creates a primitive mesh (and corresponding object) and then tries to rename the object. This works when I run the script from command line using
--python
command line parameter.When I run it in the debugger it however crashes at the
obj = bpy.context.object
with:I found an issue reported here #63 which seems related except in my case, it does not crash at
bpy.ops.mesh.primitive_cylinder_add
call but atbpy.context.object
and only when running in debugger.The only workaround I found is instead of using
bpy.context.object
I am simply searching forCylinder
named object inbpy.data.objects
and then renaming it there. But this seems like wasting performance. Is there a way to fix it, or what would be the best practice to handle a pattern like this (so it runs in both the command line and the debugger as well)?