bungnoid / zootoolbox

Automatically exported from code.google.com/p/zootoolbox
12 stars 10 forks source link

Order of zooTriggered connects may change (Rev 48) #3

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
When using the %# system to refer to a zooTriggered connection, the actual
object that is inserted in place of the %# will change if the order of the
"zooTrig#" attributes is added to the node is changed.  In other words, I had 

        addAttr -ci true -sn "zooTrig2" -ln "zooTrig2" -min 0 -max 1 -at
"bool";
        addAttr -ci true -sn "zooTrig1" -ln "zooTrig1" -min 0 -max 1 -at
"bool";

in my .ma file for one of my nodes, and my connects were broken (ie, %1
referred to %2); when I changed this to

        addAttr -ci true -sn "zooTrig1" -ln "zooTrig1" -min 0 -max 1 -at
"bool";
        addAttr -ci true -sn "zooTrig2" -ln "zooTrig2" -min 0 -max 1 -at
"bool";

it was fixed.

Original issue reported on code.google.com by elron...@gmail.com on 22 Mar 2007 at 6:31

GoogleCodeExporter commented 8 years ago
wow, thats pretty weird.  the connections are handled by maya and should be 
totally
independent of attr ordering.  this didn't used to be the case in early 
versions of
triggered, but was fixed pretty early on.  I have never had the problem myself. 
 what
version of maya u running?  and what platform?  and what object are you adding
connects to?  are they being added to referenced nodes?

Original comment by macaroni...@gmail.com on 22 Mar 2007 at 5:32

GoogleCodeExporter commented 8 years ago
Hmm, perhaps I should have been more specific... basically, I think the problem 
is
that in zooGetConnects, the ordering of the array that is returned is simply the
order that is returned by listAttr... they are NOT ordered according to 
zooTrig#...
and zooPopulateCmdStrRaw seems to assume that the array zooGetConnects returns 
is
already correctly ordered.

As a fix, I would suggest changing line 383 from:

for( $attr in $attrs )
{
        if( `match $matchStr $attr` != "" )
        {
                $objects[( `size $objects` )] = `connectionInfo -sfd ( $trigger +"."+
$attr )`;
        }
}

to

for( $attr in $attrs )
{
        if( `match $matchStr $attr` != "" )
        {
                $objects[( `match "[0-9]+$" $attr` )] = `connectionInfo -sfd (
$trigger +"."+ $attr )`;
        }
}

...the only change being that matching attribs aren't just stuck at the end of 
the
$objects array, but in the array index matching the zooTrig#.  This should 
solve the
problem I encountered, where merely changing the order that addAttr lines are 
listed
in a .ma file would change the zooTriggered connects.  (Alternatively, I 
suppose you
could NOT call `sort $numbers` in line 460 of zooGetAllTriggerSlots, since the 
order
that things are returned listAttr -ud $trigger should stay the same... but it 
seems
like a bad idea to rely on that...)

Also... while looking again at zooPopulateCmdStrRaw, I noticed there's a 
potential
problem if a user has strings of the sort %1%2, because the match string being 
used
in zooPopulateCmdStrRaw is (%[0-9]+)+, instead of just %[0-9]+... ie, if they 
have

{
        if(!(`objExists "Nancy"`)) createNode "transform" -n "Nancy";
        if(!(`objExists "Frank"`)) createNode "transform" -n "Frank";
        if(!(`objExists "loveChildCreator"`))createNode "transform" -n
"loveChildCreator";
        zooAddConnect loveChildCreator Nancy;
        zooAddConnect loveChildCreator Frank;
        string $cmd = "{\n" +
                      "  global string $babyName;\n" +
                      "  $babyName = `createNode \"transform\" -n %1%2`;\n" +
                      "}";
        zooTrigSetCmd loveChildCreator $cmd;
        zooTriggerObject loveChildCreator;

        global string $babyName;
        print($babyName);
}

poor Nancy and Frank will be shocked to find their child's name is Nancy1, and 
not
NancyFrank, as they might have expected... if you use just %[0-9]+ instead of
(%[0-9]+)+ in lines 147 to 153 of zooPopulateCmdStrRaw, they should be popping 
out
NancyFrank's in no time...

Original comment by elron...@gmail.com on 24 Mar 2007 at 12:42

Attachments:

GoogleCodeExporter commented 8 years ago
fixed by paul

Original comment by macaroni...@gmail.com on 27 Mar 2007 at 5:57