Note the crasher on delete, undo is also fixed by D5755: Fix T68645: Hair Particle Edit - Particle Mirror crash when children are visible in the viewport
Tue, Sep 17
This needs bigger design changes to the dependency graph and physics, and while it would be good if we can, it is not a requirement to be fixed for 2.81.
Fri, Sep 13
Thu, Sep 12
Deferring deletion of the scene is not practical, the depsgraph references the original scene. Even if it didn't then having multiple copies would use too much memory.
I am not sure what is "deferred" here means exactly. But technically there are only two things which needs locked interface:
Wed, Sep 11
What happens here is that you're accessing property from an original datablock, but it's actual value is only known at the evaluated version.
Mon, Sep 9
Fri, Sep 6
Anything new? Maybe I'm missing another similar bug report
@Sergey Sharybin (sergey) : I have added this to 2.81 milestone (since it was set to "High"), mind checking again?
@Sergey Sharybin (sergey) : I have added this to 2.81 milestone (since it was set to "High"), mind checking?
The AnimAll workaround probably caused T69509, so I still think this is a High priority...
Thu, Sep 5
FAST is back (probably due to some - unrelated - change in transform code), so that should help a little, looking into NEVER...
Wed, Sep 4
I posted another similar post before being led to this one, I figured that after you do all the steps, don't play the animation yet, save the project, and close blender. Delete the .blend1 file beside the .blend file, the open it up again, and play the animation, the hair particles are now following the cube.
Tue, Sep 3
Mon, Sep 2
Probably already clear to you guys since your looking for the missing dependency trigger but just in case: it seems obj.data.update() forces an update of the viewport.
Oki, thx for clearing that up
it is not the empty transform being dependent on the Boid Rule?
Sun, Sep 1
Is there and ETA for this bug going to be fixed? It seems like a pretty serious bug, and all my work is complete stop until this is fixed. For now I've had to revert all my code back to 2.79.
Fri, Aug 30
Thu, Aug 29
Wed, Aug 28
I have a strong feeling, that this, T68945: VSE - Improper audio on frame 1 when exporting to lossy-compressed audio and T69167: VSE - "Render Audio" exports only one audio strip in some cases are caused by the same issue, or at least an issue in depsgraph.
Tue, Aug 27
Also note that even if this works with image textures in the file provided, there is still an issue with procedural textures... [these dont update as well]