Home Website Youtube GitHub

Naming issue in 4.1.0

So much stuff indeed! Awesome work!

I’m updating guides to the new version and I’m having a small issue with control_01 control naming.
I’m using the following naming rule: (component)(description)_ (side)(index)_ (extension)
However, after building the rig I’m getting “controlC0_ctl” instead of “control_C0_ctl”.

Is this just me or does it happen to everyone else?

I moved your post out of the announcement thread. Please ask for help in separate threads. :slight_smile:

Did you add the spaces to your underscores to try to stop the forum from auto-formatting?

Can you please show your actual naming conventions. Put it inside backticks like this:

`(component)(description)_ (side)(index)_ (extension)`

And maybe show a screenshot of your other settings too. Like what you have in your description field. Maybe there is a small typo. Or maybe there is a new bug. But please show what you specifically did, so it can be reproduced and tested.

Hey, sorry about that, I’ll keep it in mind in the future.
I did add the spaces to prevent the auto-formatting.

I was able to reproduce this on a clean scene. I’m using Maya 2024.

  1. Add a control_01
  2. In guide settings set Controls Naming Rule to {component}{description}_{side}{index}_{extension}
    (I also set Letter Case to Capitalization at first but the same thing happens when using Default)
  3. Build the guide, then the control_01 name will be controlC0_ctl

Is it only Control_01?

I don’t see any code changes in shifter.naming (yet).

It seems like the {description} is getting completely filtered out.

In control_01/__init__.py around line 37, there is some new code regarding custom names. Maybe there is a bug in there.

            ctl_name = ast.literal_eval(
                self.settings["ctlNamesDescription_custom"]
            )[0]

control_01, ui_slider_01, sdk_control_01, EPIC_control_01, EPIC_layered_control_01 all seem to be sharing the same issue. I didn’t test 100% of the controls today, just the ones I was most suspicious of. Other components such as ui_container_01 or arms, legs, squash, etc. didn’t seem to have it.

I thought it could be related to the changes related to the new Ctl Description Name field, but some of the controls that had the issue when I tested it don’t have that field, so I’m not so sure anymore.

1 Like

I think I have introduced a bug. I will check this and do a hotfix release ASAP

1 Like

I’ve just upgraded to 4.2 from an older version 4.0.22

I have the same issue. I’ll investigate now, but let me know if it’s part of a wider issue or has been forgotten and still needs a fix.

The issue seems to be that “ctl” is the default control description name for the Control_01 component. I don’t remember ever changing this when building our main player template, which is a few years old now. Maybe doing a template upgrade has swapped this property out to a new value. Or there was a previous bug, which is now fixed. Our rig has been built in the past with the description “control.” I’m not sure if that was the default value previously, strange.

Our control naming rule is - {component}_{side}_{description}

Previously would generate “armUI_l_control”, which now generates “armUI_l_”

The fix is to force “control” as the description in the Ctl Description Naming tab. Looking at the code, there is a hack in the method addCtl, which removes hardcoded “_ctl” or “ctl” from the description.

Then, if the name is in an empty string, which it would be in my case, it modifies the control name rule and removes all forms of “{description}” from the rule. There seems to be a bug in the logic as it’s supposed to remove leading and trailing underscores from the rule, resulting in {component}_{side}, but we get {component}_{side}_ instead.

In short, it’s not advisable to use “ctl” or “_ctl” in the description property of a component. I would advise removing this as the default value in the Control_01 component, as the code prevents it anyway and fixing the bug with the leading and post underscores.

@Miquel, this fixes the trailing underscore issue for me in component\__init__.py lines 893 or there about. It’s difficult for me to upload a pull request at this time as I’m now on a modified version of mgear due to custom components, and no time to work it out so it’s a monkey patch.

# Adjust trailing underscores trailing_underscores = ( len(re.search(r"_+$", source_rule).group(0)) if re.search(r"_+$", source_rule) else 0 ) new_trailing_underscores = ( len(re.search(r"_+$", rule).group(0)) if re.search(r"_+$", rule) else 0 )