I have to agree with Ean that the simplest solution is probably to keep your
own copy of the gizmo, and then just insert it higher on the plugin path so
that when the pipe team updates the outside copy, your changes are preserved.
Then, if you ever get a new version, you can use a diff-patch combo (or just a
nice merge tool like p4merge) to integrate the changes without blowing your
modifications away. Either that, or just have a talk with your pipe guys so
they stop stepping on your toes...
However, if you really want to change the node’s class, you can use a TCL
loader script named with your alternate name, that loads the gizmo:
# file: sample_test.tcl
load sample
With this file on your Nuke path, if you create a "sample_test" node, it will
be an instance of the "sample" gizmo, but calling `node.Class()` on it will
return "sample_test".
You could even make in-place modifications to its knob values immediately if
you were so inclined (though rewriting Python knob code could get tedious).
-Nathan
From: Den Serras
Sent: Friday, January 17, 2014 9:29 AM
To: Nuke Python discussion
Subject: [Nuke-python] Re: Change knob class
Thank you for responding! I have used that trick, but I'm trying to avoid it
here because the other FX house tends to send us copies of the gizmo regularly
and when they do our Pipe team unknowingly overwrites my hack. Therefore a
better option, i think, is to have a different gizmo. It's easy to change the
class in the script by editing the .nk itself, which is what I have the artists
doing now, but I wonder if there's a way I can do the same thing completely
inside Nuke...
On Friday, January 17, 2014, Ean Carr <m...@eancarr.com> wrote:
Hey Den,
Not sure I understand your problem exactly... but here goes. You shouldn't
need to script anything in python to actually replace the gizmo with your own
version. A gizmo, by definition, allows you to do that simply by swapping out
the gizmo file in the plugin path with a new one of the identical name. So just
name your replacement version "sample.gizmo" and it'll be loaded instead of the
original on any script load which references it. If your version has the same
knob names and types, Nuke should maintain the right values.
-Ean
On Thu, Jan 16, 2014 at 5:33 PM, Den Serras <javascript:_e({}, 'cvml',
'denserras...@gmail.com');> wrote:
Morning everyone,
I have to work with .NKs sent from a different VFX house with a very
different pipeline, and that includes a gizmo with some python that looks to
their environment variables. I have built a duplicate of that node that fixes
the code, and I'd like to be able to pass to my team a script that would easily
change the gizmo from one to the other without having to worry about values
changing. My idea is to change the Class() from "sample.gizmo" to
"sample_fix.gizmo", but I can't get that to work other than just to change the
.nk file outside of Nuke. Any thoughts?
Thanks!
Den
_______________________________________________
Nuke-python mailing list
javascript:_e({}, 'cvml', 'Nuke-python@support.thefoundry.co.uk');,
http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
--
--------------------------------------------------------------------------------
_______________________________________________
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
_______________________________________________
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
