Hey, there!
I am frankly new to ragdoll and only know the basics. For my shot I replaced meshes and set them to animated to use them for my tail simulation as collision. Before recording, the markers get affected by the collision meshes but after recording, the final tail will have the simulation without the affect by the collisions.
Here is a screen-recording with the final tail (with the simulation added) and the marker tail, which still gets affected:
Is there a setting I am missing?
Thanks for the help!
Hi @ran_imation, welcome to the forums. 
Recording is the process of constraining your assigned controllers to the simulation. If your controllers struggle to follow the simulation, it’s possible the end result differ from the simulation.
To debug this, you can try this, before recording:
Ragdoll → Utilities → Extract Simulation
This will do part of what Record Simulation does, where the simulation is exported from Ragdoll onto a new set of transforms you can visualise in the viepwort (as joints). Double-check these move as you’d expect and then try manually constrain one or more controls to them.
This typically reveals issues that Record Simulation would encounter as well, such as locked channels or spline IK fighting against the simulated motion.
If you still can’t see any issue, then in the optons for Extract Simulation you can have Ragdoll apply constraints to all controls. This is the next step taken by Record Simulation, followed by actally baking the keyframes. See if any of the constraints struggle to make your controls follow the simulation at this point and post what you discover and we’ll help you further.
Hello!
Thank you for the fast reply 
With your suggestion I think I understand why it didn’t worked with the simple record simulation. Because I set the first two controllers of the tail to animated, as it gave me more of the result I wanted in the preview.
With the extract simulation and constraint the animated tail roots will also be constrainted!
Now the tail is technically following the simulation but I noticed that the shape of the tail is broken, I started to clean it up manually but as it seems to take a lot of time, I wanted to ask if it may be an issue with my setup, that the tail is all wrinkled?
Could it be because the rebuild of the tail is a bit messed up? As the start position the tail is curled and to match it I had to move and rotate them a bit, but as it does the tail setup looks then weird when in motion as you can see in this video:
It’s hard to tell from your videos, but I expect the tail is driven by spline IK.
- A set of controls drive a NURBS curve
- The NURBS curve connect to a Spline IK solver
- The Spline IK solver drive a set of joints
This is a common scenario (and problem) because the joints that ultimately drive the mesh are already getting “solved” positions from this IK solver. And the controls that drive the curve are than also being “solved” by Ragdoll’s simulation. You can think of it as double-transformation.
The most common and suitable solution is to either:
- Assign directly to joints and retarget to controls
- Find or author an alternative set of controls, without IK
Some rigs offer an IK/FK switch, even for things like tails. And you always want to drive FK controls (joints are inherently FK). Your tail controls were designed without physics in mind, because with physics you would not need IK. IK is there for the same reason as physics; to reduce the amount of controls needed to drive the many joints involved in deformation (skinning).
About retargeting, see here:
About the reason they appear to come apart, my guess is the controls behave like an FK chain - where you rotate the root the children follow. But in reality they are not.
I actually am using FK for the setup, since this rig offers an switch and I assumed it to be better than IK
Would you still suggest to assign directly to the joints?
My guess is, based on the fact that they separate when you rotate them, that what your rig calls “FK” is an approximation of FK. It would be typical for what is ultimately a Spline IK solver with the appearance of FK. True FK should not alter the position of children when rotating the parent, and unless your controls also increase in count (basically, one control per joint) then it is very likely just an approximation the rigger chose to call FK.
But again, it’s not clear from your videos why the separation happens. This is my best guess. Regardless, assigning to joints is a the safest method of the simulation getting the final animation as input and I would recommend assigning to these whenever possible.