Mark, your fix is in my latest pymel, as well as a test for it. Been taking a look at the way getReferenceEdits works (as well as how cmds.referenceQuery(es=1) works), and I think we're gonna need to change it's behavior. Right now, what it returns just isn't very useful.
To explain - there's basically two ways you can group refEdits in relation to reference nodes - by what ref node they're stored on, and by which objects they affect (and which ref node those objects are 'introduced' in). (These can be different reference nodes when reference nodes are nested...) So, if you're querying a reference node for it's ref edits, I can think of three possible results it could return which you might consider 'useful': 1) All the refEdits which affects nodes introduced by it 2) All the refEdits stored on it 3) All the refEdits which affect nodes introduced by it, but stored on the 'topReference' node The first two are potentially useful for partioning; ie, if you iterated over all the reference nodes in the scene, using either methods 1 or 2, you'd end up with all the ref edits, grouped in some sort of sane manner. The third is useful for getting the reference edits which "make sense" in the context of a given scene (see the docs on referenceQuery for only the edits on the topReference are the ones you'll usually care about in a given scene). Unfortunately, currently getReferenceEdits returns none of these - instead, it returns the ref edits which affect the it's nodes, and are stored on it. While this might seem appealing from a symmetry standpoint, it's actually not very useful when the node is not it's own 'topReference'. I really can't think of any situation in which you'd be interested in that particular set of edits. So, I think I'll probably alter the behavior of getReferenceEdits to instead return #3.... at least by default - the ideal would be to have flags to alter which set of edits is returned... This would break backward compatibility for this command, but since I can't imagine many people actually wanting the current behavior (as Erkan's case illustrates), I don't think that will be a big issue. Also - Erkan, haven't had a chance yet to look at your changeEditTarget issue... if you could supply some sample code illustrating a case where it's broken, it would help, though... - Paul 2010/6/29 Erkan Özgür Yılmaz <[email protected]>: > I was wrong about getting the right reference edits. The method, > FileReference.getReferenceEdits, returns the list of the edits done in the > reference node of that FileReference instance (FileReference.refNode). To > get the edits on a differenct reference node, which is what I want, I should > always give a reference node to onReferenceNode flag. The behaviour of maya > and pymel is correct... I was wrong about that in previous posts... Also > changeEditTarget is not working in my case, but its behaviour is somewhat > correct (where I don't expect that to happen). > > E.Ozgur Yilmaz > Lead Technical Director > eoyilmaz.blogspot.com > www.ozgurfx.com > > > On Mon, Jun 28, 2010 at 3:19 PM, Erkan Özgür Yılmaz <[email protected]> > wrote: >> >> I have a similiar problem with references: >> >> - trying to get referenceEdits for a referenced node inside another >> referenced node gives nothing until I specify that I want to get the edits >> those has been done in a specific reference node by using onReferenceNode >> flag whereas both maya and pymel documentation says not using >> onReferenceNode causes you to get all the edits. >> >> - trying to change edit targets with referenceEdit.changeEditTarget is not >> working in above case with or without onReferenceNode flag >> >> I'm not saying that these are bugs, may be they are not very well >> documented or I don't understand the correct usage... But I must say that in >> other cases I use these commands successfully to change referenced files >> with new ones. I only have problem when the referenced file also has some >> references to other files... >> >> E.Ozgur Yilmaz >> Lead Technical Director >> eoyilmaz.blogspot.com >> www.ozgurfx.com >> >> >> On Fri, Jun 18, 2010 at 1:30 PM, MarkJ <[email protected]> wrote: >>> >>> I've been deep in referencing hell for the last few weeks, trying to >>> debug some issues with the way Maya handles namespaces and references >>> in our pipeline. Part of this is to do a fast checker that will give >>> the guys a heads up as to the health status of the ref scenes they're >>> working on. I'm basically trying to get a printout of all failed >>> referenceEdits for all loaded referenceNodes. >>> >>> It looks like I've come across a possible bug in the way Pymel hadles >>> this. Code below is a simple test wrapper, in the scene I've got 3 >>> references all pointing to the same file. I know that all 3 have >>> failed edits on them and if I run the below code using the >>> cmds.refQuery I get all 3 as fails + the count. But using either of >>> the Pymel blocks I only get the fails caught for the first ref, not >>> the other 3. >>> >>> refNodes=[ref for ref in pCore.listReferences() if ref.isLoaded()] >>> for ref in refNodes: >>> print ref, >>> >>> len(pm.referenceQuery(ref.refNode,successfulEdits=False,failedEdits=True,es=True)) >>> print ref, >>> >>> len(cmds.referenceQuery(str(ref.refNode),successfulEdits=False,failedEdits=True,es=True)) >>> print ref, len(ref.getReferenceEdits(failedEdits=True)) >>> >>> anybody else come across issues with this? >>> >>> thanks >>> >>> Mark >>> >>> -- >>> http://groups.google.com/group/python_inside_maya > > -- > http://groups.google.com/group/python_inside_maya -- http://groups.google.com/group/python_inside_maya
