上古卷轴5 Papyrus的LOG日志分析，科学解决ctd,bug的方法

更新日期：2016-06-15 16:00:04 来源：网络搜集 编辑：快猴网-孙猴子
1.（起手装x）上古卷轴5本身是一个B社的一个魔幻RPG沙盒游戏，原版就那样，你们都知道的。但是B社给出了CK这个工具，我们可以修改它，让它变成我们希望的样子。TESV是一个程序，CK是一个开发者工具，做MOD的过程也就是开发（修改）一个程序（的一部分）的过程。我一直把做mod放在编程范畴，所以我有觉悟。我在修改程序，所以任何错误都是可能发生的，所以我必须付出一定时间来调试和解决错误。为什么说这些呢？因为就怕这个观点—上古卷轴5只是一个游戏，我玩个游戏还学编程？你一旦有这个观点，就懒得去弄一些东西了，遇到问题也没办法解决了，毕竟你什么都不会，我跟你解释变量null，数组溢出…之类的名词，你也听不懂，对吧。so，这个觉悟还是比较重要的。
2.如果你玩2分钟，LOG就刷出了500K以上，我只能说，你的存档已经毁的差不多了，或者mod冲突非常严重。那么多的error，够你当小说看了，还分析个球。
3.如果你很随便，喜欢玩mod就装，不喜欢就卸掉，或者不喜欢看mod说明，检查兼容性等等…那么你的老滚之路会非常艰难。
4.看这篇帖子需要两部分能力，一个正常电脑使用者的IQ，以及papyrus语言的语法知识（不需要你知道太多的函数和事件的意义，这可以去ck官网查）

=================================================================
好了废话说这些。下面开始吧。
1.首先，要开启papyrus的log记录功能，否则你的老滚不会生成日志文件。
方法：

上面红色箭头表示文件目录以及文件叫什么。
下面紫色箭头和框体表示：找到[papyrus]（若没有，则在底部新建一个），然后寻找框体内的三个参数（若没有，在papyrus下新建），然后把它们三个改成1）
如果你使用的是MO，你起效果的skyrim.ini在这个目录：ModOrganizer\profiles\你的配置文件
本部分end
2.找到你的日志文件
当你做完第一步之后，无论你的游戏过程是否ctd，是否bug，只要你进入了游戏，就会生成日志文件。
文件在这个位置：Users\你的用户名\Documents（这玩意是我的文档）\My Games\Skyrim\Logs
同一时间，最多记录4个log文件。最近一次游戏的日志是Papyrus.0.log，上一次的是1，再上一次是2，最多到3，每一次是指你开启tesv.exe，到tesv.exe结束。

==============================================================
分析log的基础就是让log存在，上面的步骤是让log存在的教程。
下面开始讲一讲如何分析。

warning：警告。如果你不蛋疼，警告可以无视，因为它任何时候都不会引起ctd。但是你分析error的时候可能会借鉴一下这些警告。关于warning的解决方法，我在以前的帖子有所介绍。
tieba.baidu.com/p/3873900066 这篇帖子讲的是warning：脚本不存在某属性的解决方法。相当的基础。
补充：我们买游戏，是为了玩游戏。虽然玩游戏的动机可能有很多，但是以编程和修改游戏内容为乐趣的人并不多，绝大多数人玩游戏还是纯粹为了游戏。我也是。所以说技术和游戏要平衡好…虽然我很尊敬DK大，但是她那样研究技术会占用很多时间（她的每一个mod的每一个文件都知道作用- -）…我个人不会选择这样做。每个人都有每个人的看法，你们想怎么玩，怎么做，都是你们自己的选择。
4.如果CTD了，并且你已经确定某一条error或者某一堆error是引起这次ctd的原因，那么怎么办呢？
我随便找个脚本错误的例子…
[11/02/2014 - 12:21:22AM] Error: (000C6984): cannot find variable named fToggleBlend.
stack:
[ (000C6984)].FXSetBlendVariableScript.SetAnimationVariableFloat() - “” Line ?
[ (000C6984)].FXSetBlendVariableScript.OnLoad() - “FXSetBlendVariableScript.psc” Line 38
[11/02/2014 - 12:21:22AM]：时间戳，你可以通过ctd发生的时间找到对应的脚本错误区域。一般引起ctd的error就是ctd时间戳，也就是最后的那个时间点上的错误。有时候也和稍微靠前的error有关。
Error: (000C6984): cannot find variable named fToggleBlend.：错误，括号里如果不是00或者uskp，smpc的序号，那么可以明确知道是哪个mod出现的错误。如果是00或者uskp，smpc的错误，就比较蛋疼，你不知道哪个mod出问题了。就算你知道哪个mod出问题，直接删掉是完全不可取的，因为删mod会坏档呀，好吧也可以用savetool或者pdt清一下存档，但是不一定能完全清理干净…后面是说究竟发生什么错误了，比如不能找到object，object的类型不对呀等等等…
[ (000C6984)]：这是发生错误的reference ID。关于reference ID的相关知识，我在后面会讲一下。
FXSetBlendVariableScript：这是发生错误的脚本。在data/scripts（或者某bsa下）一定会有一个同名的PEX文件，开源的mod或者原版（要安装ck），会有psc源码文件。
SetAnimationVariableFloat() ：这是发生错误的函数指令。这个函数可以是native类型（也就是不需要在psc中中定义的函数，这些函数是游戏本身就识别的），也可以是psc内定义的新函数，也可以是skse扩展的函数。
“” Line ?：这是被编译的psc内，发生错误的函数的行数。注意，反编译之后的psc不能用这个行数 找到函数。

