Re: [問題] Fallout 4 MOD 建議

看板RealPlaying作者 (怒海潛將)時間6年前 (2018/02/10 18:26), 6年前編輯推噓3(3推 0噓 29→)
留言32則, 4人參與, 6年前最新討論串3/3 (看更多)
※ 引述《Yuiwa1996 (黑帽紳士雨蛙君)》之銘言： : 另外我敗這款遊戲的最大原因是，自己很喜歡可以隨意蓋東蓋西的遊戲（比如rim world)，也看了琳瑯滿目的Settlement Mod，但聽說彼此之間很容易衝突崩潰，所以裝之前在聽聽版上的建議 ? 作為同樣喜歡蓋東蓋西的同好，我就只針對這部分回個文。 作為「我們人手不夠」的Fallout 4，我們可以說這代主打的恐怕「只剩下」工房模式這 個功能了。這是基本上在Settlement(我自己比較喜歡翻成定居地這個中性字彙)有限的 容積內任意使用物件建造與布置的系統。 在Fallout 4發行的早期，最有名的限制是不敷使用的工房目錄分類關鍵字的問題，而現 今這個問題也靠著幾種方法基本上不復存在。那麼原Po所指的問題還有什麼？ １、原版建物項目被多個模組重複使用、改變設定。 　　這個部分其實不光只有工房物件，任何更動遊戲設定的模組都有可能發生。 ２、定居地清理(scrap clean)類的模組。 　　這類模組首先會將原版未加入scrap list的物件補加入。但有時候不只是落葉、地 上的瓦礫，有時候一些靜態的，可能被當成前項所說的被更改項目也加入其中，這樣就 會造成衝突，而scrap list的影響，即便排到後排，仍有可能影響到該物件被建造時的 狀態。 　　此外還有導航網格(navmesh)故障的情況。所有廢土建築師都能痛徹心肺的理解到 Beth的Creation Engine在這方面的運作真是渣到無以復加。導航網格就是定居者( settler)的認路AI用以辨識何者能夠通行或抵達的平面座標(但很多情況下會被無形的 碰撞給干擾)，這在先天上這部分問題非常多也難以處理，你常會看到定居者呆若木雞 或站在不可思議的位置。 　　有時場景設計師為了讓地面崎嶇，會製作數個土墩或土丘放置在環境上，然後將導 航網格鋪在上面，而清理模組會將這些清理掉，卻沒有重建底下的導航，導致此處無法 通行。 　　與此相關的還有定居地本身的大改，如庇護山丘戰前版本植栽濃密變更、表面貼圖 (我忘了正式的用語)替換等等。 ３、定居地的範圍變更。首先要提醒的是，這類模組相當排他，尤其是修改原版既存的 定居地範圍(這通常會以定居地工房為中心來開啟)。無論你使用的是原版還是原創地點 的修改(擴展)，都要注意周遭是否有其他的定居地範圍。 　　定居地範圍一般分為：可建造範圍、定居者活動範圍，以及在工房模式下顯示的邊 界。這三種互不關聯，舉例來說一旦變更前兩者其中之一的範圍，則邊界範圍就沒有意 義；邊界是根據一個範圍模型(nif)為基準，在CK中只能將其放大縮小或改變高度而不 能改變形狀，模組作者多是挑選預設定居地的邊界來修改，但也有例外。 ４、動態工房目錄的子分類建立。這裡是指於遊戲內利用腳本生成的模組目錄，也是工 房目錄混亂與開啟延遲的元兇(笑)。 　　利用腳本動態建立模組專屬目錄，起源自當初為解決目錄關鍵字不足的問題而發展 出來的，詳細原理不在討論中，總之是不靠plugin檔案，直接寫在存檔當中相當節約的 方法。它的問題在於： 　　掛載後，無卸載或卸載不全的情況。通常這個問題可利用一個室內的、獨立的空間 進行進度的存取來設法排除。 　　同樣利用腳本生成的其他目錄模組所造成的佔位衝突。當你新加載的建築類模組沒 在工房目錄中發現(如果位置已經確定)的話，代表發生佔位衝突。這時就必須釋放掉工 房目錄中該項目錄下所有的動態生成目錄，使系統重新掃描排位來解決。 　　以上就是定居地工房系統可能出現的與模組有關的問題。當然還有其他比較少見的 問題，例如缺少某特定物件(排除需要建築條件後)，或不同模組更新，patch之間不及 更新，甚至因為漢化後才建立patch導致ID辨識異常等等...。這些是我在Fo4上千小時( 只有十分之一的時間在正經的跑任務)後的一些心得，隨手寫的很亂請見諒。 　　我自己也是有比較推薦安裝的定居地相關模組，有興趣的話就再分享吧。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.32.32.89 ※ 文章網址: https://www.ptt.cc/bbs/RealPlaying/M.1518258391.A.F04.html
推
02/10 20:19, 6年前 , 1F
推分享
02/10 20:19, 1F
推
02/12 00:18, 6年前 , 2F
我是原PO，身為一名原建設愛好者，突然對被迷失在輻射
02/12 00:18, 2F
→
02/12 00:18, 6年前 , 3F
少女世界的我感到羞愧Lex.....
02/12 00:18, 3F
→
02/12 00:21, 6年前 , 4F
輻射少女lol
02/12 00:21, 4F
→
02/12 00:50, 6年前 , 5F
我在老滾輻射都不太裝美化...這代更不用說了...工房模式
02/12 00:50, 5F
直接編輯好了... 首先要知道為什麼工房模式會限制建造容積(Size)。當我們進入一個定居地時，即便還 沒開啟當地工房，有很多東西已經開始在計算和載入了。其中一個就是關於物件占用的 容積。 Fo4的容積是以模型的多邊形面數來計算的，所以丟在地上的一支槍會比一張桌子更佔容 積。混凝土牆壁會比棚屋牆壁要比較不占容積是這個道理。除此之外，照明的形狀與廣度 動態光影等等也是根據範圍越發吃資源。 另外也不要以為只有顯卡會比較吃重，在你開啟工房時也是考慮你的CPU與RAM處理能力， 此外定居者的AI認路導航，資源的變動也是即時在運算的。有時看到一名定居者在地面 發呆有時不一定是目標地路徑卡住，而是在重複算如何走。當你把定居者的垂直活動範 圍調高，這樣的計算也可能拉高... 一直在處理這些元素的情況下，我實在不忍再多各種高清美化的替換或渲染了... ※ 編輯: deepseas (114.32.32.89), 02/12/2018 01:02:59
推
02/12 02:23, 6年前 , 6F
size解除還有問題就是，如果你蓋很大的話，撞到FFFFFFF
02/12 02:23, 6F
→
02/12 02:24, 6年前 , 7F
的formid上限只是遲早的事情。
02/12 02:24, 7F
→
02/12 02:24, 6年前 , 8F
當然啦，在那之前，CPU、GPU、記憶體消耗可能會先有問
02/12 02:24, 8F
→
02/12 02:25, 6年前 , 9F
題，假設都能撐住的話，一直有新東西加進去，遊戲很快
02/12 02:25, 9F
→
02/12 02:26, 6年前 , 10F
就會用完能用的id了(第一行後面少一個F)
02/12 02:26, 10F
→
02/12 02:26, 6年前 , 11F
雖然有id回收機制，但是不保證不會有問題...
02/12 02:26, 11F
→
02/12 02:28, 6年前 , 12F
然後CC出現的新ESL格式，這東西看起來能解決formid跟
02/12 02:28, 12F
→
02/12 02:29, 6年前 , 13F
plugin上限(0xFE，FF是系統保留，會寫進savefile)
02/12 02:29, 13F
→
02/12 02:29, 6年前 , 14F
問題，但實際上一般不建議modder用此格式。y
02/12 02:29, 14F
→
02/12 02:30, 6年前 , 15F
因為ESL建立時會重新排序ID，很可能下次要更新重做ESL
02/12 02:30, 15F
→
02/12 02:30, 6年前 , 16F
檔案時會有ID不同的現象，導致使用者更新時，原本已有
02/12 02:30, 16F
→
02/12 02:31, 6年前 , 17F
物件因為ID變動而消失或是變成別的物件。
02/12 02:31, 17F
→
02/12 02:31, 6年前 , 18F
有些人建議，除非是指出一版永不更新了，否則ESP就好。
02/12 02:31, 18F
→
02/12 02:32, 6年前 , 19F
說這麼多其實也是多餘，畢竟蓋很多很多的狀況下，目前
02/12 02:32, 19F
→
02/12 02:33, 6年前 , 20F
即使最強的硬體可能還是撐不住...
02/12 02:33, 20F
→
02/12 12:25, 6年前 , 21F
個人認為esl最好避免的是新增FromID，或者盡量不更動已
02/12 12:25, 21F
→
02/12 12:26, 6年前 , 22F
新增ID的內容。定居地變更或修改原版內容會比較適合...
02/12 12:26, 22F
想了一下，CK轉換esl有兩個選項：緊密FromID和轉製格式。 一般來說我們在編輯模組時免不了增刪一些ID資料，這時可能會在兩筆ID之間產生空隙，這部份再重新進行緊密化時會造成ID的不同。 不過還好的是，緊密化ID並不與格式轉換綁定。如果確認該資料不會刪除的情況下持續進行緊密動作，可避免ID變更的問題。 但可以的話還是以少量資料才組建esl會比較好，畢竟這是創造esl這個格式的初衷… ※ 編輯: deepseas (39.8.32.56), 02/12/2018 14:07:24
→
02/12 19:53, 6年前 , 23F
BGS官方人員也是建議ESL是資料不多時比較好，一般mod
02/12 19:53, 23F
→
02/12 19:54, 6年前 , 24F
如果資料較多的話還是用ESP/fake ESM就好
02/12 19:54, 24F
→
02/12 19:55, 6年前 , 25F
或是資料持續修改增加的情況也不應該用ESL。
02/12 19:55, 25F
→
02/12 21:16, 6年前 , 26F
沒錯呢...我自己做的模組不能也不敢用...
02/12 21:16, 26F
→
02/12 21:19, 6年前 , 27F
另外個人推薦的esl用法是整合一些小設定，例如屍體碰撞
02/12 21:19, 27F
→
02/12 21:20, 6年前 , 28F
改遊戲設定值那種的其實倒是沒問題就是～
02/12 21:20, 28F
→
02/12 21:21, 6年前 , 29F
化、ragdoll、QA吸菸室預設天空、電線擺動或一些細微的
02/12 21:21, 29F
→
02/12 21:22, 6年前 , 30F
vanilla cell小修補等等...
02/12 21:22, 30F
→
02/12 21:25, 6年前 , 31F
patch原本vanilla的資料應該也很適合，除非要新增東西
02/12 21:25, 31F
→
02/12 21:25, 6年前 , 32F
那就要考慮一下緊密ID的問題。
02/12 21:25, 32F
‣ 更多 deepseas 的文章
文章代碼(AID): #1QViZNy4 (RealPlaying)
‣ 更多 deepseas 的文章
文章代碼(AID): #1QViZNy4 (RealPlaying)