Great to see someone working on this, as the currently released code is indeed some kind of borderline incomprehensible mess of patches, hacks, and workarounds. A rewrite is well overdue, so, thanks @Germano Cavalcante (mano-wii)!

@paul szajner (szap), I get what you mean about conveying the idea of animation, and indeed that makes sense.

I didn't want to use the words "capture" or "grab" because they are associated with live interactive screen recording, while what this addon does is in no way interactive, and more akin to the process of offline rendering, except that it "renders" the whole UI.
"ScreenRender" was the best I could come up with... Other options could be "UIRender", "GUIRender", "InterfaceRender", or something along those lines.

• Change license to GPL

Sorry about notifying everyone, I'm not really familiar with the addon process, so didn't know who to add.

Oh, and I'm only part of the BF Blender project, not the Add-ons (Community) project, so I suppose if I am to commit this I would need to be added to that group as well...

Oh, I misunderstood... For some reason I read it as if the scale of the noises was being affected, instead of the amplitude.
But in any case, wouldn't it be good to match it with the Musgrave Dimension then?

This is super useful!

A new fix was made by @Germano Cavalcante (mano-wii) (D6135).

Thanks for the quick patch!

This issue is caused by the new collision system.

Definitely a known issue. I believe the pointcache system should be removed in favour of a completely new solution.
I think it is relevant to mention here that I started working on an alternative to the pointcache some time ago. I don't have time to continue work on it right now, but the foundation is there.
It is publicly accessible on my gitlab: https://gitlab.com/LucaRood/OmniCache

This is not a bug. The cloth simulator changed significantly in the 2.80 release, and we cannot support the behaviour that existed in 2.79.

This is expected behaviour. The cloth simulation happens in world space because it can involve many objects with different local coordinate spaces.
As the duplicate objects are not at the same location in world space, the world coordinates of the vertices are different, and after all the computations there will be different accumulated float errors between the two objects.
The two simulations are theoretically identical, the difference is down to this accumulated float error.

@Philipp Oeser (lichtwerk), kinda known issue. The whole SDef code is kinda unstable, and in ideal circumstances I'd like to completely rewrite it. I've had some thoughts on better algorithms, though no time for that at the moment.
But @Cody Winchester (CodyWinch) seems to have tracked down where this issue lies, and it seems like it could be a simple fix. I expressed my thoughts at D6782.

Thanks for looking into this and defining that it is an issue with the weights computation, but I don't consider this an acceptable fix.

Thanks for the reminder. Done :)

Addressed mano-wii's notes and fixed swapped current_x and current_xnew

Sorry for the late reaction. I somehow completely missed this task before.