OnLoad() - “FXSetBlendVariableScript.psc” Line 38：这里，分别是发生错误的event，以及发生错误的文件，以及event所在的行数。所谓事件，就是告诉游戏什么时候执行事件下面的语句。event 妹子表白（妹子 我） if 妹子萌萌哒 ，我.setgirlfriend（妹子） 随便写一段脚本就知道event是是什么意思咯。当然这些大白话是不能通过编译的…别闹…

5.分析和解决思路
首先分两个路径，都要去做。一个是脚本，一个是入口。
第一路径，通过psc文件的指示，去寻找起作用的那个psc文件。
要知道，如果原版有A.psc文件，uskp也有A.psc文件，Xmod也有A.psc文件，那么起作用的一定是Xmod的。怎么才会起作用呢？排在相对后面，并且入口中要挂载这个脚本文件。
找到psc文件之后，打开看，看懂它在做什么。
看的第一遍，看一下每个event和function下的主要函数指令都在做什么。
看的第二遍，针对出错的位置，进行分析。
这需要papyrus语言的知识，我已经说过了。
如果没有psc文件，那就只能找到pex文件，然后用TESVTranslator反编译。这个软件绝大多数时候是用来做汉化的。我这种懒比肯定不会去做汉化的。
方法：首先打开软件，然后点击文件，load papyrusPEX，然后在下面的pexdata下就会有反编译的脚本内容。

如果是一个20行以内的小脚本，用这个方法还稍微可以。但是1200行的脚本，就算你看懂，想修改也需要重写成正常的papyrus语法，否则无法通过ck编译。
第二路径：根据出错的reference ID，寻找出错的入口。
需要注意的是，reference ID是base ID实例化之后的id，在ck和edit下可能会找不到。
什么时候能找到？这个reference在文件制作的时候就已经被实例化了，例如所有有名字的npc，放在某箱子里的钥匙等等。还有就是这个东西不需要实例化。
什么时候找不到？这个reference是在游戏过程中实例化的。例如无名字的龙。
那么对于找不到入口的reference ID怎么办呢？
打开savetool最新版本，搜索这个ID，可能会找到这个reference的相关信息，你可以通过这些信息推断出它是什么入口实例化的。你还可以通过直接搜索出错的脚本，在所得的信息中推断入口是什么。
不过有些时候依然找不到入口，为什么呢？
因为实例化这个过程，在你上次存档到这次ctd之间…那就只能gg了。

知道脚本内容和出错入口，大概就可以知道mod这个部分究竟在做什么。

知道这些信息，如何解决呢？
你要通过这些信息去想，为什么这个脚本会出错？
然后针对原因，进行入口的修改/脚本的修改并且重新编译。之后再处理存档（一般来说是删掉出错脚本的相关内容，或者修改其中的value）。
我说这么少的内容，是有原因的。因为错误有无数个，每个错误的解决方法都不一样，我怎么写呢？

6.bug
bug区别于ctd，它不会引起闪退，你的游戏还可以继续。
不过bug也分为良性bug和恶性bug。
良性bug只是类似武器架E不动了，冰怨灵卡着不动了等等…这些bug你能忍的话就不需要去解决。
恶性bug会让你的游戏无法继续，例如某任务卡住，某音乐播放不停止。
解决bug的思路和ctd差不多。只是把ctd时间戳改成bug嘛。
不过建议尝试看log之前，先读靠前的存档，多次试验，如果bug没了，就不用累死累活了…

7.log的局限性
很多时候，log给出的信息，只是xxx不能xxx，因为xxx不能作用在一个none object上…
none是啥？
为啥那玩意变成none了？
这些log都不会给出。你需要自己分析，这个难度非常大…甚至modder都不一定能分析出来…毕竟游戏底层的东西只有b社员工知道。
所以嘛，错误能避免尽量避免。说到底，还是一个mod使用习惯好坏的问题。

8.最后
我可以帮大家看一些log。先说好，不一定能看懂。我的能力也是有限的。
让我看log需要满足以下条件，当然，这也是为了你能解决问题。
1.把papyrus.log上传百度云，把地址给我。
2.你在ctd之前，在做什么。大概就是说，你要讲明白，你怎么玩着就ctd了。
3.多次试验的结果。千万别拿概率性ctd来逗我。因为什么样的error会ctd，我也不知道。
4.你的modlist拿出来，必须保证排序正确。
5.你的贴吧至少5级。我要确定你不是伸手*。可能你问个问题只需要10分钟，但我给你看脚本需要几个小时，你问完就跑了，我怎么感觉我像个sb一样？
6.态度不能太恶劣。
7.我不能解决的话不能喷我
8.哦对，不能卸载过mod。如果卸载过，请指出卸载的mod是什么，是否带脚本。如果不能给出这两点信息，或者卸的太多了…那抱歉…

好吧…写技术贴是很累的，大概就写这么多吧。