Thank you! I'll test this version and come back with a follow-up i it doesn't solve the error.

Ok, I see. But having only one twist joint per limb part (characters for mobile games) the situation and priorities look different... Could it be maybe possible to unlock the 100% follow of the last twist joint (the one closest to the bend joint, i.e. knee/elbow)? This could resolve the issues for 1-twist-joint limbs. Or maybe could you advise how to skin such limbs (with only 1 twist joints)?

Cool, thank you! :)

Yes, I set only one twist joint. Can you please explain how can it be problematic? Could you share a file with a limb skinned as it should be by RRM3 design? (can even be a simple cylinder)

Apologies for the late response as well. In my case I did see the message, but it took me some time to get back to the verification of this things as I had to put out fires with other stuff. l_Leg_Upper_Twist_Ctrl follows perfectly correctly the twist of l_Leg_Hip_Ctrl according to the Auto Twist attribute setting (follows fully when set to 1, doesn't follow at all when set to 0, follows half way set to 0.5). Although neither l_Leg_Upper_Twist_01_Jnt nor (thus) l_Leg_Upper_Twist_01_SH_Jnt don't follow the l_Leg_Upper_Twist_Ctrl, but follow l_Leg_Hip_Ctrl fully insted all the time, regardless of the Auto Twist attribute's setting. The same bahaviour is observed on the upper arm too. Regardless of the Auto Twist attribute value in the l_Arm_Upper_Twist_Ctrl l_Arm_Upper_Twist_01_SH_Jnt and l_Arm_Upper_Twist_01_Jnt follow l_Arm_Shoulder_Ctrl twist rotation, and not the l_Arm_Upper_Twist_Ctrl as it should be. The same problem of course applies to the right side limbs. (Using rrm3_installers_BETA_2023_08_24. Were there any updates in the meantime?)

Apologies for the late response as well. In my case I did see the message, but it took me some time to get back to the verification of this things as I had to put out fires with other stuff. l_Leg_Upper_Twist_Ctrl follows perfectly correctly the twist of l_Leg_Hip_Ctrl according to the Auto Twist attribute setting (follows fully when set to 1, doesn't follow at all when set to 0, follows half way set to 0.5). Although neither l_Leg_Upper_Twist_01_Jnt nor (thus) l_Leg_Upper_Twist_01_SH_Jnt don't follow the l_Leg_Upper_Twist_Ctrl, but follow l_Leg_Hip_Ctrl fully insted all the time, regardless of the Auto Twist attribute's setting. The same bahaviour is observed on the upper arm too. Regardless of the Auto Twist attribute value in the l_Arm_Upper_Twist_Ctrl l_Arm_Upper_Twist_01_SH_Jnt and l_Arm_Upper_Twist_01_Jnt follow l_Arm_Shoulder_Ctrl twist rotation, and not the l_Arm_Upper_Twist_Ctrl as it should be. The same problem of course applies to the right side limbs. (Using rrm3_installers_BETA_2023_08_24. Were there any updates in the meantime?)

Hey :) Just checking if there's any update on this issue. Kind of a blocker for me now.

Hey! I'd like to ask about collisions. Should colliders be made manually (e.g. on legs for skirt not to intersect with them), or is there an automatic way, like with Rapid Mesh or sth?

Ok, I see. Thank you a lot for keeping me posted and good luck with that one, I hope you'll figure it out! :)

That's very good! Unfortunately I don't have access to this page. When I know there's a new version available I need to ask IT guys to download it, for only they have access to the paying account for now. I hope that'll change and I will have more autonomy, but for now I need some page (one) to get updates about the new version. If it's not a problem, could you please just write a comment, when there's a new version available?

Oh, I see, Ok then :)

Hmm.. Could intertwining with the Spline IK the Ribbon (using hairSystemFollicles) make it work? I get that this could be pretty chalanging to pull out, but just sharing an idea...

Oh.. That won't be a nice solution I think :/ We'll need to always be careful not to "tear apart" the middle part - of course with blended skinning it won't physically tear apart, but will be stretching which I wouldn't like. I will think about the propositions to make it work. I was also thinking about using the Spine module, but the problem is that it doesn't attach to the other end, at least natively by the RRM3.

OK, great! That's fantastic news for me! Thank you very much for quick reaction, I will test it out soon :)

Yes, I know, I meant this window: The button on the lower left ("Enable/Modify Marking Menu") could stay highlited when pressed (enabled) and a text below saying "Marking Menu is Enabled" could appear as well.

Wow! Great! Awesome. Thank you for the fix! :)

Good news! Thank you! :)

:(

Cool! I think that'll do :)

Have you figured out what picker I was talking about (not sure if I can call it by the name here)? It has zoom and it works just fine with no lags, I don't know how they did it technically, but it just proves that there's a way. To clarify the particular benefits and to show our use case we (or at least tome of our animators) isolate a group of controls to temporarily work just on them, with no need to see all the buttons at once and to use up the screen space, like when one's working on fingers, he zooms and crops the buttons so that only fingers' controls are visible in a small (resized, shrunk down) window, so it's not getting in a way of seeing the pose. Of course it's also possible to make other tabs, but it's not the same - much quicker and dynamic is to just zoom in and resize the window.