This is the backtracke for deleting a whole particle, then Undo (cannot reproduce an Undo crash if I only delete a particle key...)
There, some ParticleCacheKey is broken...
Thank you for the info about 'FAST'. That explains another problem.
Blender, you keep confusing me.
I recall other issues with data paths in Shader Nodetree .
@Alexander Gavrilov (angavrilov) : havent checked code, but this was a bit special, right?
Thank you for looking into it.
I forgot to mention that the same lack of update also happens with lattice points’ locations. The issue with the lattices can’t be demonstrated with a blend file though, because the workaround found by Rombout Versluĳs can’t apply since even the location isn’t updated.
I don’t know if I should open a new bug report for this, as it seems related.
Tue, Aug 20
Started looking into this.
Some first notes:
Can confirm the issue about Never still updating.
Also Fast will not recover polygonization after editing is confirmed...
Mon, Aug 19
@Philipp Oeser (lichtwerk), you need to access runtime.curve_cache from evaluated object, and write new texture space based on the min/max values calculated from it to original curve.
Caused by rB3566b81c8bfa.
Even though we ensure an evaluated depsgraph in match_texture_space_exec, the object->runtime.curve_cache is NULL...
Thu, Aug 15
Confirmed, will check on this...
Sun, Aug 11
It looks like this goes down to somewhere in depsgraph/animation sources of Blender. Beyond my skills, so I hope someone more experienced can help. At least the F-curve is there apparently OK. Thanks @Lorenzo Celli (lorenzocelli) for confirmation.
Sat, Aug 10
@Tuomo Keskitalo (tkeskita) I tested it and to me it seems that the properties don't update at all, not in the UI and not by accessing them via python. The last keyframe you set just becomes the value for all frames, ignoring the other keyframes you set before
This is a fairly well known limitation. I'm not sure what is needed to make it work, but we should be able to figure that out.
For animation nodes, I usually advice people to not keyframe their nodes but create controller objects in the 3d view instead.
Fri, Aug 9
Can confirm for any mesh with a modifer (since rBAe5c3ae311 the mesh name cannot be changed anymore it seems...)
Will check in a bit...
Hmm, it looks like the animated f-curve evaluates correctly in python console via D.node_groups['NodeTree'].animation_data.action.fcurves.evaluate() even though value shown in node is not updated.
I found out that this bug (keyframing property values is not working for custom nodes) seem to exist also in Animation Nodes on Blender 2.80, FYI @Jacques Lucke (JacquesLucke)
Tue, Aug 6
Fri, Aug 2
That was really a highspeed fix!
Many thanks Sergey.
This is caused by rB3566b81c8bf, reverting to the "old style" in ED_object_base_init_transform seems to fix:
Thu, Aug 1
Wed, Jul 31
Jul 5 2019
committed a fix now (rB609e16339f13), thorough testing is welcome :)
Jul 4 2019
Thx for getting back.
Seems this has the same reasons as T66080, checking... [might merge these two if same reasons apply...]
Blend file example of issue.
I think this might be the same as T66080.
@Sergey Sharybin (sergey) do you want to take a look at this?
Jul 1 2019
This dependency cycle is reported: