Thanks Randy, that didn't work either...we're OK though, but I'll ask here
if I can send a script to support to take a look for future reference.



On 21 August 2011 19:03, Randy Little <randyslit...@gmail.com> wrote:

> did you try doing a search for  "{}"    find every line with that and
> delete the whole line.   Script will come back if thats the problem.   (this
> is the result of the problems Nathan was mentioning I believe.)
> Randy S. Little
> http://www.rslittle.com <http://reel.rslittle.com>
>
>
>
>
>
> On Mon, Aug 22, 2011 at 07:13, Michael Garrett <michaeld...@gmail.com>wrote:
>
>> Thanks Nathan,  I checked in a text editor for old channel/layer names,
>> and there is one very basic gizmo in use (unless you can count gizmos copied
>> to groups).  Again, there are no clones.  Anyway we seem to have moved on
>> but maybe I can forward the script to the Foundry.
>>
>> Howard, I did start the copy/paste thing but not exhaustively.
>>
>> John, the duplicated comp trees are very modest and I think I only have
>> about 25 reads so I don' t think it's the "to many open files" issue.  I
>> tend to only hit that when I've had hundreds of Reads.
>>
>>
>>
>>
>> On 21 August 2011 14:07, Nathan Rusch <nathan_ru...@hotmail.com> wrote:
>>
>>>   The causes I’ve seen for the blank error message behavior when the
>>> script file is otherwise intact are bad clones and a few Gizmo-related bugs.
>>> Check any Gizmos in the script file for references to non-existent or
>>> non-default layer/channel names (the most common occurrence I’ve seen is a
>>> Gizmo with a linked ChannelMask knob that has a value of {rgba.red
>>> rgba.green rgba.blue rgba.alpha} or something similar that shouldn’t be
>>> saved in the script). Typically deleting the values and letting the knob
>>> revert to its default state will let the script load normally. Also,
>>> checking for Gizmo name collisions is probably worth a shot as well.
>>>
>>> Just some more ideas... Good luck.
>>>
>>> -Nathan
>>>
>>>
>>>  *From:* Howard Jones <mrhowardjo...@yahoo.com>
>>> *Sent:* Sunday, August 21, 2011 1:49 PM
>>> *To:* Nuke user discussion <nuke-users@support.thefoundry.co.uk>
>>> *Subject:* Re: [Nuke-users] Re: Disappearing nodes on script re-open
>>>
>>>  try copy and paste in sections then til you find the node(s) thats
>>> causing it?
>>>
>>> Howard
>>>
>>>   ------------------------------
>>> *From:* Michael Garrett <michaeld...@gmail.com>
>>> *To:* Nuke user discussion <nuke-users@support.thefoundry.co.uk>
>>> *Sent:* Sunday, 21 August 2011, 20:36
>>> *Subject:* Re: [Nuke-users] Re: Disappearing nodes on script re-open
>>>
>>> Thanks Ken, that is all very useful information.  The script file is
>>> intact because it just so happens the most recent version was left open for
>>> a local gui render the night before but if we copy/paste from that into a
>>> new script then we get the missing nodes.
>>>
>>>
>>> On 21 August 2011 12:18, Ken Littleton <ken.little...@gmail.com> wrote:
>>>
>>> The leading cause of truncated scripts is saving the script file to a
>>> overloaded network server.  Either Nuke quits before the script is saved or
>>> more likely, Nuke is killed by the user thinking it has hung.  This can
>>> happen locally as well if the machine is out of memory.
>>>
>>> I would recommend changing the autosave path to a local path.  This will
>>> speed up autosaves and act as a local repository in case the server screws
>>> you.  Another safety net is to have a copy of the script saved to the output
>>> folder when submitted to a render farm.
>>>
>>> I haven't seen the clone issue in quite a while.  Take a look at the
>>> script with a text editor, if it's truncated, it was a save issue.  If it's
>>> complete to the Viewer node, then the script has an issue.
>>>
>>>
>>> On 8/21/2011 11:33 AM, Michael Garrett wrote:
>>>
>>>  A bit more info:  in this case, there are four shots in the one script
>>> with four very similar node trees for each shot, and the last tree is
>>> completely gone except for the backdrop nodes.  Of the first three, they all
>>> have deleted nodes at different points in the tree even though the tree is
>>> very similar.
>>>
>>> We have managed to salvage stuff to the point where we are mostly OK but
>>> obviously we would like to know what happened.
>>>
>>> On 21 August 2011 11:27, Michael Garrett <michaeld...@gmail.com> wrote:
>>>
>>> Excuse my poorly worded email, I'm still waking up here.  There was only
>>> one kind of "blank error" message that is occasionally appearing on script
>>> open.  but some of the nodes are gone regardless.
>>>
>>>
>>> On 21 August 2011 11:19, Michael Garrett <michaeld...@gmail.com> wrote:
>>>
>>> I'm getting the random blank error message when re-opening a node graph
>>> from last night and some nodes have disappeared.  I'm also occasionally
>>> getting the "blank error" message on script open.
>>>
>>> There are no gizmo changes overnight or cloned nodes that can typically
>>> cause this kind of issue. Historically, merging the script or deleting the
>>> Viewers in a text editor could help  but there are other solutions I can't
>>> remember.
>>>
>>> Is the best way to fix this issue just to comb through the script in a
>>> text editor and copy/paste sections in?  Any magic bullets?  We're in 6.2v4
>>>
>>> Thanks,
>>> Michael
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Nuke-users mailing listnuke-us...@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
>>>
>>>  ------------------------------
>>> _______________________________________________
>>> 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
>>
>
>
> _______________________________________________
> 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