You should be able to Popen a new copy of Nuke (with the clean script) and then 
immediately quit() your current session.

-Nathan



From: Erik Winquist 
Sent: Wednesday, April 18, 2012 3:03 PM
To: nuke-users@support.thefoundry.co.uk 
Subject: Re: [Nuke-users] Re: ??? redguard1.glow ???


Yeah, sorry..   i wasn't very clear.

We're still cleaning the text of the .nk script via regex, but like you 
describe, that's happening from a python function in nuke once the script is 
open.  An addOnScriptLoad() callback checks the script's channels as I'd 
described previously and if any suspect channels are discovered, at that point 
the user is alerted and given the choice whether they want to clean the script 
or not.  If they choose to, a backup copy of the script is made and then the 
.nk text is cleaned and nuke immediately exits.

I'm interested in how you're launching a new nuke instance from another 
process.  Re-opening the cleaned script automatically would definitely be 
preferable to just having nuke quit like we're doing now.


The main downside I'm curious about with searching for specific channels as 
you're doing is having to maintain a list of 'baddies' to search for.

erik


John RA Benson wrote: 
  The big headache is, however, that pesky "add_layers" with bad channels will 
still be stuck in the script. At least with 6.2, the only way to remove the 
layer was with a text editor, which is why I favored the regex approach outside 
of nuke.  In practice, we run a version of this from nuke to clean up a lot of 
issues. Hitting the button does a few things with nuke to fix internal stuff, 
but then saves the script and runs this solely as a text operation on the file. 
The open (and infected) script is then closed and the cleaned up script is 
relaunched (but as a separate process - just using nuke.scriptOpen(...) ends up 
just re-introducing the bad layers into the already open session. Despite 
'closing' it, the bad layers and channels are still in memory).

  
http://www.nukepedia.com/python/regular-expressions-re-module-to-fix-broken-scripts/#findChannels
 covers using the blacklisted layers and finding the channels inside them. 
Since we use '-?' (find a match 0 or 1 times) as a prefix to the regex 
expression for the channel we're looking for (based on the bad layer's 
channels), we find both 'rgb.red' and '-rgb.red'.

  A whitelist of channels to keep is a good idea, but so far hasn't been 
necessary. I guess in our case, when a bad channel has been introduced, it 
hasn't been carrying a good channel with it in the add_layers function.

  Cheers
  JRAB


  Erik Winquist wrote: 

    We've been wrestling with this like many others.

    Instead of searching for specific layers/channels in specific 
configurations, I've instead opted to compare what channels Nuke says a script 
contains:

    nuke.channels()

    vs. what channels all of the script's nodes report they're using:

    allnodes = nuke.allNodes(recurseGroups=True)
    allchans = []
    for n in nuke.allNodes():
        for c in n.channels():
            allchans.append(c)

    scriptchans = set(nuke.channels())
    usedchans = set(allchans)
    notused = scriptchans - usedchans

    In the above example, 'notused' is a python set of any channels that aren't 
actually used by the script.

    This, combined with a whitelist of channels that should always be ignored 
because they're OK (like depth.Z) and a blacklist of channels that should 
always be removed, because they cause damage (like "rgb.red") pretty much 
catches anything that could come up now, or in the future.

    The one place I've noticed that this doesn't work is when a node has one of 
said channels specified in the alpha slot but the alpha slot isn't turned on 
for that node.   This instance shows up in the .nk script as "-rgb.red".  If 
you remove the "add_layer .." from the .nk script and don't remove all 
references to that channel, Nuke will not load anything beyond that line in the 
.nk script and you'll have an incomplete script in the DAG.

    erik



    John RA Benson wrote: 
      This thread finally prompted me to do some sharing - 

      I've fixed a lot of bad layers in scripts with some simple python (well, 
with regular expressions, which are simple but can be confusing). Some of these 
scripts were recovered from dead because of broken clones or empty {}. The 
usual...

      
http://www.nukepedia.com/python/regular-expressions-re-module-to-fix-broken-scripts/

      The tips not only clean up dummy layers like redguard - whatever you need 
to clean up - but also address some of the other issues that bugger scripts, 
like bad clones and the weird {} issue.

      Since it's just working on text, the script works on gizmos (often the 
source of mystery layers) that might have junk in them as well as nuke scripts 
that have been infected. 

      Flavor to taste and enjoy -
      jrab


        Frank Rueter wrote: 
          Yeah, this is the single most annoying/dangerous bug in Nuke. I've 
encountered this numerous times over the years (since D2Software days 
actually). It would be really nice to have some sort of collision handling if 
anything threatens to interfere with the default channel sets.

          Have you done a text search for the fully qualified channel names 
("redguard.whatever") in all of the files in Nuke's plugin path?


          On 4/10/12 7:47 AM, thoma wrote: 
            thanks frank - i did just that and it has worked so far. The 
strange thing is I did find one gizmo that had a redguard layer in there but 
not with all of the channels that were showing up in my script - also no hint 
of why they would start replacing rgba. Anyway thanks

            Thomas

             

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


       

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

-- 
erik winquist
weta 
digital----------------------------------------------------------------------------
_______________________________________________
Nuke-users mailing list
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users

   

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

-- 
erik winquist
weta digital

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

Reply via email to