Properties vs Alias Properties
So what's the big deal with Alias Properties?
It's been rumoured that "most" Property tools out there deal only with Properties that are in the General category. AND that Property Alias' were introduced specifically to deal with that.
I'm not sure which of those rumours is true, but nonetheless, we have a bunch of Properties that we WANT users to be able to control from other Properties. Directional Morphs obviously need to be controlled by other Properties such as current orientation, and although that does mostly happen automatically through the SDK, there are times we want to override that. We WANT to break the obvious and as-intended and easy stuff the SDK already does, and muck about! ;) We want to do it wrong. We want to make it creepy. We want to use our Artistic License! (without having to get caught up on dues and such.)
One seemingly simple solution is to just to put our stuff, (er Properties,) under the General category... I mean, we do already have a Property Group that is all ours, otherwise how would we know we weren't in General? Because we "made it so!", that's why!
Perhaps that's not the "best" way though. The Property Alias idea was added for a reason, and since DAZ uses it itself, likely a very good one.
It opens questions of double-saving Properties to .duf though, and dbl-reading/syncing them, so not sure if I should pick Door #1 or Door #2... features; advantages; pitfalls, tricks, traps and gotcha's; etc...
Thought I'd ask... Not like I have nothing else that could occupy my coding (and, eeek, documentation,) time for a day or two.