关于游戏固定地点100%CTD的问题根源之个人剖析。。。标题可以再长点。。。

hansuper88

最近我也碰到了固定地点100%CTD的问题，是在雪漫通往风盔，需路过水合磨坊的两座石桥，只要靠近那两座桥就必CTD。。。

很恼人的问题，看过很多帖子，尝试了所有能想到的，和帖子经验中提到的各种方法，包括睡觉。。。

我的Mod很少，10余个。而且都是我长期不断开新档测试的mod，也有些是自己通过CK修改得来的esp文件，它们不会对游戏原版内容照成任何负面影响，这点我非常肯定。

好吧，各种死马当活马医的繁琐工序开始了：卸mod，改ini，还原en版本，删档建新档，大睡一个月等等等等。。

结果就是该跳还跳，完全不鸟你这套！！

无数次失败后，令我不得不重新审视解决问题的方法，由于我们太过急于解决问题，而忽略了问题的根源所在，那么有再多的解决方案，不能对症下药又有什么用呢？

我本是程序员出身，如今代码虽然写得少了，写代码时对于排查问题根源的本能也被唤醒了，是什么导致的100%固定点CTD?

用我们程序员的话来讲，看系统日志是最快捷最直接的方法，因为日志不会说谎也不会被古怪的问题气昏头脑！！

好吧，转了一圈N网，还真有点收获

在my game\skyrim\skyrim.ini 中添加
<
这样，在每次跳出后就会有详细的日志来说明是神马东西导致的跳出。。

进入游戏，传送至CTD点附近，靠近CTD点触发CTD。。。（LZ又啰嗦了）

返回 my game\skyrim，在目录下多了一个新目录log，里面会有一个子目录，script。。
再次打开，可以看到Papyrus.0.log 这样的日志文件，仔细阅读之下发现了一些端倪：

dunGeirmundsBossBattle.OnDeath() - "dunGeirmundsBossBattle.psc" Line 132
[07/06/2012 - 03:48:37AM] VM is freezing...
[07/06/2012 - 03:48:37AM] VM is frozen

嗯哼，在 dunGeirmundsBossBattle.psc 脚本中，OnDeath() 函数被视为未定义函数，声明一下，这个脚本是原版游戏自带脚本，也从未做过任何修改，（我是用svn管理data目录的，只要文件发生改变版本图标就会变化）

所以可以排除脚本语法错误，而之后，我打开了该脚本，发现 isdisable() 函数被 call Failed，调取失败。。

回想起刚刚路过的CTD地点，该点也是随机事件高发区，又恰巧一头冰龙路过。。而脚本中关于对boss对战的抽象就被激活了，而两个终极错误，导致了游戏端被挂起，啊，也就是我们所说的跳出。。。

所以，可以得出一个结论，CTD的固定点，一定是某个事件触发了令游戏挂起的脚本的终极错误导致的CTD。。

有了这个结论，我们就有了一个问题，到底是什么东西会令原版的脚本发生终极错误呢？

N网论坛上有一篇帖子说得非常明确了：
http://forums.nexusmods.com/index.php?/topic/703954-are-you-having-constant-exterior-ctds-ive-finally-found-your-solution/

那就是不正当删除mod，当这些mod包含调用游戏默认脚本时，就会在你的存档中记录这一条脚本关联，当mod被不正当的方式删除时，这条关联不会跟随mod一同删除，而留在你的存档中，当事件触发了该脚本，

则因脚本函数不能被 call，或 call back，而最终令游戏挂起。。

换而言之就是您目前的存档是损坏的，此时无论用什么解决方案都很难解决CTD，最好的情况也只是治标不治本。。

怎么解决？LZ 如果说出的话，肯定会挨拍的，但LZ还是要说，就是卸载调用默认脚本的mod，包括模型贴图脚本esp文件等，然后关键的地方来了，删除全部存档，关闭自动存档，重新开档，总比重装游戏好（被拍飞）

其实在其他人的CTD解决方案中，很大部分都是针对他们个人发生问题的临时解决方案，而分享给有完全一样问题的人。尽管他们说真的完全解决了，但并不一定适合在搜索答案的你，尽管你的问题和你搜索的解决

方案帖子很相似。。。

该CTD点之前是没有跳出现象的，那么LZ仔细回想CTD发生前后，装过三刀流的村正武器MOD，里面有一个武器效果的script和perk，我是觉得剑鞘过长才删除，而删除之前MOD武器是在LZ角色的背包里的。。。

那么一切就都解释得通了。。

当发生游戏问题时，诸位要冷静，仔细分析问题的根源，养成记录游戏错误日志的习惯，根据日志提供的线索揪出问题的结症，另外就是要仔细回忆发生问题前后在游戏内外您做过哪些动作和变动。。往往这些

最容易被忽略的细节，就恰恰是触发问题的关键。。