Thanks for checking me on this guys. Ivan, I am getting the same print out 
now... the runtime exception does indeed work. I realized I hadn't tested it 
properly -- DERP.

the "print nuke.allNodes()" was just a quick test call I threw in there -- in 
my code, I was actually running a block that included 
"nuke.selectConnectedNodes()" -- that spits out an unbelievable amount of junk 
when run on a script with "issues" -- any one know how to suppress all that 
garbage when run via shell? We should be able to run that in "quiet" mode.

Ivan, can you confirm you're getting the same behavior with 
nuke.selectConnectedNodes when running your "gizmos missing" script through 
something like:

##### process2.py ##########
import nuke
import os

def main():
  nk = os.path.abspath(sys.argv[1])
  try:
    nuke.scriptOpen(nk)
  except RuntimeError:
    print "A RuntimeError occurred: Ignoring..."
    pass
  # Moving on...
    activeWrites =  [ x['selected'].setValue(True) for x in 
nuke.allNodes('Write') if not x['disable'].value() ]
    if activeWrites:
        nuke.selectConnectedNodes()
        files = list(set([ x['file'].value() for x in 
nuke.selectedNodes('Read') ]))
        print "\n%s\n" % '\n'.join(files)
if __name__ == '__main__':
    main()
######################

nuke -t process2.py missing_gizmos.nk

It may be that this behavior is just inherent with the 
nuke.selectConnectedNdoes method -- the larger issue I'm looking to solve 
(lot's of posts on this issue -- not sure what the latest conventional wisdom 
is as of 2014)

Basically, I'd like to optimize selectConnectedNodes to be able to find out the 
files *actually used* by the active (non-disabled) write nodes to replace a 
"tree walker" which is very slow. Ultimately I'd like to implement a solution 
OUTSIDE of nuke that just parses the script file however, the .nk file leaves 
no clues (that I've found) that would suggest which Read nodes are actually 
used in any of the script trees. Since a shell based parse doesn't seem to be 
an option, and python seems overly slow, perhaps C++ is a better route to take?

Thanks again...

Cheers,
Jep 

_______________________________________________
Nuke-python mailing list
Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python

Reply via email to