A. 發售6年仍然火爆《上古卷軸5》什麼時候過氣
1.首先，要開啟papyrus的log記錄功能，否則你的老滾不會生成日誌文件。上面紅色箭頭表示文件目錄以及文件叫什麼。下面紫色箭頭和框體表示：找到[papyrus]（若沒有，則在底部新建一個），然後尋找框體內的三個參數（若沒有，在papyrus下新建），然後把它們三個改成1）如果你使用的是MO，你起效果的skyrim.ini在這個目錄：ModOrganizer\profiles\你的配置文件2.找到你的日誌文件當你做完第一步之後，無論你的游戲過程是否ctd，是否bug，只要你進入了游戲，就會生成日誌文件。文件在這個位置：Users\你的用戶名\Documents（這玩意是我的文檔）\MyGames\Skyrim\Logs同一時間，最多記錄4個log文件。最近一次游戲的日誌是Papyrus.0.log，上一次的是1，再上一次是2，最多到3，每一次是指你開啟tesv.exe，到tesv.exe結束。分析log的基礎就是讓log存在，上面的步驟是讓log存在的教程。下面開始講一講如何分析3.根據LOG內容出現的時間，我把LOG內容分為三種。運行游戲，讀檔，出現的LOG：這個所謂的檔，最好是在吸煙室，並且保證吸煙室只有你自己，沒有其他NPC，屍體，以及多餘的物品。這部分LOG內容中的ERROR，建議大家弄懂它們的意思。如果明確知道這些error是無所謂的，或者有所謂，但是你可以無視它，那麼就可以不解決，放著它。如果明確知道它會造成未來的某個嚴重問題，建議立即解決。游戲過程中，不會引起CTD的LOG：這些log多造成邏輯問題。比如一個給冰怨靈綁定搖尾巴動作的函數找不到object，只會造成冰怨靈沒搖尾巴，而不能ctd。這些error也是一樣，如果你覺得它無所謂，那麼不解決也是可以的。引起CTD的LOG：這些error出現在papyrus0.log的後部，也就是你發生CTD時間戳的地方。在這里必須多說幾句，ctd的原因有三種：文件缺失或者錯誤，當前游戲環境超過你的計算機處理能力，腳本嚴重錯誤。而你ctd之後查看log，ctd時間戳上的腳本錯誤，不一定是這次ctd的罪魁禍首，因為還可能是第二種原因引起的ctd.分辨的方法就是多次試驗，100%跳的就是腳本原因。如果知道是腳本原因了，就要排查這個錯誤。時刻記住，找到發生錯誤的mod，就卸掉它，這是不可取的，至於原因，我後面會說，當然也可能忘掉了.warning：警告。如果你不蛋疼，警告可以無視，因為它任何時候都不會引起ctd。但是你分析error的時候可能會借鑒一下這些警告。關於warning的解決方法，我在以前的帖子有所介紹。tieba..com/p/3873900066這篇帖子講的是warning：腳本不存在某屬性的解決方法。相當的基礎。補充：我們買游戲，是為了玩游戲。雖然玩游戲的動機可能有很多，但是以編程和修改游戲內容為樂趣的人並不多，絕大多數人玩游戲還是純粹為了游戲。我也是。所以說技術和游戲要平衡好.雖然我很尊敬DK大，但是她那樣研究技術會佔用很多時間（她的每一個mod的每一個文件都知道作用--）..我個人不會選擇這樣做。每個人都有每個人的看法，你們想怎麼玩，怎麼做，都是你們自己的選擇。4.如果CTD了，並且你已經確定某一條error或者某一堆error是引起這次ctd的原因，那麼怎麼呢？我隨便找個腳本錯誤的例子.[11/02/2014-12:21:22AM]Error:(000C6984):.stack:[(000C6984)].FXSetBlendVariableScript.SetAnimationVariableFloat()-""Line?[(000C6984)].FXSetBlendVariableScript.OnLoad()-"FXSetBlendVariableScript.psc"Line38[11/02/2014-12:21:22AM]：時間戳，你可以通過ctd發生的時間找到對應的腳本錯誤區域。一般引起ctd的error就是ctd時間戳，也就是最後的那個時間點上的錯誤。有時候也和稍微靠前的error有關。Error:(000C6984):.：錯誤，括弧里如果不是00或者uskp，smpc的序號，那麼可以明確知道是哪個mod出現的錯誤。如果是00或者uskp，smpc的錯誤，就比較蛋疼，你不知道哪個mod出問題了。就算你知道哪個mod出問題，直接刪掉是完全不可取的，因為刪mod會壞檔呀，好吧也可以用savetool或者pdt清一下存檔，但是不一定能完全清理干凈.後面是說究竟發生什麼錯誤了，比如不能找到object，object的類型不對呀等等等..[(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.bugbug區別於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使用習慣好壞的問題。