There is a lot to unpack in these comments, and so rather than making a lengthy response, I have tried to address your concerns in what I hope is a fair solution. I have spent the past week writing a new plugin installer that is just the required nodes for opening scenes with RRM3 and requires no additional licensing. This plugin does not come with the UI or any other features. Simply the nodes I have written to construct the rigs so files can be opened without errors and have all the extended functionality I have written into RRM3. This can be shared within your team. You can read the blog post here: https://www.rapidrig.com/post/rrm3-simple-plug-in-now-available Dustin

I have uploaded BETA_2024_09_11 which has several fixes for control appearances and should resolve this issue when rebuilding the rig.

I believe you already have a node called "Pivot_Ctrl" that exists in your scene before you are generating your rig and you are hitting a name clash. Can you have a look at your scene and see if this is indeed the case? I am working on a major code refactor to handle this issue, but it's going to take some time.

Thanks for reporting this. I have a fix going in the next update that should address this. Through debugging this, I found a few more issues, especially with these fk controls that have a volume appearance. Fix will be in next week's update. Dustin

Good catch, I will have a fix for this in the next update, which should be available next week. The fix will require updating the proxies. Dustin

Thanks for finding this. I will get this fixed in the next update. Thank you!

This is usually due to the hierarchy not being consistent. The warning in unreal should tell you what specifically is the issue in the hierarchy. If not, you may have to manually inspect the hierarchies and see where there is an inconsistency. Either in a mismatched name or a joint having a different parent between the two skeletons.

I have released a new update that hopefully address this issue. For more info, check out the blog post: https://www.rapidrig.com/post/new-rrm3-version-info Apologies for the delay. This required doing some planning and work on the site which took some time to implement the best option I could come up with.

Hi Mariana, we spoke back and forth via email, but for others interested, the licensing is the same for all products, which can be found here: https://www.rapidrig.com/general-info On that page, click the "What can I use Rapid Rig for?" for more details.

Hello, this works as designed. You can read about the reasoning for this here: https://www.rapidrig.com/post/rapid-rig-modular-2-vs-3-axes The more recent releases do have some controls with the option to switch control orientations to Maya space. You can read more about that here: https://www.rapidrig.com/post/rapid-rig-modular-3-new-axes-controls

That's correct, after I move the eye control forward, I select only the Head_Top_Ctrl and move just that one control.

I have not begun updating the version numbers while in Beta, so it has stayed as 3.00.00. The only thing that indicates the version is the zip. Recently I added an archive which shows the changes with each release https://www.rapidrig.com/rrm3-archive

I have not begun updating the version numbers while in Beta, so it has stayed as 3.00.00. The only thing that indicates the version is the zip. Recently I added an archive which shows the changes with each release https://www.rapidrig.com/rrm3-archive

Thanks for that! I tried going through the exact steps and was not able to reproduce it. There was an old bug that was fixed about 5 months ago that could have been a result of this. Are you able to get the latest release and see if the issue persists?

Are you getting any errors?

Hello Nathan, As you noticed, RRM3 now has custom nodes built using the Maya API. This allows the system to leverage more functionality than only using the command library. You can read more about this change in the forum post https://www.rapidrig.com/post/rrm3-maya-api  All users of Rapid Rig require a license and installation. This has always been the case in the EULA where it states in the installation that RRM is for personal or production use only. For production use with several users, there is the Site License section in the Store Page. There are a lot of great features in the Selector UI and the Marking Menus that would be quite useful to the animators, which I recommend they familiarize themselves with. Selector UI https://www.rapidrig.com/post/rrm3-selector-debut Marking Menus for Animation https://www.rapidrig.com/post/streamlining-animation-with-the-all-new-marking-menu https://www.rapidrig.com/post/more-marking-menus Dustin

Hi, can you be more specific? What transform node are you referring to for the right side eyes? What is the setup you have that is giving you this transform node you do not want? Any additional information would be helpful :)

No, only selecting and moving one object at a time in the gif. A helpful tip you may not be aware of: if there are multiple nodes selected, the Channel Box will have "..." at the end of the name of the last selected node to indicate more than one thing is selected. One node selected. Multiple nodes selected.

Something is weird here. The orientation of the control is wrong, and there are attributes missing. This is what it looks like for me. Can you download the latest version from here, and try again? Can you also check if you are getting any errors in the script editor? Also, generally you should not animate the Head Control unless your are doing something like a mech or robot where the top of the neck and head have different behaviour.

The reason this occurs is because if the module of the selected node is not mirrored, a mirrored auxiliary will attach both auxiliaries to the same selected node. If you created a mirrored head, then it would create a 1:1 mirrored auxiliary for each head. The best way around this for your needs is to attach your auxiliary to either the head's attach proxy (eg. the top of the neck), or the head top proxy (or any other non-left/right side of face proxy like the nose or jaw). Then, in the edit modules, you can assign the left and right eyes as Follow nodes: When you build the rig, you can set the Follow attribute on the auxiliary control to follow the corresponding eye. Also, if you are using a single hierarchy skeleton, you can reparent the single hierarchy auxiliary joints to the eye joints manually, and when you rebuild the rig, that parenting will be maintained. I realize this may feel like a hacky workaround, but it is the best way to do this in the current system. The complexity of the face rig makes everything a lot trickier when accounting for the possibility of a non-mirrored and a mirrored head. The current face implementation stays is most consistent with how all other modules behave in both mirrored and non-mirrored states.