大家好，小晉來為大家解答以上問題，上古卷軸5開始怎么跳出去，上古卷軸5 跳出很多人還不知道，現在讓我們一起來看看吧！
解決方案：
1.首先打開紙莎草的日志記錄功能，否則你的舊卷不會生成日志文件。
上面的紅色箭頭表示文件目錄和文件名。
下面的紫色箭頭和方框表示：找到【紙莎草】(如果沒有，在底部新建一個)，然后在方框中找到三個參數(如果沒有，在紙莎草下面新建一個)，然后將它們改為1)。
如果您使用MO，您的有效skyrim.ini位于以下目錄中：mod organizer \ profiles \ your profile。
2.找到您的日志文件。
當你完成第一步，不管你的游戲進程是ctd還是bug，只要你進入游戲，都會生成一個日志文件。
文件在這個位置：Users\ your username \Documents(這個東西是我的文檔)\MyGames\Skyrim\Logs。
同時，記錄多達4個日志文件。最后一局的日志是Papyrus.0.log，最后一個是1，最后一個是2，最大3。每一次，你都從tesv.exe出發，在tesv.exe結束。
日志分析的基礎是讓日志存在，以上步驟是讓日志存在的教程。
先說怎么分析吧。
3.根據日志內容出現的時間，我把日志內容分為三種。
運行游戲，讀取文件，出現的日志：這個所謂的文件，最好是在吸煙室，并且要確保吸煙室里只有你自己，沒有其他NPC，尸體，額外物品。這部分日志內容有誤，建議你理解它們的意思。如果你清楚地知道這些錯誤無關緊要，但你可以忽略它們，那么你可以不解決它們。如果很明顯會在未來造成嚴重的問題，建議立即解決。
游戲過程中，不會造成CTD的日志：這些日志往往會造成邏輯問題。比如一個綁定搖尾巴動作給冰魔的函數找不到對象，只會導致冰魔不搖尾巴，而不是ctd。這些錯誤也是如此。如果你覺得無所謂，那么不解決也是可以的。
導致CTD的日志：這些錯誤出現在papyrus0.log的后面，這是您的CTD時間戳出現的地方。ctd的原因有三：文件缺失或錯誤，當前游戲環境超出你電腦的處理能力，腳本嚴重錯誤。而當你查看ctd之后的日志時，ctd時間戳上的腳本錯誤不一定是這個ctd的罪魁禍首，因為也可能是第二個原因造成的.辨別的方法是多次嘗試，100%跳轉是腳本原因。如果您知道是腳本的問題，您應該解決這個錯誤。永遠記住，發現錯誤的mod就卸載是不可取的。至于原因，我以后再說，當然也可能忘了。
警告：警告。如果你沒有蛋疼，警告可以忽略，因為不會隨時引起ctd。但是當您分析錯誤時，您可以從這些警告中學習。至于警告的解決方法，我在之前的帖子里介紹過。
《Tieba.baidu.com/p/3873900066's郵報》是關于警告：劇本中的某個屬性是無解的。相當有基礎。
補充：我們買游戲就是為了玩。雖然玩游戲的動機可能很多，但是對游戲內容編程修改感興趣的人并不多。大多數人玩游戲純粹是為了游戲。我也是。所以說技術和游戲要平衡好.雖然我很尊重DK大學，但是她學那樣的技術會花很多時間(她每個mod的每個文件都知道功能-).我個人不會選擇這樣做。每個人都有每個人的看法。你想怎么玩，怎么做，都是你自己的選擇。
4.如果ctd壞了，并且你已經確定某個錯誤或者一堆錯誤是這個CTD的原因，那么你該怎么辦？
我只是在尋找一個腳本錯誤的例子。
[11/02/2014-12:21:22am]錯誤：(000 c 6984): cannotfindvariablenamedftoggleblend。
堆棧：
[(000 c 6984)]. fxsetblendvariablescript . setanimationvariablefloat()-' '行？
[(000 c 6984)]. fxsetblendvariablescript . onload()-' fxsetblendvariablescript . PSC '第38行
【11/02/2014-12:21:22am】:時間戳，可以通過ctd發生的時間找到對應的腳本錯誤區。一般造成ctd的誤差是ctd時間戳，也就是最后一個時間點的誤差。有時與稍早的誤差有關。
錯誤：(000 c 6984)3360 CannotFindVriableNamedToggle Blend。錯誤。如果不是00或者括號里的uskp和smpc的序列號，那么就可以知道是哪個mod出現了錯誤。如果是00或者uskp，smpc的錯，那就更痛苦了。你不知道哪個mod壞了。即使知道哪個mod有問題，直接刪除也是完全不可取的，因為刪除mod會斷檔。嗯，你也可以用savetool或者pdt來清除存檔，但是可能不會完全清除。
[(000C6984)]：這是發生錯誤的referenceID。關于referenceID的相關知識，我在后面會講一下。
FXSetBlendVariableScript：這是發生錯誤的腳本。在data/scripts（或者某bsa下）一定會有一個同名的PEX文件，開源的mod或者原版（要安裝ck），會有psc源碼文件。
SetAnimationVariableFloat()：這是發生錯誤的函數指令。這個函數可以是native類型（也就是不需要在psc中中定義的函數，這些函數是游戲本身就識別的），也可以是psc內定義的新函數，也可以是skse擴展的函數。
""Line?：這是被編譯的psc內，發生錯誤的函數的行數。注意，反編譯之后的psc不能用這個行數找到函數。
OnLoad()-"FXSetBlendVariableScript.psc"Line38：這里，分別是發生錯誤的event，以及發生錯誤的文件，以及event所在的行數。所謂事件，就是告訴游戲什么時候執行事件下面的語句。
5.分析和解決思路
首先分兩個路徑，都要去做。一個是腳本，一個是入口。
第一路徑，通過psc文件的指示，去尋找起作用的那個psc文件。
要知道，如果原版有A.psc文件，uskp也有A.psc文件，Xmod也有A.psc文件，那么起作用的一定是Xmod的。怎么才會起作用呢？排在相對后面，并且入口中要掛載這個腳本文件。
找到psc文件之后，打開看，看懂它在做什么。
看的第一遍，看一下每個event和function下的主要函數指令都在做什么。
看的第二遍，針對出錯的位置，進行分析。
這需要papyrus語言的知識，我已經說過了。
如果沒有psc文件，那就只能找到pex文件，然后用TESVTranslator反編譯。這個軟件絕大多數時候是用來做漢化的。我這種懶比肯定不會去做漢化的。
方法：首先打開軟件，然后點擊文件，loadpapyrusPEX，然后在下面的pexdata下就會有反編譯的腳本內容。
如果是一個20行以內的小腳本，用這個方法還稍微可以。但是1200行的腳本，就算你看懂，想修改也需要重寫成正常的papyrus語法，否則無法通過ck編譯。
第二路徑：根據出錯的referenceID，尋找出錯的入口。
需要注意的是，referenceID是baseID實例化之后的id，在ck和edit下可能會找不到。
什么時候能找到？這個reference在文件制作的時候就已經被實例化了，例如所有有名字的npc，放在某箱子里的鑰匙等等。還有就是這個東西不需要實例化。
什么時候找不到？這個reference是在游戲過程中實例化的。例如無名字的龍。
那么對于找不到入口的referenceID怎么辦呢？
打開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不能作用在一個noneobject上.....
none是啥？
為啥那玩意變成none了？
這些log都不會給出。你需要自己分析，這個難度非常大....甚至modder都不一定能分析出來....畢竟游戲底層的東西只有b社員工知道。
所以嘛，錯誤能避免盡量避免。說到底，還是一個mod使用習慣好壞的問題。
本文到此結束，希望對大家有所幫助。