Animation Rigging - PropertyUtils "internal" scope hurts custom constraint workflow

After making the jump to 2020.2.0b13 and Animation Rigging 1.0.3, some example custom constraints I had been using didn't compile, with the PropertyUtils class scope being the culprit.

I managed to get my custom constraint working by copy-pasting the code I needed from PropertyUtils, but I get the impression that changing the custom constraint workflow in this way wasn't intentional, so I thought I'd shine a light on it.

Here's my AnimationJobBinder subclass, where I needed to bind a FloatProperty:

Code (CSharp):

1. public class ContinuousRotationBinder : AnimationJobBinder<ContinuousRotationJob, ContinuousRotationData>
2. {
3.   public override ContinuousRotationJob Create(Animator animator, ref ContinuousRotationData data, Component component)
4.   {
5.     return new ContinuousRotationJob {
6.       constrained = ReadWriteTransformHandle.Bind(animator, data.constrainedTransform),
7.  
8.       // The old way of doing it, but PropertyUtils now has "internal" scope to its assembly
9.       // speed = FloatProperty.Bind(animator, component, PropertyUtils.ConstructConstraintDataPropertyName(nameof(data.speed)))
10.  
11.       // The fix, mimicing the old method. Still works, but definitely was nicer to have access to the old API call:
12.       speed = FloatProperty.Bind(animator, component, "m_Data." + nameof(data.speed))
13.     };
14.   }
15.  
16.   public override void Destroy(ContinuousRotationJob job)
17.   { }
18. }

I've also attached the full file, if anyone needs it for anything.

 

I have not been using Animation Rigging specifically, but the amount of stuff that's marked internal hurts me a lot all the time, so I can feel your pain.

 

Gotcha, thanks for the reply. I'll probably end up duplicating the method in question into a Utilities class of my own, then. I was scratching my head awhile at first thinking I had hit a more serious bug, only to finally see that I'd used "m_data." to prefix the property path rather than "m_Data" with the capital 'D'. Lesson learned: don't retype things if ya don't have to.

 

Hah, I hear ya. I can definitely empathize with the decision to keep assemblies locked down a bit, though. I've been on a team where the project continued to receive updates for years beyond what we imagined in the beginning, and as we added new team members and features, we found ourselves living in a good ol' dependency spaghetti hellscape