概括
本文介绍如何对 .nuke 目录进行故障排除并隔离哪些自定义可能会导致Nuke出现问题。
更多信息
Nuke可以通过添加插件、小玩意或其他定制来进行极大的定制。然而，由于许多自定义设置都是单独编写的，因此可能会导致Nuke行为不正确，甚至崩溃。
如果Nuke表现出不正确的行为或崩溃，那么首先要检查问题是否是由自定义引起的。
最好的方法是在安全模式下启动Nuke ，因为这会禁用所有插件、小工具和其他自定义设置（环境变量除外）。有关如何在安全模式下启动Nuke信息可以在以下文章中找到：
Q100038：在安全模式下启动Nuke / NukeX / NukeStudio / Hiero
如果在安全模式下测试后问题不再出现，则问题可能是由于添加到Nuke自定义操作而对Nuke的行为产生了不利影响。
此类自定义可以添加到许多位置，这些位置在下面的Nuke文档中列出：
加载 Gizmos、NDK 插件以及 Python 和 Tcl 脚本
为了进一步确定导致问题的自定义或自定义组合，我们建议以详细模式启动Nuke并按照本文中的步骤操作：
Q100112：以详细模式启动Nuke并隔离导致问题的潜在自定义
在进行故障排除时，如果删除 .nuke 文件夹可以解决问题，那么下一步就是隔离 .nuke 目录中的罪魁祸首自定义。
注意：详细的Nuke日志可能会显示与某些自定义文件相关的错误，这可能有助于缩小调查范围。
.NUKE目录
添加自定义项（例如脚本或小玩意）的最常见位置是位于用户主目录中的 .nuke 目录。下面列出了用户 .nuke 目录的默认位置：
Windows： C:\Users\<用户名>\.nuke
Linux： /home/<用户名>/.nuke
macOS： /Users/<用户名>/.nuke
注意：请注意，在某些操作系统上，.nuke 目录可能是隐藏的。如果是这种情况，请检查操作系统的文档，了解如何显示隐藏目录和访问 .nuke 目录。
故障排除步骤
检查 .nuke 目录中的自定义设置之一是否导致问题的最简单方法是将 .nuke 目录重命名为 old.nuke 之类的名称。下次Nuke启动时，它将创建一个新的 .nuke 目录。如果问题不再出现，则表明原始 .nuke 目录中的某些内容导致了该问题。
此时用户的主目录应包含：
old.nuke - 原始定制
.nuke - 上次Nuke启动期间创建的默认目录
在 old.nuke 目录中，要准确隔离导致问题的原因，一个好的方法是分半故障排除。其背后的想法是不断地将要测试的文件分成两半并测试每个部分以查看问题是否仍然可以重现，直到找出罪魁祸首。
注意：在执行此方法之前，请确保除了用户 .nuke 目录中的插件、小工具或自定义项之外，您的计算机上没有其他可用的插件、小工具或自定义项。
分半故障排除方法：
- 转到 old.nuke 文件夹并将一半的自定义文件复制到Nuke创建的新 .nuke 目录中。
- 重新启动Nuke并检查问题是否仍然出现。
- 如果问题仍然存在，请转到 .nuke 目录并删除一半文件。重新启动Nuke并查看问题是否继续发生。当问题仍然存在时，请重复此步骤，直到 .nuke 文件夹中只剩下一个文件。此时您已经确定了罪魁祸首定制。
- 如果将 old.nuke 目录的一半复制到新的 .nuke 中后问题不再出现，则删除 .nuke 目录的内容并从 old.nuke 目录中复制尚未测试的另一半，然后重复步骤3.
- 如果在复制并测试 old.nuke 目录内容的任意一半后没有出现问题，则表明自定义组合正在影响设置。在这种情况下，将整个 old.nuke 目录内容重新复制到新的 .nuke 中，然后一次删除一个自定义文件，启动Nuke并测试问题是否仍然出现，直到确定触发问题的最小文件集。
一旦隔离了单个自定义文件或重现问题的最小文件集，就可以进一步对这些文件进行故障排除。使用相同的分半故障排除方法，可以删除代码行，直到在一个或多个文件中识别出相关部分。
根据定制类型，TCL 或 Python 脚本等文件可以在文本编辑器中打开并进一步测试，编译的 NDK 插件等其他文件可能不可编辑，因此需要联系插件的创建者。
我们很遗憾听到
请告诉我们