That was something I thought we had fixed a few versions back. Are you definitely on the latest Rigodotify version from GitHub/here?
I don't know if it's related to issue I'm seeing, but throwing out information in case it helps. When I convert a human metarig (in this case I'm using Natural Human 5 Fingers) to Rigodotify rig, the controls stop working for the shoulders and breasts. When I unhide DEF, I can see they are still grey compared to everything else being green. I can get them to work again by following your "add a bone" instruction, but I would expect it would just work on armatures provided along with the plugin. This is also Blender 5.1.2, using the latest Rigodotify from GitHub.
Update: resolved issue by renaming to "Armature"
Indeed, the armature being able to be named Armature is important, one annoyances if you've spun up a few rigs, and regenerated it a few times, the data inside the blend file can make the script confused, attempting to run on OTHER armatures that you are no longer using.
Clearing out the old rigs by purging them and or just opening a fresh blend file with the model and doing it clean one time through can help avoid little bugginess when the rig generates.
Oh dear, digging deeper I see what you're talking about. It'll try to find a solution that keeps compatibility and get this patched soon. I have some ideas I just need to run a bunch of tests to be sure.
And in case you want the backend information. In order to avoid a bunch of errors in the different game engines, we have to remove any 'stretch to' bone constraints. Because they'll throw scale errors on certain bones. But that means I have to find replacement constraints that can provide a similar effect to the deformations.
I've got a working fix, It's not identical to the rigify deformations, but it's close. I'll just need to punch that into the script and we'll be ready to patch soon after I test for issues
Awesome, thank you so much!!
Turns out i did in fact was stupid and used the outdated version originally because blender caches extensions into its own .config folder rather that using local files directly so my original issue may or may not have actually been fixed on 2.3 all along..
Either way thank you for such fast and nice tech support