Indeed… actually, not sure why those effects are available for emitter particles, most cannot work at all in that context and will just do nothing.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

I realised this crash happens only if the particle system was modified before with the Particle edit mode.
You can reproduce this crash on the startup scene by doing the following:

Confirmed on linux as well, see ASAN backtrace below, @Sergey Sharybin (sergey) think that one is for you. :)

That file has nothing to do with initial report… *sigh*

Thanks!

@Brecht Van Lommel (brecht) @Sybren A. Stüvel (sybren) iirc, this is known limitation due to how our cache works currently?

To bad this is an ongoing issue with 2.79 i was already wondering why the particles where not following.

Confirmed, since this is related to physics maybe @Sybren A. Stüvel (sybren) wants to have a look?

It looks like all the Metaball objects do close blender 2.80a

here is the file, go to edit mode and select the green sircel

I confirm that it works fine with the latest build so this can be closed.

Cannot confirm that here on linux (though psys code spits out a huge amount of asserts…), mind re-checking with latest 2.8 build? thanks.

Please follow our submission template and guidelines, also read these tips about bug reports, and make a complete, valid bug report, with required info, precise description of the issue, precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.

I can confirm that in 2.79 and current master, but not in blender2.8, so will consider this issue as fixed. :)

Can confirm the issue (on both master and 2.8), it’s buffer overflow bug:

In T37578#189565, @Lukas Toenne (lukastoenne) wrote:

Reading/writing cache files simultaneously should be as smooth as possible. I have to investigate the details of how Alembic files can be accessed more-or-less simultaneously, but generally it should follow a one writer / multiple readers model.

Hm strange, saw a crash once here (when pind->kkey[1]->time wasnt accessible)
but cannot reproduce ever since...

Hi, any news on this bug? It really makes it impossible to use Blender as generator of fluid simulations for use in other apps. This should be high priority, because all the work spent by someone to make Blender support VDB is negated by this unwise file naming. I mean if you are doing sims to be used in Blender, you can just use the default point cache. VDB makes sense mainly because of interoperability with other 3D packages, yet this interoperability is broken for exactly this reason :(

Thanx for getting back [and for finding a workaround/solution]
I'll archive this then (though it is still not completely clear whether this is intended behaviour or not -- but report can always be reopened or found as reference)

In T55151#504978, @Philipp Oeser (lichtwerk) wrote:

This is actually working as intended, so calling this "corrupted" is not really appropriate.
I agree though that flipping index and framenumber would probably have benefits in a pipeline involving other software.
This could certainly be done [would need to take care of reading both naming-conventions then...].

Dont think this is a bug [more of a TODO - if at all], but maybe @Brecht Van Lommel (brecht) or @Sybren A. Stüvel (sybren) have a comment?

This is actually working as intended, so calling this "corrupted" is not really appropriate.
I agree though that flipping index and framenumber would probably have benefits in a pipeline involving other software.
This could certainly be done [would need to take care of reading both naming-conventions then...].

I'll look into Alembic separately

commited rB5e7a21a5f549

I did solve this with majoy difficulty.

is this bug found? will it have a solution?

This doesnt seem to be related to a ParticleSystem in particular.
It just works well with object transformations on the target (same as your First Layer example), but not so well with object data transformations...

Though this might be inconvenient, this seems to be by design (and not a bug) then.

OK, will have a look

Yeah, rotation sliding on Z is bothering me

Sorry this report hasnt been answered in quite a while.

Lukas T. I just hope what this doesnt go in perpendicular with your work in hair_guides branch.