Trainz/AM&C/修復資產

Trainz 資產維護與建立 Trainz 註釋參考頁面

TOC | 開始 | 樂趣 | AM&C | 建立 | 書中參考文獻 | ORP 參考文獻：  • 索引 • 容器 • 型別 • 標籤 | 附錄  • 版本

詞彙表

HKeys-CM

HKeys-DVR

HKeys-SUR

HKeys-WIN

滑鼠使用

符號

貢獻作者：The Yesterdayz-Trainz group

如果你開始將 Trainz 作為構建工具進行探索，製作或修改路線，或者大膽地進入 DLS 並獲取過去十年中上傳的 2500 多條路線之一，你將不可避免地面對“修復資產”的學習曲線。如果你要著手修復資產，你需要了解在哪裡查詢資訊。 資產層次結構 和 config.txt 檔案 資產修復是一個有點用詞不當的說法，除了極少數情況外，大多數廣泛使用的資產需要透過更新到新的技術級別來修復，因為它們相對於遊戲引擎資料需求的更新已經過時。 可悲的是，在可下載內容中確實存在一些錯誤，不僅來自 DLS，還來自其他信譽良好的第三方內容建立者，例如 TrainzProRoutes.com Mocrossing 包（zip 檔案）包，其修復將在即將釋出的教程中介紹。很多時候這些都是簡單的筆誤，有些是拼寫錯誤（並非所有貢獻者都以英語為母語，或將其作為第一語言），而 TS08 之前的錯誤檢查要寬鬆得多……導致 Trainz 崩潰，甚至更糟，藍色畫面宕機 錯誤。

最後，也是最不常見的，是缺少紋理錯誤，以及在檔名中使用非法字元（非 ANSI 字元編碼，主要來自非英語字母，如許多歐洲語言）的錯誤，這些字元在 Trainz 中是非法的。

• 這些錯誤通常可以透過提供缺少的紋理（使用 PEV 的網格檢視器檢視它們發生的位置並進行智慧替換）或透過紋理剝離網格 (IM 檔案) 使用 PEV 的 Images2TGA 在紋理剝離模式下進行修復。

如果你要對此頁面進行更改，請註冊為華夏公益教科書編輯，以便你可以被識別，並且可以聯絡你有關解決方案的任何問題。一些更改已被新增，這些更改可能會讓人皺眉，因為它們對於較新的版本來說不是最佳選擇。此類修復對於 TRS2004 — TRS2006 版本來說可能沒問題，但對於較新版本來說就不那麼理想了，對於 TRS 版本來說更是微不足道！

 

編輯注： 在下面，短語 在型別為 <容器名稱> 的容器中不允許 最常見 實際上是指 資產“KIND” 在相關 config.txt 檔案中的資料定義。下面的一些也適用於 容器 和/或子容器，但大多數看到的都是指 KIND。

少數“不良資產”可以（由於系統性清理 DLS 的努力，發生頻率不斷降低），並且當這些資產在路線中被發現時，它們的大部分問題也可以被修復。大多數可以被歸類為關鍵字的誤用，拼寫錯誤，缺少引號等等。任何人都可以透過文字編輯器（如 記事本 或 Notepad++）修復這些小問題。偶爾會缺少一個元件的資產，要麼是紋理，要麼是網格（由紋理“裝飾”的線框，以建立虛擬物件。一個是表面，另一個是底層形狀的骨架）。到目前為止，大多數這類資產已經被證明可以透過調整檔案路徑規範，在 config.txt 檔案中安裝新的容器樣式資料結構，或者調整檔案資料夾內容（例如，在 TS2009 及更高版本中放棄了處理）來輕鬆修復，方法是將相關檔案複製到必要的資料夾中。

已經採用了各種技術，需要不同的資料，或者需要改變資料組織方式。大多數這些更改在軟體中自動處理。如果它們無法處理，就會產生錯誤，這是件好事。在資產中出現錯誤比在資產中存在缺陷導致程式崩潰好得多——這在 TRS2006 的早期很常見，當時第一個提高基本錯誤測試水平的措施被整合到 CMP 軟體 中，以及它的 Service Pack 1。

T:ANE 中的 VE 訊息

隨著 T:ANE 的引入，內容管理器中錯誤和警告的報告方式發生了變化。每個錯誤和警告現在都有一個 VE 編號。完整的編號列表 在此。每個錯誤或警告也有自己的 WIKI 頁面，可以透過從該頁面選擇該專案來訪問，也可以透過右鍵單擊“錯誤和警告”視窗中的編號錯誤或警告訊息來訪問。這些頁面上的資訊特定於 T:ANE 版本。但是，以下資訊適用於大多數 T:ANE 報告的錯誤和警告。

獲取和安裝 PEV 工具

PEV 工具在高階使用者的 C:\Downloads 資料夾中（你的可能在其他地方）。

PEV 的工具將由社群在一個或另一個網站上維護，因為它們非常寶貴。Peter Villaume (PEV) 是一位非常有才華的程式設計師（工程師，實際上），他位於澳大利亞與 N3V & Auran Holding 在黃金海岸（布里斯班附近）的小鎮位置相對（或悉尼）的一邊，但在 2013 年中期停止在他自己的網站上託管他的工具，當時 Trainz 論壇大師 Shane Turner 在 他的幫助網站這裡接管了這項任務。

Shane Turner 還在 Auran 論壇上主持了許多問答帖子，並在本文和 N3V wiki 中做出了貢獻，此外，他還在自己的網站上製作了一個教程系列。隨著最初的 Trainz 老一輩逐漸淡出，像 Shane 這樣的新粉絲站了出來，重新煥發了 Trainz 互相幫助的社群精神。Shane 年輕、精力充沛、熱情，技術精湛，是一位非凡的 Trainz 老手，他的貢獻已經並且有望繼續長期造福我們所有人。訂閱和瀏覽他的帖子、網路論壇和新聞信，我相信任何新 Trainz 粉絲都會覺得值回票價。而且他每天都回答問題！讚賞，Shane。我們需要更多像你一樣的人。

1. 在 Shane 的網站上找到 PEV 工具及其附帶的 .pdf 檔案 手冊（如果有）。
2. 檢視 設定 PEV 工具，瞭解關於放置位置的步驟和提示。
3. 檢視 PEV 工具，瞭解一些操作技巧、教程連結以及本地安裝中的高階設定。那裡還會找到一些節省時間的有用技巧和竅門。
4. 雖然你是錯誤修復新手，但在你的 \UserData 或 \UserData\editing 資料夾中設定一個“editing2_unchanged”資料夾，並在嘗試任何更改之前定期將資產複製到該資料夾中。
   1. 這是一個安全網，以防事情似乎要爆炸……一種在單個錯誤變成令人警覺的 30 個錯誤列表時重新開始的方法……
   2. 或者更好的是，一種方法是讓你可以將原始副本和更改後的副本用於 Kdiff3 進行比較，並讓它顯示你在哪裡弄亂了巢狀的“}”或添加了額外的引號，或者犯了一些其他導致解析問題的錯誤。
       • (深吸一口氣，放鬆一下，那樣的錯誤列表並不真實，只是某個地方的標點符號需要修復。)

 

如果你剛開始使用 Trainz，下載站的吸引力可能會很迷人。 控制住你貪婪的一面，只下載少量內容，清除你所獲得的內容中的錯誤，然後繼續你的貪婪。過多的錯誤只會讓你和內容管理器感到困惑，所以為了你自己，要採取小步驟。 建議你最初只下載會話，這些會話具有路線作為依賴項。CM 將填充依賴項，一個單一的選擇可能會突然變成 800 多個資產！這對我們所有人都會發生！ 如果你想練習錯誤修復，選擇一些 V2.5-v2.8 版本的較舊路線，在那裡你會發現一些錯誤。然後回到更早期的 V2.0-v2.4 內容，然後是 V1.3-v1.5 內容。許多最近的路線和會話都包含較舊的內容，所以以這種方式回顧將讓你在可以控制的劑量下獲得所需的經驗，並且那些能夠進入較新路線的較舊資產是經受住了時間考驗的珍寶。（在較早期的 Trainz 中，有相當數量的“低於專業水平”資產，因為許多內容建立新手添加了一些最好不要共享的東西。我已經提醒過你了！

 

第二部分

1. 花一些時間潛伏在論壇上，觀察一下。使用谷歌的網站搜尋功能查詢有關你可能提出的任何主題或問題的條目。（site:forums.auran.com “問題文字關鍵詞”。）這個網站也同樣適用！
2. 在你學會處理 10-20 個錯誤並瞭解它們是多麼重複出現之後，在論壇上找到 Asset-X FAQ 並訂閱，並開始逐漸進行學習，同時定期、穩定地修復你遇到的任何其他故障資產。
   1. Asset-X 的大部分操作說明都包含在產品內建的 Windows 風格幫助檔案中。可以直接在資料夾中閱讀，也可以透過載入 Asset-X 並點選幫助來閱讀。
3. 在這樣做之前，你必須瞭解 基本的 Trainz 資料模型 配置，並且透過 PEV 工具和專注的大腦修復 20-30 個錯誤將讓你對 Trainz 演變資料模型的各種形式有足夠的瞭解，並且可能足以掌握它們之間的相互作用和差異，從而能夠使用 Asset-X 並能夠發現錯誤。
4. 另外，建立一個示例資源型別側邊資料夾並用需要編輯的內容副本填充它也是一個好主意，但修復了這些副本以便它們可以毫無警告地透過。這些可以與同類其他資源進行比較，避免你陷入困境。這項練習將為你打下良好的基礎知識，並增強信心，使未來的資源修補速度更快。最終，你將在建立對如何修復故障的良好基礎知識方面節省大量時間。

關於標籤中大小寫的說明

內容建立者為在 Trainz 配置檔案中使用而建立的標籤通常不受任何特定大小寫（大寫或小寫）規則的約束。一般標準是使用全小寫，但對於許多名稱，任何形式的大小寫都是允許的。在許多地方使用任意名稱，包括檔名（影像、網格等）、網格中使用的名稱（附件點、紋理）以及列表中使用的標籤（例如，附加軌道容器中的軌道列表）。

某些名稱或標籤有特定的大小寫要求，例如網格容器中預設網格的“default”。這些標籤應嚴格按照文件使用。在其他地方，需要特定的大小寫，例如在“string-table”容器中使用的標籤，這些標籤必須全部小寫。但許多其他標籤，尤其是檔名，完全由內容建立者決定。但很難判斷何時大小寫很重要，何時不重要。否則看起來很神秘的錯誤可能是由於大小寫不同的名稱不匹配造成的（尤其是在提交資源更改了某些標籤的大小寫時）。

一個好的規則是將所有內容都設為小寫 - 避免使用任何大寫字母。這與 Trainz 的一般標準一致，也減少了 Windows 資源管理器使用自己的規則調整檔名以供顯示而產生的問題。

如果你遇到 CM 說某些內容不存在或已經存在而你找不到錯誤原因的錯誤，請仔細檢查正在使用的大小寫 - 它可能是大小寫重要的那些情況之一。

注意：指令碼有自己的規則。特別地，物件和方法必須使用文件中記錄的確切大小寫，並且，根據上下文，大小寫不同的標籤是不同的標籤。

一對一替換列表

1. 發動機規格 <kuid:35837:51002> 可以替換為 <kuid:44090:51016>

內容管理器警告資訊

以及如何處理它們...

內容管理器在提交資源時會驗證資源，還包括一個選項來顯示任何已安裝資源的錯誤和警告。以下是 CM 在驗證資源時將顯示的一些錯誤訊息及其簡要說明。此列表基於 CM v3.7，但也包括一些僅由 N3V 上傳驗證過程生成的錯誤。

此列表中的符號 <text> 表示該文字根據資源的詳細資訊而有所不同。

警告：Trainz 目前無法驗證別名網格。

此資源中使用的一個或多個網格未包含在該資源中，但包含在從該資源引用的另一個資源中。這種引用被稱為別名，另一個資源被稱為別名資源。別名通常用於建立與現有資源僅在用於渲染模型的影像方面不同的新資源 - 這有時被稱為為資源重新貼皮。它被廣泛用於火車車廂，以及路標等資源，其中一個網格與許多不同的影像一起使用。它也用於透過以不同的方式組合幾個標準網格來建立資源，例如與接觸線。別名也被 Trainz UTC-TRS2004 時代的實用程式 Paintshed 使用。

對於 T:ANE 之前的版本，CM 在驗證此資源的過程中不會驗證別名資源，因此無法確認此資源沒有錯誤。即使此資源被列為可用，它也可能在遊戲中無法正常工作，因為包含所需網格的別名資源可能存在故障，或者該網格可能實際上並不存在於該資源中。在大多數情況下，資源是正常的：警告並不意味著使用資源會遇到問題。警告有時會被誤解為錯誤，因為它經常出現在看起來沒有錯誤但不會在遊戲中顯示的火車車廂中。

與網格相關的其他配置項，例如附件點，如果網格在別名資源中，也不會被驗證。

從構建號 2.9 開始，一種替代的別名形式可用。從該構建號開始，可以在網格表容器中使用“mesh-asset”標籤來引用另一個資源中的網格。在這種情況下，CM 也應該發出上述警告，但（對於 T:ANE 之前的版本）它並沒有發出。因此，使用“mesh-asset”標籤的資源可能在遊戲中無法正常工作，因為別名資源存在故障或丟失，但 CM 中沒有警告。

對於高於 3.8 的構建號，只支援“mesh-asset”型別的別名，而在 T:ANE CM 中，會驗證別名網格，因此不會出現此警告。

 

修復

1. 可以透過將網格表中的頂級“alias”標籤更改為“mesh-asset”標籤來抑制警告，注意使用相同的 kuid。但是，這並不會改變別名網格沒有被驗證的事實 - 它只是阻止警告出現。最好保持資源現狀，這樣警告就會出現。
2. 如果顯示此警告的資源未在遊戲中出現，則別名資源是首先要查詢問題的地方。

警告：缺少必需的標籤“<tag name>”並已將其設定為預設值。

應將該標籤新增到 config.txt 中，並使用適當的值。

來自故意濫用縮圖容器的示例

• 警告：缺少必需的標籤“height”並已將其設定為預設值。
• 警告：缺少必需的標籤“width”並已將其設定為預設值。

導致這些錯誤的原始碼行（測試是否可以將其“全部放在一行”）

thumbnails { A { image "$screenshot (256).jpg" } }（答案是“是”，但顯示的空格是必要的。）

在某些情況下，此警告實際上是一個錯誤，因為預設值對於該標籤無效。當這種情況發生時，會立即顯示一條錯誤訊息，指示該值無效。新增帶有正確值的標籤將消除警告和錯誤。

警告：此資源使用過時的 trainz 構建號。

警告：此資源使用過時的 trainz 構建號。低於 <build number> 的 trainz 構建號不再受支援

應用於資源的驗證測試取決於資源的構建號。此訊息表明資源被認為已過時，因此沒有應用最新標準。

此訊息是一個警告 - 資源仍然可以正常工作（除非存在錯誤）。可以透過更改構建號來消除警告，但這可能會在根據較新的構建標準驗證資源時建立新的錯誤。只有在準備進行更新資源到更高構建號所需的所有其他更改時，才應更改構建號以消除此錯誤。

警告：容器“<container name>”中的標籤“<tag name>”已過時。

該標籤不再受支援，將被忽略。該標籤可能在較低的構建號中相關，但在當前的構建號中不再適用。

標籤功能可能已被容器或其他標籤替換，例如 'category-era-nn' 標籤被更簡單的 字串陣列 標籤 'category-era' 替換，類似地，'category-region' 字串陣列 標籤替換了多個 'category-region-NN' 標籤。

檢視 容器規範 （在 N3V Wiki 中或此處）以確定標籤是否已被替換。如果有可用的替換，請選擇與廢棄項中值對應的標籤值。如果對應值不清楚，請接受預設值。在大多數情況下，標籤可以簡單地刪除。

警告：檔案 '<name>' 不存在

當容器中使用無效標籤時，可能會發生此錯誤，並且驗證系統假設標籤值必須引用檔案。例如，容器 'sound' 只能包含一個標籤 - 'soundfile' - 並且標籤的值必須是檔名。如果包含了不同的標籤，則驗證過程不會報告無效標籤錯誤，而是假設標籤值引用檔案，並建立此警告。解決方法是刪除標籤和值。

警告：必需的容器 'thumbnails' 丟失。

應將縮圖容器新增到 config.txt 中。

對於從 3.5 版本開始的 DLS 上傳，這是一個錯誤，上傳將被拒絕。請參閱錯誤列表中的對應專案。

警告：此資產需要陰影網格，但網格表中沒有。

應為資產建立陰影網格並更新網格表。

在 3.8 版及以上版本中不再需要陰影網格。但是，如果網格表中列出了陰影網格，則網格必須存在，並且缺少的網格將被報告為錯誤。將主網格指定為陰影網格是有效的。

警告：紋理 '<texture name>' 是統一顏色。

不應將統一紋理用於新資產，但對於需要更改網格的舊資產，應將紋理調整為 4x4，或至少將一個畫素更改為不同的顏色（即使差異很小）。大的統一紋理會浪費資源：不要調整影像顏色以避免警告，而無需將其調整為合適的較小尺寸 - 16x16 或更小。

據報道，如果影像小於 64x64，則不會生成此警告，但這在 61388 版本中似乎並非如此。單個畫素差異足以消除警告。

警告：必須為標籤 'texture-kuid' 指定一個資產。

texture-kuid 標籤被一些容器（例如，電暈效果容器）用於引用紋理名稱。如果使用它，則應指定紋理名稱。

此錯誤通常發生在紋理由指令碼程式碼控制的資產中。在這種情況下，可以為標籤指定任何紋理，因為指令碼將在執行後立即更新它。

警告：Trainz 不再支援漸進網格。

警告：Trainz 不再支援漸進網格。雖然這些網格可能在 Trainz 中起作用，但建議您切換到 LOD 網格。警告：Trainz 不再支援漸進網格。雖然這些網格可能在 Trainz 中起作用，但建議您切換到 IM 網格。（直到 2008 年釋出 TC3 引入了 LOD 技術。）

可以使用 PEVtools 實用程式 PM2IM.exe 將漸進網格 (.pm) 轉換為單個 索引網格 (.im)。

• 沒有可用的工具可以將漸進網格檔案轉換為多 LOD .lm 檔案 格式，該格式詳細說明了多個網格如何基於距離視點縮放成檢視。這種轉換將透過手動複製模型並簡化模型來建立多個版本來完成 - 通常是兩個到四個網格，其多邊形越來越少。對於修復的資產，無法進行此操作，因為沒有可用的網格原始模型。

警告：從 trainz-build 3.8 開始，索引網格不再支援火車車廂。

警告：從 trainz-build 3.8 開始，索引網格不再支援火車車廂。建議您將 <mesh-name.im> 升級到 LOD 網格。

對於構建級別為 3.8 或更高的 火車車廂，網格必須設定為 LOD 網格，否則將不被接受上傳。LOD 網格在 Trainz TRS2004（於 2003 年首次釋出）中引入，由多個索引網格組成，這些網格在物體檢視距離增加時使用更少的多邊形。這有助於減輕主 CPU 的處理負載，並將負載轉移到 GPU (GPU) 上。此要求不適用於構建級別較低的 火車車廂，但對於構建級別為 2.9 及以上的任何資產，它都是一項推薦的升級。

如果資產是構建級別為 3.8（Trainz MAC-II 和 TANE）或更高的火車車廂，並且沒有 LOD 網格，則此警告將成為錯誤。

警告：<value> 不是標籤 '<tag-name>' 的有效值。此標籤現在為空，必須選擇新的值。

示例

"警告：'US ' 不是標籤 'category-region' 的有效值。此標籤現在為空，必須選擇新的值。"

仔細注意確切的訊息警告：'US '和 刪除標籤值末尾的空格。這個額外的空格在一些編輯器中不可見，它解釋了一些本來很神秘的錯誤。

• 注意：任何字串值欄位中的尾隨空格在 Trainz 中是非法的，並且通常會顯示上面的訊息。

警告：容器 '<container name>' 中的布林標籤 '<tag name>' 不是有效的布林值。

標籤被定義為需要布林值，但提供了一些其他值。布林值表示 '0'（false）或 '1'（true）。使用任何其他整數值會導致此錯誤訊息。在一些較舊的資產中，已觀察到 2 到 7 的整數值。可以合理地假設除 0 以外的任何值都表示 'true'。

修復 將標籤的值更改為 0 或 1，具體取決於資產。

• 請注意，在某些情況下，此訊息實際上表明標籤的定義錯誤 - 內容建立者已遵循正確的規則，但驗證使用的是不同的規則。一個例子是在 Trainz 的某些版本中的不透明度標籤。在這種情況下，正確的型別是“值”（從 0.0 到 1.0 的浮點數），而不是“布林值”。要消除錯誤，可以在 安裝根目錄\bin\TETData 資料夾中的 container.txt 檔案中重新定義“不透明度”標籤的型別。仔細檢查該檔案的內容應該表明所需的更改，即使內容乍看之下沒有多大意義。

 

內容管理器錯誤訊息

使用 OR 的 KUID 列表檢視已修復的資產，這是一種強大的技術，可以修改您的搜尋並精確顯示您想要的內容 - 一些故障在資產重新提交之前不會顯示為已修復，或者突然您會發現已修復的資產具有元件資產存在問題，如本檢視中探索這種情況。 放大時，請檢視此影像上的描述。 點選此處的影像始終可以提供更大的檢視。

獲取資產意味著在舊內容中經歷一系列錯誤，這些錯誤通常可以透過一系列簡單的編輯更改和 PEVtools 來修復。這是一份指南，教你如何做到這一點，以及為什麼會出現這種或那種錯誤。 AssetX 和 TARDIS 指令碼可用於自動修復其中許多錯誤。

請參閱 設定 PEVtools，瞭解一些有用的技巧和方法。

 

錯誤：此資產的 Trainz 版本號未被此工具識別。

該資產的 Trainz 版本號標籤 (TB、TBV) 值 對於您的 Content Manager 版本來說過高。

• 如果您收到此訊息，則可能意味著您擁有 Trainz 的多個許可副本，因為如果沒有同時擁有舊版本和新版本，這種情況不應該發生，並且您將無權訪問高於與零售版本相關的最高 TBV 的內容。

編輯說明： 雖然 DLS 到 CM 的介面在 2015 年期間進行了部分大修，但從舊 CM 的角度來看，在 TANE 處理伺服器資料流的方式（尤其是在使用者擁有多個活動 CM 或版本時）中引入了一些錯誤（從舊 CM 的角度來看）。因此，作為經常執行多個 CM 的人，我也經常看到此錯誤。有時這是因為我從一個 Trainz 跨載入到另一個 Trainz，而 cdp 比我複製到的 Trainz 更先進。 -Fabartus

幾乎所有具有更高 TBV 的內容都可以透過將版本號降低以匹配您的版本來使用，除非使用了僅在更高版本中可用的功能（包括一些指令碼功能）。對於我們這些執行多個 Trainz 版本的人來說，此訊息變得越來越常見，因為 DLS 軟體並不總是正確（並且可能根本沒有在 TS09、TS10 和 TS12 中檢查 TBV - 這些版本都獲得了幾個更高的三和一小部分 V4.0+ TBV 作為升級下載。 DLS 絕對變得更加積極地將最新版本轉發到請求資產的 CM。即使 CMP 也下載了 V3.7 資產，而我沒有期望如此慷慨。）在解釋下載到哪個版本時，尤其是在執行多個 CM 時進行交叉下載時。

當此類更新的資產或版本使用舊 Trainz 資料模型中找不到的標籤或容器時，需要進一步調整以刪除不支援的標籤。

此類錯誤將由 CM 明確標記，通常包含多行錯誤，提及多個紋理和 texture.txt 檔案。在許多情況下，修復方法是刪除有問題的行，依靠預設值來使用。當使用 樣條線物件（長資產）將版本號降低到低於 2.9 時，此過程會變得更加困難，因為許多標籤在該版本中發生了更改。對於物件（型別風景 和相關型別）而言，在沒有紋理問題的情況下，將 Trainz 版本值回滾到高於 v1.5 的任何值通常都很容易，因為用於這些物件和大多數 型別火車車廂 資料結構的資料模型在 TBV 1.5 和 v2.0（分別為 UTC 和 TR04）中變得穩定。

編輯說明： 僅更改 Trainz 版本程式碼值就可以顯著地改變看到的錯誤列表！例如，請參閱 第三部分（下文）。

• 在許多情況下，降低版本號也會影響 texture.txt 檔案，需要從這些檔案中刪除不支援的標籤。

原因
發生這種情況是因為 PEV 的 Images2TGA 是在假設內容建立者或 Trainzer 正在嘗試“升級資產”的情況下編寫的。預期設計是，一個人正在嘗試將資產轉換為更高的 TBV。

• 由於 TRS 時代的 CMP 在遇到已編譯的 紋理檔案（例如，檔名類似於feature.texture 的 Trainz 壓縮資料形式）時會報錯，因此 Images2TGA 必須執行以提取可編輯的 texture.txt 檔案 及其相關各種圖形資料檔案（例如 BMP、TGA、JPG 等）以供舊的 Trainz 版本使用。

TANE 僅以 .texture 檔案形式開啟要編輯的檔案；因此，Images2TGA 是 PEV 自 2014 年底 TANE-CE 過早釋出以來工具的第一次也是唯一的一次更新。如果要進行更改（例如修復），則只需獲取檔案的可編輯版本。

• 將資產向後移植到 TRS 時最常見的問題是 Images2TGA 輸出的 texture.txt 檔案中的AlphaHint= 'something' 行。
  ‌ 修復方法很簡單，只需註釋掉 AlphaHint= 'something' 行即可，方法是將該行變為註釋字首：在該行的開頭新增 '// '（一個所謂的 Hack-hack 註釋行分隔符），該行中之後的所有內容都會被忽略在許多軟體檔案中，包括 texture.txt 檔案。
   • 它曾經在 Trainz 的 config.txt 檔案中也能使用，但程式設計師在 TS09 中變得懶惰，配置中的註釋不再存在。
   • 這可能會影響單個資產中的數十個 texture.txt 檔案。例如，考慮一個“numberit”指令碼化的機車 - 每位數字 0-9 都有四個 TGA 紋理，其中四分之一（或者可能是一半）會有 AlphaHint 標籤！

• 但不要絕望，有一個簡單的答案，那就是使用一個好的程式設計師文字編輯器，例如 Notepad++，它可以讓你搜索給定指定資料夾中的所有檔案並立即進行更改... 僅開啟一個檔案！（感覺像作弊，但你可以在幾秒鐘內改變數百個開啟用於編輯的資產！降低 TBV 是最常見的操作。）

• 通常，最簡單的“修復”方法是刪除資產並使用早期版本，如果可用，該版本具有合適的版本號。有些人認為，2015 年 8 月實施的 DLS 下載程式變更使得下載資產的特定版本變得更加容易，並且不太可能下載版本不合適的資產。對於 TANE 使用者來說，這確實是事實，但此更改對舊 CM 的影響是，DLS 有時會提供比請求或需要的版本更高階的 kuid/cdp，因此我們看到了更多導致開啟本節主題的錯誤。（'錯誤：此資產的 Trainz 版本號未被此工具識別。'）
• 此外，這些自動 DLS 控制不適用於第三方網站，也不適用於從 DLS 網頁手動透過 FTP 下載資產，因此在使用這些網站時，可能需要格外注意以確保只下載了合適的版本並將其整合到您的安裝中。

錯誤：標籤 '<text>' 不允許在型別為 <container-name> 的容器中使用。

部分 - 哦，簡介

哎，羅馬人從未有過零！

正如它仍然會困擾並困擾著最憤世嫉俗且經驗豐富的資產修復者... 真的，真的，非常有可能的第一個原因，是缺少分隔符。

• 用簡單的英語來說，您是否在某個地方缺少'"' 或 '}' 字元？

提示：搜尋錯誤訊息中名為“第一個標籤”的標籤（通常會有很長的列表……可能檔案中某部分的每個單詞都會出現），然後檢視它上面是否有缺少的東西！ 有時候它只是一個額外的字元，一個多餘的雙引號（或花括號）都是常見的罪魁禍首，或者一個“結束符”（分隔符）完全缺失。 這些是巢狀錯誤，每個程式設計師在歷史上的任何一天都會犯很多這樣的錯誤……至少持續幾分鐘……沒有理由內容創作者應該比這更好！

資產 config.txt 和 texture.txt 檔案也是程式碼，並且語法不僅需要精確，而且需要強制執行。 我們稱它們為錯誤。 事實上，它們幾乎總是人為錯誤。 使用像 Notepad++ 這樣的優秀的程式設計師編輯器，您可以在引號之間來回切換（F3 和 SHFT+F3，單手即可完成向下搜尋或向上搜尋！)，以及突出顯示配對括號、方括號和圓括號的功能，可以真正加快此類錯誤的查詢速度。

現實世界的例子：（這些都是在我忘記新增的 縮圖容器 的內部“}”時看到的！）

1. 錯誤：標籤“author”在“thumbnails”型別的容器內不允許使用。
2. 錯誤：標籤“organisation”在“thumbnails”型別的容器內不允許使用。
3. 錯誤：標籤“contact-email”在“thumbnails”型別的容器內不允許使用。
4. 錯誤：標籤“contact-website”在“thumbnails”型別的容器內不允許使用。
5. 錯誤：標籤“license”在“thumbnails”型別的容器內不允許使用。

第一部分

如果標點符號和語法問題沒有導致 CM 在嘗試理解這些不平衡的分隔符時出現數據配對異常，那麼這些錯誤通常是由以前有用但現在是非法標籤引起的，這些標籤包含在其他地方定義的值，或者作為要解釋為文件或資訊的行……以前合法的註釋（見下文），現在應該刪除或放入描述容器中。 或者，如果它們是帶引號的字串，則可以將它們保留為帶引號的字串對，但移動到 字串表容器 中。 有時候情況正好相反，一個“未來標籤”被帶回 Trainz 的早期版本，其 Trainz-build（技術級別！）值低於來源。 第三種情況與第二種情況相反，但只是因為在每種情況下，某些東西都處於不合適的時間和地點（以及 TBV 級別）。 也就是說，如果高階資料標籤被帶入早期技術級別的錯誤檢查，則可能會出現相同的引號。 容易看到。 將 Trainz-build 標籤值降低至少 0.5，然後觀察錯誤訊息的變化。 如果您必須編輯內建資產，經常看到的一件事是，它們在生產期間被存檔，並全域性更改了 TBV，因此在開啟標籤多年後，它們會突然顯示為非法。 有趣！哈哈！ 將 TBV 降低到 2.3--2.5，並確保它具有 mesh_table 和縮圖容器，大多數較舊的資產可以正常轉換，直到 TANE 的 V4.2 更新。

瞭解 Trainz 資料應該始終被視為標籤（關鍵字）和配對值（資料）。 即使是 Trainz 的 容器資料型別 也是如此，因此外部大括號定義了值的邊界，可以這麼說。 同樣，當被視為值的陣列時，儲存在像 類別-時代、類別-關鍵字 和 類別-地區 這樣的字串中的值，即使對我們人類來說是多個值的物體，也可以被解釋為單個配對值……只是軟體期望包含多個子值的那些值，可以這麼說。 最後，這一切都取決於計算機如何解包和利用資料。 配對術語，即使是具有明確列舉關鍵字的複合術語，也不可能與其他事物混淆，這是一種構建收集的組織資料的非常安全的方式，這些資料必須作為一輛以每小時 70 英里的速度在城市後街行駛的火車迅速執行和解釋！

“看似相反地”，將資產降級到早期 Trainz-build 標籤值會直接更改錯誤檢查，因此也可能會給出這樣的訊息。 當然，您實際上可能是將資產帶到 Trainz 的早期版本（我們中有些人這樣做），這將大大提高您看到此類訊息中引用的“新標籤或容器名稱”的機率。 以下兩個錯誤是透過將“新模型” 軌道資產從原始的 V3.5 或 V3.6 降級到 TBV 2.9 時單獨生成的。

• 錯誤：標籤“follows-spline-gradient”在“track”型別的容器內不允許使用。
• 錯誤：標籤“attached-splines”在“track”型別的容器內不允許使用。 事實上，附加樣條線容器 是一個聚合值“子型別”或修飾符，它將建模軟體擴充套件到另一個子例程以解釋其值。 它非常類似於 kind SceneryWithTrack 的 軌道容器（“附加軌道容器”），它包含允許兩種“kind”混合特徵的指令，使工業、平交道和碼頭等資產能夠實現其功能。

• 容器中可能出現在此類錯誤訊息中的所有標籤都是

• lateral-offset、use-same-direction、spline-kuid <...>、visual-only、follows-spline-gradient、start-gap 和 end gap}，除了引用的 KUID 之外，它們都是布林值引數，預設值為 0（False）。

  這些錯誤訊息的底線是軟體功能和 Trainz-build 級別可能不同步。 TBV 值標識了某些功能何時被新增到 kind 和容器的調色盤中。 在早期版本中引用此類標籤將導致此類訊息。  

以下實際錯誤訊息：通常會“作為一組”重複出現，一大堆使用別名標籤 來引用外部網格的 Paintshed 標記重新塗裝汽車。

• 此組源於直到 TS09 版本及其更嚴格的錯誤測試 之前盛行的鬆散資料定義和處理。 在那之前，任何以字母 字元 開頭的行開頭標記（可能合法地評估為可能的關鍵字）（例如 height-below、width-of-interior 等）都可以與帶引號的字串配對，如果標記不是關鍵字，則會被忽略。 此外，如果行以標點符號（“;”和“/”很常見）開頭，則該行到行尾程式碼會被視為單個值，在這兩種情況下，Trainz 也會忽略該行。 關鍵字“REM”來自 BASIC 語言，雖然從未正式使用，但被廣泛用於對整個帶引號的文字段落進行字首。 因此，直到 TS09 之前，CC（作者）才能夠嵌入自己的備選值以供測試，或者允許使用者使用相同的網格將配置檔案定製為完全不同的外觀，或者在應用資產時嵌入指令，如果使用指令碼，幾乎總是需要類似的內容。
• “(容器型別“traincar”)”訊息可能會或可能不會出現，具體取決於解析配置檔案並驗證內容錯誤的 Content Manager 版本。 這些示例故障訊息來自TS2009-SP2 的 CM-2.0 驗證測試。

 

1. 錯誤：標籤“capacity:”在此容器內不允許使用。(容器型別“traincar”)
2. 錯誤：標籤“height:”在此容器內不允許使用。(容器型別“traincar”)
3. 錯誤：標籤“length:”在此容器內不允許使用。(容器型別“traincar”)
4. 錯誤：標籤“weight:”在此容器內不允許使用。(容器型別“traincar”)
5. 錯誤：標籤“wheelbase:”在此容器內不允許使用。(容器型別“traincar”)
6. 錯誤：標籤“width:”在此容器內不允許使用。(容器型別“traincar”)

一般修復方法是確定問題的開始，搜尋（SAR 或 FIND，通常在大多數編輯器中為 **CTRL+F，向下重複搜尋使用 **F3）雙引號（ " )，並用單引號、空格或空替換。當最後一個錯誤訊息行被傳遞後，選擇並拖動以使用 **CTRL-X 突出顯示所有內容，目的是將現在已去除的線條移至 **description** 容器中。將移動的剪下緩衝區（行）貼上到描述的雙引號內，進行復制編輯，儲存並重新測試。

使用 **string-table 容器** 的另一種修復方法保留了傳統方法的歷史記錄，前提是 Trainz 版本高於 V2.3 —這隻需將所有有問題的過時標籤一起重新定位到後續行上，新增標籤 string-table 以及它的花括號“{”和“}”。這之所以有效是因為 string-table 是每個有效 **Kinds** 中的合法容器。

編輯者注：  

• 在驗證錯誤時留在配置檔案內是一個好習慣！

1. 使用 **CTRL+S（在大多數編輯器中）儲存更改，然後 **ALT+Tab ↹ 或 **⇧ Shift+ALT+Tab ↹ 將內容管理器視窗恢復為焦點應用程式。

• 注意：這對從 TR06 的 **CMP** 到 TS10/TS2009-SP3 的 **CM 2.0** 開始的所有 CM 版本都不適用。使用這些舊的 CM，您必須將資產提交到資料庫中（**CTRL+M ) 重新測試它（**validate**）並生成新的錯誤訊息（故障）列表 — 希望沒有！ 從 V3.2（TS10-SP2）及更高版本釋出的軟體版本，包括 TS09 和 TS10 的 SP4（都是 TBV 3.3）將表現並解析錯誤，而檔案仍處於開啟編輯狀態，正如我們推薦的更高效的方式，使用可靠的 **ALT-Tab ↹ 在 **活動視窗** 之間切換。

1. RMBh+drag 以 **檢視錯誤和警告** 並重新測試資產。

• 通常，在修復了某些其他故障（通常是路徑修復）後，會顯示其他故障。
• 注意：路徑修復是針對舊（v2.6 之前）資產最常見的修復需求，因為在 trainz 版本 v2.9 之前，所有版本都可以基於 **asset-filename** 標籤的分配值，以及 '_art'、'_body' 和 '_shadow' 等字尾，正確地在原始資料模型資料夾中找到資產元件。N3V 的程式設計師從 v2.9（**TS2009-SP0**）及更高版本開始刪除了使這些可預測連結自動生成的程式碼片段 — 強制在即使是簡單的資產中也使用 顯式路徑 和容器。最常見的需要是 **thumbnails**、**mesh-table** 和 **bogeys container**；建立了許多計算機處理程式程式碼建立的故障，以及其他可預防的故障生成訊息。
• 強烈建議，如果您要修復需要新增這些容器的故障，還應將trainz-build提升至v2.6並消除該TBv下的所有警告。此類修復在TS12中始終有效。

第二部分

這條神秘的資訊，常見於老舊內容，並非因為'?'（?，搜尋'?' 不會找到！），而是因為GMAX或其他早於TRS2004（此類內容不會出現此問題）的實用工具建立頁面時遺留的“下劃線”（___）。

“錯誤：'0' 中的標籤 'image' 必須具有影像副檔名。”另一個易於修復的錯誤。上面的截圖中出現了兩次，但也說明了佔位符引數（虛擬標籤或虛擬關鍵字可以是任何東西）。
嘗試記住這一點，當你開始建立自己的資源時。並非所有名稱都相同，除非它們是佔位符。

案例 I

• '錯誤：標籤 '?' 不允許出現在型別為 'engine' 的容器內。'
• '錯誤：標籤 '?' 不允許出現在型別為 'bogey' 的容器內。'

 

這條神秘的資訊，常見於老舊內容，並非因為'?'（?，搜尋'?' 在 config.txt 檔案中不會找到任何內容！）而是因為gmax遺留的字元，通常出現在配置的第二行——不可列印字元（在大多數文字編輯器中用下劃線（___）表示），由對檔案的先前處理插入，作者保留（並被 Trainz 的早期版本忽略）。

修復：參考右側影像的文字：這很可能是第二行上的兩個不可列印字元，應將其刪除。

案例 II：例如，它可能是一個簡單的拼寫錯誤

• '錯誤：標籤 'discription' 不允許出現在型別為... 的容器內'

因此，將拼寫更正為 'description'。

資源定義不是程式設計，但它們是程式碼，並且與預期不符的拼寫或其他偏差可能會產生錯誤資訊，例如本例中所述。

 

案例 III，不再在規範中的標籤

• '錯誤：標籤 'origin' 不允許出現在此容器內。'

說明

此標籤在較舊的版本中是正確的，但在當前版本中不允許。

修復：刪除該行。（請查閱《維基百科》中記錄的已棄用配置標籤列表此處。這些是最常見的情況（風景和路邊物體發生了很多變化：其他容器、KIND 和子容器自 V2.8 以來（Trainz Classics 3）以來資料模型變化較少）。

第 III 部分

這種情況與上述情況相反：新標籤在舊版本中找不到！

此錯誤是不同版本 Trainz 釋出的驗證規則不一致的結果。

例如

錯誤：標籤 'engine-sound-ramp-up-durations' 不允許出現在型別為 'enginesound' 的容器內。

錯誤：標籤 'engine-sound-ramp-down-durations' 不允許出現在型別為 'enginesound' 的容器內。

這些錯誤資訊在匯入 TS09、TS10 和 TS12 中都會出現。 解決此問題的關鍵是仔細閱讀，並檢視參考頁面的歷史記錄。

• 這兩個都是新標籤和引數，以前由一種通用的預設實現來滿足，但“使用者 Auran”（一個 Trainz ID 為“-25”，其粗心大意對 N3V 的 TS09-TS12 版本進行了許多導致資產出現問題的升級。）沒有更新trainz-build（讓 TB 預設值為 v1.3！），同時將不合適的關鍵字（標籤）新增到 TS09-TS12 版本中內建功能中缺少的資產中。
• 因此，由於沒有 trainz-build 標籤，每個版本中都會出現此錯誤。

解決方案

• TS12 的配置透過新增 trainz-build 3.6 得以修復。
• TS09 和 TS10 的配置透過新增 trainz-build 2.3，並將兩行標籤（包含逗號分隔的浮點數的陣列引數）移到描述資料中……實際上是刪除了這兩行。

 

第 IV 部分

子容器標識不正確。

某些子容器需要型別標識，而型別指示哪些標籤有效。一個例子是網格表中的 Effects 子容器。Effects 子容器的型別由 'kind' 標籤定義，可以是 'animation'、'attachment'、'corona'、'name' 或 'texture-replacement'。如果使用了錯誤的型別，或者子容器中缺少 'kind' 標籤，那麼原本在子容器中有效的標籤可能會被標記為“不允許”。此錯誤通常會在子容器中建立一系列額外的錯誤資訊。修復方法是確保已指定正確的型別，並且子容器中使用的標籤適用於該型別。

另一個類似的例子是煙霧容器——煙霧容器的型別由 'mode' 標籤的值定義，而該標籤值決定了哪些其他標籤是必需的，或者哪些標籤對該容器有效。

錯誤：'<子容器名稱>' 中的標籤 'image' 必須具有影像副檔名。

真實示例

錯誤：'1' 中的標籤 'image' 必須具有影像副檔名。

錯誤：'c' 中的標籤 'image' 必須具有影像副檔名。

• 對於某些容器，影像標籤必須具有可以解析為影像檔案的值，而無需使用 texture.txt 檔案提供引用。預期的影像檔案可能是紋理檔案，也可能是具有 bmp、tga 或 jpg 副檔名的影像檔案。如果它是紋理檔案，則應將紋理轉換為影像並更新標籤。

此錯誤可能是由簡單的拼寫錯誤或缺少檔名造成的。或者，該值可能是在 texture.txt 檔案中引用而不是影像檔案本身（無論是否需要影像，還是 texture.txt 檔案是否可接受，取決於標籤出現的容器）。

BAD     image   "filepathspec\filename.texture.txt"
OK      image   "filepathspec\filename.texture"
GOOD    image   "filepathspec\filename.tga"

請注意，此錯誤可能會與其他錯誤一起出現，這些錯誤與無法找到或載入影像檔案有關。

錯誤：由於檔案訪問錯誤，無法提交對資源 <kuid 值> 的更改

錯誤

由於檔案訪問錯誤，無法提交對資源 <kuid:-25:6> 的更改

出現此錯誤的最可能原因是 Trainz 正在執行，並且正在編輯的資源在路線中“正在使用”。路線中使用的大多數資源在路線載入時載入一次。這些資源可以在遊戲執行時編輯。但某些資源，例如某些指令碼資源、聲音和區域，會從資料庫中重複訪問。這些資源在遊戲中路線“正在使用”時無法編輯。關閉 Trainz 並重復儲存。

此錯誤也可能是由機器速度較慢或記憶體不足，以及大型下載造成的。曾經有一次，這種情況出現了六次，計算機是一臺 10 年前的雙核筆記型電腦，六條訊息顯示了要編輯的開放資源。在 CM 主檢視中檢視下載列表後，每個資源都成功驗證並手動提交。

解決方案

關閉其他應用程式或停止任何 CPU 或記憶體密集型活動，然後重試。如果問題發生在多個資源上並且無法清除，則資料庫可能已損壞。

 

錯誤：檔名“<filename>”包含非法字元

• 示例：錯誤：檔名“$hirsch-tga_converted (512^2).jpg”包含非法字元

解決方案

透過編輯引用和檔名來刪除有問題的“^”字元——此字元在檔名中不允許。請注意，即使檔名對您的作業系統有效，也可能被 Trainz 標記為無效——這是因為 Trainz 被設計為在多個平臺上執行。

錯誤：容器“<kind>”中的標籤“<tag-name>”已過時。

這三個錯誤經常一起出現

這些訊息是在資源升級到 V2.9 及更高版本（TS09 Trainz 及其後續版本）後出現的.

• 錯誤：容器“scenery”中的標籤“region”已過時。
• 錯誤：容器“scenery”中的標籤“type”已過時。
• 錯誤：容器“scenery”中的標籤“asset-filename”已過時。

如果 trainz-build 標籤 小於 V2.9，則這三個已棄用標籤將顯示警告資訊。可以透過從 config.txt 中刪除標籤來使資源符合規範。

錯誤：無法提交“<'asset_username'>”。資源未開啟以供編輯。您可能需要先將其開啟以供編輯

當 CM 對正在編輯或未編輯的內容感到困惑時，可能會出現一條罕見的訊息。可能是由於打開了 CM 的多個副本，或手動移動了編輯資料夾或子資料夾造成的。

錯誤：無法讀取位於“<location>”的資源的配置檔案

[[Trainz/Unable to read config file for asset at <location>|無法讀取位於“<location>”的資源的配置檔案]]

無法找到或讀取 config.txt 檔案。

1. 這可能表明資源已損壞，或不存在於預期位置。如果資源被刪除，但快取未更新，則可能會發生這種情況。應從備份源還原資源，或將其還原。

2. 此錯誤可能是由於配置檔案中缺少關鍵資訊造成的。例如，如果未找到“kuid”標籤，則會報告此錯誤訊息，即使實際錯誤應該是“配置檔案無效”。請檢查是否包含所有必需的標籤，並確保拼寫正確。

錯誤：此資源的 Trainz 版本號未被此工具識別

資源的版本或“版本號”作為必需的條目包含在每個 Trainz 專案中，作為資源 config.txt 檔案 中的 trainz-build 標籤。

編輯說明：沒有 trainz-build 程式碼值的資源預設為 v1.3，這是最後一個沒有版本號的 Trainz 版本。認為 Trainz UTC 是完成原始 Trainz 1.0 版本 設計目標的第四個 Service Pack 也是很有道理的，因為從 v1.3 到 v1.5 的最大變化是 UTC 添加了第一個 ContentManager.exe（分配了 v1.4，但與 CMP 和 CM 非常不同，這些模組取代了這些獨立的模組）以及添加了內容，以及包含在 UTC 中的出色價值 *.doc MS Word（文字處理器）檔案。遊戲中的 GUI 更改和新增，如 TRS04—TRS06 之間的更改，非常小。

一個有趣的事實是，每個 Trainz 版本都包含 Trainz 資料模型 的重大更改，大約需要 4 個 Service Pack 才能將其設定為穩定版本。UTC 作為第四個，TRS2004 的 SP4，TS09 和 TS10 的 SP4（聯合開發）。TANE 使用 64 位計算機體系結構，並且沒有來自 N3V Games 的高階資料模型資訊——可能會以相同的方式進行。

原因

當您匯入的資源的 trainz-build 標籤的值高於 Trainz 版本支援的版本號（支援的資料模型或技術級別）時，會發生此錯誤。

作為必填資料欄位，trainz-build 號碼向遊戲定義了建立資源的技術標準。它還定義了 Content Manager 在對本地資料庫進行驗證和新增操作時驗證資源的標準。這使遊戲能夠根據適當的技術標準驗證資源，並在需要時插入預設值或忽略功能。它是保持 Trainz 版本之間相容性的秘密，也是（例如）Trainz 1.3 資源仍然可以在新路線和會話內容中使用的理由。

通常，可以透過調整版本號來降級資源使其在更早版本的 Trainz 中使用，但存在限制。指令碼是版本之間變化很大的一個方面，如果版本號降低，可能會導致問題。因此，將資源從（例如）3.3 降級到 2.9 可能需要刪除或停用指令碼。此外，構建級別之間的技術標準之間存在一些不一致。例如，版本 3.5 允許在 Soundscript 容器中使用單個值來表示 Distance 標籤（如同 2.9 之前的標準），但版本 3.3 要求包含兩個值。這些更改通常很容易在資源中進行調整。

網格、紋理、kuid 引用和其他類似的資源基本元素通常可以在 2.9 及其之後的所有版本中正常工作。對於 2.9 之前的版本，所需調整將更加廣泛。

關鍵點：因此，當生成此訊息時，CM 表示它不知道如何驗證資源的元件，它不知道標準。

• 只有現在由 kind 軌道、地圖和會話資源建模的基於樣條線的資源，以及那些包含需要在先前版本中不存在的指令碼功能的指令碼要求的資源，會阻止將資源降級到 N3V 時代資料模型（TS09 及更高版本）。大多數資源可以透過簡單地將 trainz-build 更改為 CM 或更早版本的版本號，以及可能補償（TS09—TS12 到 TRS 的需要刪除紋理檔案行，以便他們可以使用預設模式，因為 TS09 及更高版本允許在他們的改進的圖形處理過程中對這些模式進行更精細的控制。）texture.txt 檔案 中任何次要命令更改來正常工作。

錯誤：位置資料無效。LoadE2MeshObject> <mesh 檔名>：塊：n 無效

網格可能存在技術錯誤。 或者，TANE 在匯入 cdp 檔案時可能存在問題。

• 從技術上講，它應該意味著：... 一個或多個頂點座標不是數字，或者距離模型原點超過 5 公里。

• 當出現真實錯誤時，無法在沒有訪問網格原始檔的情況下修復此問題，您必須聯絡資產的作者。 問題必須反饋給內容創作者。
• 塊號提供了一個指示，表明錯誤發生在網格的哪個部分。

• 此錯誤在 TANE 中的一些使用大型網格的資產中出現，即使網格本身有效。 TANE 無法處理在 TS12 中可接受的網格大小。

• 通常，使用 PEVtool images2TGA.bat 在 TS09–TS12 中開啟資產進行編輯，並將網格從舊的 Trainz '..\editing\assetname' 子資料夾複製到 TANE 的編輯資料夾，可以有效地解決 TANE 錯誤地給出此錯誤訊息的問題。

錯誤：無法載入網格檔案：'<網格檔名>'

無法載入網格檔案。 可能在 config.txt 中拼寫錯誤，可能丟失，可能格式錯誤，或者可能已損壞且無法讀取。

通常相關聯的是，較新的 Trainz 版本可能會報告找不到 anim 檔案。 對於那些嵌入軌道且被建立為 kind mocrossing 的資產，這經常發生，例如一些碼頭資產或帶有附帶軌道的早期非工業車站。 在這種情況下，包含任何 anim.kin 檔案將抑制錯誤，而不會影響資產。

 

修復這些問題的步驟

1. 執行 PM2IM 並檢視是否生成了一個 IM 檔案，或者 Pevs Tool 生成了類似的錯誤。
   ‌ 這可以透過 Trainz 內容管理器中的 RMBh 選單啟動使用開啟 PM2IM，或者透過在 \editing 資料夾中安裝 PM2IM.BAT 的副本並將其拖放到 bat 檔案上完成。
   1. 如果是後者，請在論壇上尋求建議和幫助。
   2. 如果是前者，請手動編輯網格路徑以使其正確，如下所示。
2. 首先，確保您也檢查並更新副檔名到 .IM！
3. 如果生成了具有相同名稱的 IM 檔案，請檢查資產的 網格表容器 中的資料夾/路徑規格條目，並驗證 PATH（許多舊的資產都有一個“asset-name” + '_body' 子資料夾，它是直到 TRS2006 中期版本才使用的約定，因此很可能出現在任何 v1.3-v2.4 資產中）和 檔名規格（包括副檔名）是否正確。
   1. 在這些舊的資產中，如果路徑規格正確，則很可能沒有安裝網格表。 新增一個（至少在 v2.0 之後）將被所有 Trainz 接受（毫不奇怪，因為它是由 TRS2004 引入的標準），並且通常被 N3V 的 TS09-TS12 版本中的較差解析所要求。
   2. 大多數將位於一個子資料夾中，以 '_body' 結尾。
      ‌ 有用的省時小技巧：當您在 ..\editing\asset-folder 中時，單擊 子資料夾，然後使用鍵盤序列F2+CTRL-A+CTRL-C，(然後 ESC) 來捕獲子資料夾名稱的精確語法(並且不要更改任何內容)。
   3. 然後將它貼上到 網格表 路徑的前端："subfolder-name_captured\mesh_filename.IM"。
   4. 示例網格表樣板（調整 路徑規格 和 檔名 以匹配您的資料夾內容）

mesh-table {
  default {
    mesh               "traincar-body.im"
    auto-create        1
  }
  shadow {
    mesh               "shadow.im"
  }
}
Alternatively,
  default {
    mesh               "Subfoldername_body\traincar-body.im"
...

新的 Trainzer 注意！ 請注意，在具有 asset-filename 標籤的舊資產中，編輯資料夾和'Subfoldername_suffix's' 由標籤確定，該標籤通常是小寫，並且通常包含下劃線而不是空格。

 

錯誤：在 'container-name' 中未找到附件點 'numeric_name'。

示例

錯誤：在 'queues\passengers_off_0\attachment-points' 中未找到附件點 18 (a.passoff)。 錯誤：在 'queues\passengers_on_1\attachment-points' 中未找到附件點 61 (a.passoff112)。

此錯誤可能有多種原因

1. 附件點名稱錯誤，因此網格和列出資料點的容器不匹配。
2. 附件點名稱後面包含一個或多個額外的尾隨空格。
3. 缺少附件點，因此網格和列出資料點的容器再次不匹配。

對“數字名稱”的解釋：網格中列出的第十九個附件點，名為“18”，佇列容器 在子容器 passengers_off_0 中丟失。（“18”是 佔位符引數 引用 - 一個用作名稱或標籤的數字……可以重新命名為 'xyz', 'glops' 或者任何沒有空格的名稱，只要它出現在容器（資料表）的第 19 行上即可。）

按照慣例，Trainz 中的子元素通常使用數字佔位符命名，但在大多數情況下，任何可以解釋為字串的條目都可以使用。
 • 作為佔位符引數，數字被解釋為字串，沒有權重或值，就像標籤名稱一樣。
 • 重要的是在{...} 對中存在某些內容，其內部行也期望關鍵字（或佔位符）與值配對，正如 Trainz 中普遍存在的做法。
 • 請考慮 配對的 { ... } 大括號 的內容與前面的 種類 或 容器名稱 配對。

錯誤：在 'container-name' 中未找到附件點 'numeric_name'。
 • 這些是人為錯誤（透過在容器中新增 3 行假資料），在修復第一個錯誤訊息之後。
 • 兩個例項都給出相同的錯誤訊息語法……一個缺少正確的名稱，另一個缺少附件點。

有三種可能的常見修復方法……

1. 可以使用 PEVsoft 工具 Attachment Maker 向平臺新增一個名為“a.passoff_##'”的附件點，如果它確實丟失了。（這在較舊的“乘客產品”資產中是一個相當普遍的情況。）
2. 但是，根據名稱“a.passoff”，這一行可能缺少數字字尾 - 沒有人會浪費時間給火車站上的通用附件點（可能有數百個）一個花哨的名稱 -這些通常以數字字尾命名；因此，該訊息可能是因為容器名稱缺少其數字字尾而發出的，並且由於佔位符序列是
   00  → a.passoff01,
   01  → a.passoff02,
   02  → a.passoff03, ...因此，在條目##-1   → a.passoff##X，新增正確的字尾“##+1'”，
   因此，在給定的示例中，將 19 新增到 #18 佔位符的行應該可以解決問題。
3. 如果重新命名失敗，則可以刪除該行。如果是這樣，產品 佇列容器 中的“大小”標籤數字應該遞減，以正確初始化陣列的大小並節省執行時記憶體。

人員，即乘客，是 Trainz 處理乘客行業相關資產（如客車和車站站臺）的方式。

錯誤：附件點“<attachment point name>”在“<effect name>”中必須在網格“<mesh name>”中找到。

在 config.txt 中引用了附件點，但它在預設網格 <mesh name> 中不存在。這通常發生在從其他資產複製 config.txt 時，並且從網格中刪除了附件。例如，一個道口閘門從網格中刪除了燈附件，但燈的電暈效果仍然引用了丟失的附件點。

示例（以及相關的伴隨錯誤）

錯誤：附件點“a.lite121”在“133”中必須在網格中找到 ''.

錯誤：附件點“a.lite121”必須屬於效果的父網格（網格=malt.IM）。

該錯誤也可能由於附件點的命名錯誤（有時由於名稱末尾有空格）而發生。

效果容器通常是一系列類似的專案，這些專案構成模型並需要某種形式的單獨處理。例如，建築物中的“背光”窗戶、火車車輛上的燈、站臺上的乘客以及“樹組”中的樹。這些效果需要父網格上的附件點，以便在模型中定位效果。

解決方案：如果問題是打字錯誤，則更正效果容器中附件點的命名。如果找不到正確的附件點，或者效果不再與資產相關，則刪除容器。

注意如下記錄的“修復” kind "scenery" category-class "BC" description "Large Grain Conglomerate, so I have built it in sections for easier placement. located in Vancouver, by the BNSF yard. Rev-A by Fabartus -- 2014-0508 Repaired these 'lights' faults by removing the #133 container to below: Error: Attachment point 'a.lite121' in '133' must be found in mesh ''. Error: The attachment point 'a.lite121' must belong to the parent mesh of the effect (mesh=malt.IM). Removed/Deleted lines: 133 { kind 'corona' att 'a.lite121' texture-kuid <kuid:-3:10111> object-size 0.21 } "

錯誤：附件點“<attachment point name>”必須屬於效果 <mesh name> 的父網格。

這通常與之前的訊息一起發生。不僅在網格中找不到附件點，而且在效果附加到的父網格中也找不到它。它發生的原因與前一條訊息相同。

錯誤：容器“<container-name>”沒有“att-parent”標籤，該標籤是引用附件點所必需的。

容器（子容器）將在網格表中。該訊息表明容器缺少所需的 att-parent 標籤，以指示容器中引用的網格附加到的父網格。當父網格是別名時，就會發生這種情況——在這種情況下，CM 需要明確指定父網格。

解決方案

• 檢視別名網格的 config.txt 檔案，以確定網格之間的關係，並將“att-parent”標籤和父網格名稱新增到網格容器中。

錯誤：紋理檔案 <filename.texture.txt> 包含非 ANSI 字元。紋理必須是 ANSI。

示例： 錯誤：紋理檔案“engine_black.texture.txt”包含非 ANSI 字元。紋理必須是 ANSI。

紋理名稱應該只包含 ANSI 字元。此規則在過去並沒有嚴格執行，因此，從 DLS 下載的一些資產的紋理檔名中可能包含非 ANSI 字元。如果隨後編輯資產，這些字元會導致問題。非 ANSI 字元的示例包括 À 或 è。檔名也可能包含不可見的非顯示字元。

1. 使用 AssetX 檢查網格中的紋理名稱。確保紋理檔名與網格中的紋理名稱完全匹配。

2. 如果網格中的紋理名稱包含非 ANSI 字元，則需要使用二進位制檔案編輯器編輯網格，例如將 è 更改為 e。然後調整紋理檔名以匹配。通常，需要在 texture.txt 檔案內容和影像檔名中進行相同的更改。

錯誤：紋理資源“<texture name>”缺少 *.texture.txt 檔案。

網格檔案中使用的紋理名稱找不到，或者無法載入。應該建立具有適當關聯影像檔案的有效 texture.txt 檔案。可以在使用者資料資料夾中搜索相同名稱的紋理，該紋理可能適合或可能不適合資產。也可以建立新的 texture.txt 檔案和任意影像——這可能揭示影像需要是什麼，或者可能揭示紋理無關緊要，任何影像都可以用來消除錯誤。

如果缺少的檔案是“digit_xx.texture”，則可以使用任何影像來消除錯誤。這些檔案實際上沒有使用，因為它們被替換為執行編號建立的一部分中選定的數字影像。

請注意，如果網格使用包含非 ANSI 字元的紋理名稱，則可能會發生此錯誤。在這種情況下，texture.txt 檔案（及其關聯的影像檔案）可能在匯入過程的某個階段由於檔名無效而被刪除。在這種情況下，需要編輯網格中的紋理名稱以刪除非 ANSI 字元，然後替換 texture.txt 檔案（以及影像檔案）。

錯誤：紋理“<image filename>”載入失敗

示例：錯誤：紋理“column1.bmp”載入失敗。

載入名為影像檔案的影像時失敗。該檔案可能已損壞，在這種情況下，必須將其替換為有效的影像檔案。它可能不在正確的格式中。例如，它可能是壓縮的 TGA：將其載入到您喜歡的影像編輯程式中並另存為未壓縮的 TGA。它的大小可能不正確——網格中使用的影像必須具有高度和寬度，這些高度和寬度是 2 的冪（即 2ⁿ，其中 n 是整數）畫素。如果影像用作主影像檔案和 alpha 通道檔案，則它必須具有 alpha 通道：將其載入到您喜歡的影像編輯程式中並另存為 32 位/畫素的未壓縮 TGA。

（如果 MS Paint 或其他圖形應用程式可以載入檔案，則大小是最可能的原因。調整影像大小，使寬度和高度都是 2 的冪（例如，8x8、16x16、32x128、256x64）。）

錯誤：無法為紋理檔案“filespec.texture.txt”載入 alpha“texture filename”。

形式

錯誤：無法為紋理檔案“subfoldername/alphamaskfile.texture.txt”載入 alpha 紋理“subfoldername/alphamaskfile.bmp”。

示例

錯誤：無法為紋理檔案“night/white-licht1.texture.txt”載入 alpha 紋理“night/licht1.bmp”。

錯誤：無法為紋理檔案“night/white-lichta.texture.txt”載入 alpha 紋理“night/lichta.bmp”。

最初的早期 Trainz 資產不需要今天資產的嚴格定義，並且可能沒有使用超過一個 AlphaMask 來模擬三種不同的 .tga 檔案作為光源。 例如，PEVTools 可能已按新標準正確建立了 texture.txt 檔案，而一個更簡單、更簡單的解決方法是將三個檔案都使用同一個 .bmp 檔案，只需更改新生成的 texture.txt 檔案條目。 （不過，那樣“修復”就失去了實驗的樂趣！使用 3 個檔案可以增強自定義能力！-編者） 重要的是要了解，在 V2.7 之前，TRS2004 和 TRS2005 沒有明確的允許行來更改 AlphaMask 模式。所有內容都是預設模式。這些行是後來新增的，以擴充套件功能，因此這對訊息提供了一些關於該時代資料演變的見解。 TRS2004 及更早版本的資產可能甚至沒有使用 texture.txt 檔案，而是基於帶有後綴的舊資料夾組織方式。（推測，編者）Ø

1. 上述錯誤訊息對出現在 v1.3 庭院塔式泛光燈資產中，其中僅使用三個灰度.bmp 檔案中的一個來改變塔上每盞燈的亮度和特性，使它們具有個性和獨特性。在庭院泛光燈資產中的其他聚光燈旁邊，三個不同的陰影蒙版將逼真地複製原型中各個燈光燈的實際屬性。
2. 當圖形檔案完全丟失時，通常的解決方法是用能夠完成工作的檔案替換該檔案。
   1. 在上述情況下，只有三個 AlphaMask 中的一個存在，因此對其進行了複製，並進行了修改以複製所需的個性並滿足“texture.txt”包含檔案。（參見上圖和右圖）
3. 這種型別的其他故障通常是因為早期的 Trainz 會完全讀取資料夾內容，並無差別地索引每個檔案並將其放入記憶體塊中 - 這使得能夠在資產資料夾層次結構中的任何位置引用 .bmp 或其他支援檔案（包括資產根目錄以上的那些檔案）。
   1. 但較舊的方法有時會冒著建立微妙問題的風險，如果內容項使用相同的檔名但資料不同。
   2. 較新的 Trainz 不會以相同的方式查詢內容，它們依賴於指定的路徑規範，並且 texture.txt 檔案用於確保明確指定了正確的路徑規範 / 檔名規範。當子資料夾或資產根目錄資料夾中存在filename.texture.txt檔案中指定的檔案時，就會產生這種副作用...... 在 Trainz 1.3 - TRS2006 中很容易找到的檔案突然斷開路徑規範，從而破壞了資產。

錯誤：在驗證網格“<網格檔名>”時，無法為紋理“<紋理檔名>”載入影像檔案“<影像檔名>”。

請注意，此錯誤和以下錯誤（無法載入主紋理）通常一起出現。

texture.txt 檔案中引用的影像無法載入。它可能丟失，texture.txt 檔案中名稱可能拼寫錯誤，影像檔案格式可能錯誤（例如，壓縮的 TGA），影像大小可能不是 2 的冪（在需要的地方），或者影像檔案可能已損壞。 

編者注： 還有可能影像檔案實際上並沒有丟失，但 texture.txt 檔案存在，並且不需要。也就是說，它是一個額外的 texture.txt 和/或紋理。在 DLS 上散佈著一些在 TS2009 版本之後報告了此故障的資產。 解決方案 在一個視窗中使用 PEV 的網格檢視器，以顯示紋理模式，並與..\editing\資產資料夾或子資料夾中的資料夾內容（按名稱排序）進行比較。如果錯誤訊息中的紋理名稱不在網格或子資料夾中，那就是問題所在。它不需要。 作為檢查，將副檔名更改為somename.texture.org.txt，這樣它就會被忽略並且合法。 重新驗證，如果故障訊息消失，則可以刪除該檔案。 高階替代方案：使用AssetX[1]檢查網格中所需的紋理列表 - 如果網格中未列出紋理名稱，則可以刪除 texture.txt 檔案，錯誤將消失。

  示例：錯誤：無法為紋理“shadow”載入影像檔案“shadow.bmp”，同時驗證網格“shadow.im”。

• 解決方案：陰影網格不需要任何影像檔案。但是，許多陰影網格是用預設影像（通常為黑色）建立的，在某些情況下可能用多個影像建立。使用 PEV 的 QuickShadows 工具從現有的陰影網格重新建立陰影網格，並刪除原始陰影網格使用的影像（texture.txt 和影像檔案）（在確認其他網格不需要這些影像之後）。使用 QuickShadows 工具建立的網格不需要任何影像。

對於不是陰影的網格，請參見以下內容。

錯誤：無法為紋理檔案“<紋理檔名>”載入主紋理“<影像檔名>”。

請注意，此錯誤和前面的錯誤（無法載入影像檔案）通常（如果不是總是的話）會同時出現......

texture.txt 檔案中引用的主影像無法載入。它可能丟失，texture.txt 檔案中名稱可能拼寫錯誤，影像檔案格式可能錯誤（例如，壓縮的 TGA），或者影像檔案可能已損壞。

示例-1：錯誤：無法為紋理檔案“shadow.texture.txt”載入主紋理“shadow.bmp”。

• 解決方案：使用了在修復資產時構建的資料夾紋理庫中存檔的 shadow.bmp。
• 替代方法：可以使用 black.tga，或者建立一個新的 4x4、8x8 或 16x16 的深色 tga 檔案作為此陰影。

  示例-2：錯誤：無法為紋理檔案“greyhound_stop_1_nightwindows/bussstatin1.texture.txt”載入主紋理“greyhound_stop_1_nightwindows/bussstatin1.tga”。

• 解決方案：關鍵在於關注關鍵字“主紋理”（“/bussstatin1.tga”），但... 該檔案位於資產資料夾的根目錄中，需要將其複製到下方，而夜間模式 texture.txt 檔案位於“..\greyhound_stop_1_nightwindows”資料夾中，位於根目錄下方。它帶有一個“greyhound_stop_1_nightwindows.tga”和“greyhound_stop_1_nightwindows.bmp”，實際上是用於照明窗戶和標誌的 AlphaMask 影像。

  示例-3：錯誤：紋理“billboardnight/white flat.texture”丟失或無法為網格“billboardnight\billboardnight.im”載入。

• 在這種情況下，DLS v2.4 廣告牌資產 (<kuid:262137:10118>) 的故障在於完全有效的TGA 檔案具有“開啟”的RLE 壓縮（在許多圖形應用程式中單擊框選項）。TS09 及更高版本無法容忍預壓縮的 TGA 檔案（Trainz 自此會對其自己的壓縮排行壓縮，PEV 的 Images2TGA 會提取這些壓縮檔案）。

• 解決方案：使用免費軟體GIMP或其他影像處理圖形編輯器，這些編輯器可以控制 RLE 壓縮，並使用“另存為”模式覆蓋資產。

（如有疑問，請另存為其他名稱（新增字尾“-B”等），然後修改 texture.txt 檔案以儲存原始檔案。

或者，在 Windows 中複製該檔案，然後調整它 - 這樣可以跳過對 texture.txt 檔案的更改。

請注意，一旦可接受，N3V 的 Trainz（v2.7 及更高版本）釋出（至少從 TS09 及更高版本開始）很可能會將額外的 texture.tga 標記為新的、不同的錯誤... 這可以透過更改後的訊息讓您知道您現在可以刪除安全檔案。

編者注： 新使用者可能不知道您可以大膽一點......CTRL+R(或透過選單下拉)將恢復一個失敗的修復，使其就像從未進行過一樣，包括關閉編輯資料夾和刪除失敗的修復內容。因此，雖然像上面那樣儲存檔案是一個好習慣，並且可以將控制權掌握在您手中，但搞砸了並不是世界末日。

錯誤：影像檔案 '<image filename>' 被錯誤地用作 texture.txt 原始檔和原始影像檔案。

該資產包含一個texture.txt 檔案，該檔案引用了一個影像檔案，但該影像檔案是直接從 config.txt 中的標籤引用的。

• 這通常適用於kind groundtexture 資產，其中紋理也被用作縮圖。縮圖引用指向影像檔案，但紋理標籤引用 texture.txt 檔案。
• 此故障報告還出現在“normal-texture 標籤”已新增到配置中，並且影像檔案已直接從標籤引用，而不是透過 texture.txt 檔案。
• 當使用 texture.txt 和影像檔案組合時，也會出現此問題，而只允許使用影像檔案，例如產品中的“icon-texture”標籤。

除縮圖和某些特定標籤外，所有對影像檔案的引用都應透過 texture.txt 檔案。由於多個標籤可以引用同一個 texture.txt 檔案，因此最簡單的修復方法是將標籤值從影像檔案更改為 texture.txt 檔案。對於縮圖，引用可以是直接的，而不是透過 texture.txt 檔案，前提是縮圖影像不用於任何其他目的。如果問題是使用了不允許的 texture.txt 檔案，請將標籤引用更改為影像檔案並刪除 texture.txt 檔案。

注意：許多內建資產在資產詳細資訊窗格中不會顯示縮圖影像。這是因為資產使用對 JPG 影像的直接引用作為縮圖。從 JA 檔案獲取的資產將缺少未從 texture.txt 檔案引用的影像，因為這些影像未包含在 JA 中。這對使用者來說並不重要，因為使用者無法建立 JA 檔案。

關於如何使用 texture.txt 和影像檔案的詳細討論，請參見此處引用的腳註。

錯誤：紋理資源“<texture filename>”的二進位制轉換失敗。

由於某種原因，無法處理 texture.txt 檔案中引用的影像。請參見前面。

錯誤：'texture.txt 檔案' 的主紋理和 alpha 紋理大小不一致。

當使用除 TGA（如 BMP）以外的影像格式並需要透明度時，則必須提供兩個影像——不透明影像和透明度蒙版。這兩個影像在 texture.txt 檔案中被稱為主影像和 Alpha 影像。在這種情況下，這兩個影像必須具有相同的大小。

如果出現以下情況，將報告錯誤：

• 使用了兩個單獨的影像，並且影像的大小不一致。
• 需要兩個單獨的影像，但只能載入一個影像。

可以透過以下方法解決問題：

• 1- 如果提供了兩個單獨的影像，但大小不一致，請調整其中一個或兩個影像的大小，使其大小一致。

  編輯者注： 免費軟體 IrfanView 和 Paint.net 都可以輕鬆地調整大小，GIMP 稍微複雜一些。大多數圖形軟體應用程式都具有調整影像大小的功能。

• 2- 如果提供了兩個單獨的影像，則此錯誤也可能是由 32 位 TGA 或 32 位 BMP 引起的。當提供兩個單獨的影像時，它們應為 24 位格式。
• 3- 如果需要透明度影像（例如，如果 texture.txt 檔案包含標籤“AlphaHint=masked”），則還必須指定“Alpha”檔案。這可以是單獨的檔案，但最簡單的配置是透過將檔案格式從 24 位更改為 32 位，向現有 TGA 檔案新增一個 alpha 通道。然後，TGA 檔名列在 texture.txt 檔案的“Primary”和“Alpha”標籤中。

錯誤以及說明無法載入紋理檔案的故障訊息也可能在紋理檔案壓縮時出現。這在使用 GIMP 時經常發生，在“另存為”模式對話方塊的選項選單中隱藏了將檔案儲存為壓縮/未壓縮、24 位/32 位的選項。對於 Paint.Net 使用者，這些選項顯示為“另存為”對話方塊頁面的部分。（對於 Irfanview，TGA 檔案沒有選項頁面——預設格式為 32 位未壓縮）。

選項 1 對於修復某些資產可能更簡單，但 32 位 TGA 檔案是迄今為止更好的選擇。

示例問題和解決方案

示例情況 1

錯誤顯示為出現在 art 子資料夾中

錯誤：無法為紋理檔案“gondola4axlebn521555ant_art/gondola4axlebn521555ant_art_512.texture.txt”載入 alpha 紋理“gondola4axlebn521555ant_art/gondola4axlebn521555ant_512.tga”。

錯誤：'gondola4axlebn521555ant_art/gondola4axlebn521555ant_art_512.texture.txt' 的主紋理和 alpha 紋理大小不一致。

資產的 texture.txt 檔案為

Primary=Gondola4axleBN521555ant_art_512.tga
Alpha  =Gondola4axleBN521555ant_512.tga
Tile=st
Hint=Dynamic

這是一個簡單的檔案輸入錯誤。將其更改為

Primary=Gondola4axleBN521555ant_art_512.tga
Alpha  =Gondola4axleBN521555ant_art_512.tga
Tile=st

(提示不是必需的。更改行的順序無關緊要，但可以更輕鬆地檢查輸入）。錯誤實際上是由於無法找到 alpha（透明度蒙版）檔案。

注意：修復“無法載入……”錯誤也刪除了“……大小不一致”錯誤。

編輯者注：修復火車車資產的 art 資料夾中的問題或警告是一個簡單的過程，有助於確保該資產在 Trainz 的後續版本中保持有效。

• 512x512 art 檔案不再使用，因此可以刪除 texture.txt 檔案和影像檔案，並刪除匹配的縮略圖表條目。
• 可以透過引用控制texture.txt 檔案來使用 512x512 影像作為 240x180 縮圖，但仍應在縮圖容器標籤中分別指定高度和寬度為 180 和 240。但是，這將建立一個失真的影像。首選方法是在影像編輯器中編輯 512x512 影像，並將其另存為正確大小的 JPG。
• 128x64 圖示 art 檔案仍在列表中使用（例如，火車場中火車車的列表或測量員的“火車車”標籤列表）。它是可選的，另一個類似大小的影像將被縮放以適合，但結果通常不可接受。該影像應該是側面檢視，透視最小，背景透明，火車車位於影像的上半部分。
• 對於 512x512 影像（如果使用）和 128x64 影像，應使用 texture.txt 檔案（但請注意，AssetX 不會這樣做——必須手動編輯 config.txt）。縮略圖表條目應僅針對 DLS 縮圖（240x180）直接引用影像檔案，正如 N3V Games 版本經理 James Moody 在 2014 年 9 月強烈建議的那樣。在腳註中詳細引用的電子郵件中，J. Moody 強烈建議使用 texture.txt 檔案 為所有影像格式檔案，包括 *.jpg 240x180 縮圖截圖。James Moody 不再為 N3V 工作。

示例情況 2

錯誤：'kansascitysouthernsd40-2_body/reflectstrip1f-window-dark.texture.txt' 的主紋理和 alpha 紋理大小不一致。

在這種情況下，使用 AssetX（或任何影像編輯程式，如 Irfanview 或 GIMP）中的影像調整大小選項調整影像大小（以畫素為單位），使其在高度和寬度上匹配，並且每個維度都是 2 的整數次方（4、8、16、32 等）。

錯誤：找不到資產 <asset kuid> 的縮圖影像。

• 1- 縮圖容器丟失或為空。新增一個帶有合適縮圖的容器。
• 2- 影像檔案位於子資料夾中，且資料夾路徑格式錯誤。對於在縮圖容器中引用的影像，路徑名必須使用“/”作為分隔符，而不是更常見的“\”。例如

   image "Litchfield & Madison CT100_art/preview.jpg"

錯誤: 找不到執行編號字型目錄'_alpha_numbers'。

• 1- 該車廂不支援執行編號，但 'fonts' 標籤的值大於零。刪除 'fonts' 標籤，或將 'fonts' 標籤的值設定為零。
• 2- 該車廂支援字型，但 'fontspath' 標籤丟失或為空。建立 'fontspath' 標籤並插入正確的值。正確的值是字型所在的資料夾名稱，直到但不包括文字“_alpha_numbers”。例如，如果字型位於資料夾“sd40-2_alpha_numbers”中，則 'fontspath' 標籤的值為“sd40-2”。

編輯說明: 請注意，這種部分路徑規範非常不典型，大多數路徑規範需要在 Trainz 的 config.txt 上下文或 texture.txt 檔案中完全指定。

錯誤: 標籤 '<tag name>' 不允許在型別為 '<kind>' 的容器中使用。

示例
‌"錯誤: 標籤 'thumbnail' 不允許在型別為 'scenery' 的容器中使用。"

該標籤不被識別為此型別容器的有效標籤，即kind scenery。

1. 該標籤可能是一個註釋：早期的 CM 版本忽略了註釋（註釋可以用多種方式表達，最早的 Trainz 版本只是簡單地忽略了無效關鍵字，使許多結構實際上成為了註釋。如果它只是一個註釋，那麼它可以被刪除。
    • 指令碼使用的標籤通常利用了The TRS's 時代的版本簡單地忽略了無效標籤的事實——這本應一直延續下去，因為它只佔用計算機眨眼的功夫，卻給數千使用者帶來了巨大的時間壓力，而這些使用者被程式設計師的命令“修復損壞的資產”搞得焦頭爛額！——這就是為什麼這頁頁面變得必要！
    • 例如，一些指令碼使用的標籤，用於提供執行編號範圍（起始和結束合法值），通常被包含在配置檔案中的頂層標籤中。這些“自定義標籤”不再允許作為頂層標籤——它們必須移動到“extensions”容器中，並且指令碼程式碼必須修改為在配置檔案中找到它們的新的位置。或者，可以從配置檔案中刪除這些值，並將其硬編碼到指令碼檔案中——具體細節取決於指令碼。
2. 它可能拼寫錯誤，在這種情況下可以將其更改為正確的拼寫。
3. 它可能是一個對於不同構建號的容器有意義且有用的標籤，但對於資產的當前構建號無效。

具有以下確切示例中所示錯誤的資產可能已經被更新了——因此，與任何需要修復的資產一樣，請檢查 DLS，看看是否有更新的版本，其中包含可以下載的修復程式。

  版本衝突示例

1. 錯誤: 標籤'engine-sound-ramp-down-durations' 不允許在型別為 'enginesound' 的容器中使用。
2. 錯誤: 標籤'engine-sound-ramp-down-durations' 不允許在型別為 'enginesound' 的容器中使用。

在這種情況下，... 這兩個錯誤代表了內容創作者對 Trainz 0.9 的良好意圖——TC3 被程式設計師在 TS09 和 TS10 中安裝的故障測試所破壞... 也就是說，在上述兩個錯誤中，這兩個使用連字元的計算機術語原本是 Trainz 中的關鍵字，然後在 Trainz 2.9 版本的開發或除錯過程中被新增，而這些關鍵字對於解決 Trainz 的幾個聲音處理問題的預期解決方案來說並不必要，然後在 Trainz 3.4 版本中被重新強制要求，並且一直延續到現在的版本！

• 請注意，上面顯示的這兩個錯誤代表了當將有效的舊版 TBV 引擎規格匯入或下載到 TS09-TS10 中，或將更新的引擎資產的配置檔案中報告的 TBV（TB v3.4-v3.6 或更高）“回溯”時出現的錯誤訊息型別

解決方案: - 不要刪除這些行，只需將它們移動到描述欄位中，以記錄在以後的 TBV 版本中對它們的需要，並作為對自己的提醒——許多帶有這些錯誤的資產將在TB 版本高於 v3.4中給出相反的“缺少必需值”錯誤，在這些版本中，N3V 的程式設計師開始將越來越多的資料元素設為強制要求，因為他們對 Trainz 資料模型和程式碼系統進行了大規模的修改，以適配Trainz Mac 和Trainz Mac2 的釋出。也可能透過將構建號更改為支援該標籤的版本來消除錯誤。但是，由於這將增加或減少 TB 值，它可能會引入其他需要修復的錯誤或警告，儘管在這種情況下，這不太可能，因為kind engine 是一種非常穩定的資料型別。這個錯誤是程式設計師典型的傲慢。

這個克隆的kind map 資產，缺少原始資產的 HTML 檔案。

錯誤: '<asset kind>' 中標籤 '<tag name>' 的選擇缺失或無效。

標籤的值與該標籤的允許值之一不匹配。例如

錯誤: 'traincar' 中標籤 'nightmode' 的選擇缺失或無效。

對於這種情況，標籤 'nightmode' 的允許值為 "home"、"lamp"、"constant" 或 "none"。許多其他標籤也有類似的允許值列表。如果標籤值不是允許值之一，則會報告此錯誤。

錯誤: '<container name>' 中標籤 'tag name' 指向一個不存在的檔案: '<filename>'.

當標籤引用一個檔案而該檔案無法找到時，就會出現此錯誤。

例如，縮圖容器中的命名子容器有一個 'image' 標籤，它可以指向一個 texture.txt 檔案或一個影像檔案。如果影像檔案未找到——可能是名稱拼寫錯誤，或者檔案丟失——就會記錄此訊息。類似地，'maps' 容器中的 'info-page' 應該指向一個.htm 檔案。如果檔案未找到，則會記錄此錯誤。

錯誤: 標籤 '<tag name>' 的值數量不正確，預期為 <x> 個值，但找到 <y> 個。

當標籤需要一個值列表時，該列表中可能存在所需的最小或最大條目數。如果未提供正確的條目數，則會記錄此錯誤。

這些故障訊息是交叉載入（將..\local 資料夾的內容匯入到更新版本中的 CM）舊內容到TS2009 和TS2010 中，特別是對於第二個值，它通常是可選的且容易預設，並且在早期版本的 Trainz 中，以及在 Trainz 社群強烈要求之後，N3V 在TS2012 中將其恢復了——儘管 N3V Wiki 在 TB 3.4 版本之後提到了它們是必需的。既然如此，修復它們的微不足道的努力意味著它們很可能在匯入到更高版本的 Trainz 中時不會出現問題。

• 一般方法: 根據需要新增或刪除標籤列表中的條目，首先諮詢 N3V Wiki 以獲取缺少的值的引用。請注意，容器（快速類別連結）也可以是 KIND（快速類別連結）。

錯誤: 標籤 'repeat-delay' 的值數量不正確，預期為 2 個值，但找到 1 個。

案例一——sound-script 容器中的 repeat-delay 標籤配對值

在較舊的音效資源中很常見（kind scenery 或雜項），因為早期的 Trainz 版本被程式設計得足夠智慧，可以預設第二個值。

實際示例——具有三種不同音效的資源

Slugsmasher's trainz-build V2-4 —SS Log Dump Diesel, <kuid2:86661:144048:2>,升級到 V3-7 時，從 V2-9-SP2（TS2009-SP2 訊息）出現錯誤。值得注意的是，TS12 沒有報告相同的錯誤，在匯入到 V3.1 之前，給出了 0 個錯誤和 0 個警告，儘管 N3V Wiki 文件說該標籤在 TB V3-4 以上是強制性的。

錯誤：標籤“repeat-delay”的值數量不正確，預期為 2 個值，但找到 1 個。

錯誤：標籤“repeat-delay”的值數量不正確，預期為 2 個值，但找到 1 個。

錯誤：標籤“repeat-delay”的值數量不正確，預期為 2 個值，但找到 1 個。

• 修復：諮詢 repeat-delay 容器——配對值是一個範圍，如果不同，則該差異是新增到第一個值中的隨機值的範圍，然後在聲音再次重複之前。預設值為 1,1。第三個容器是引擎，因此將值設定為 0,0。其他日誌轉儲為 2,3（因此操作員操作的隨機值為 1 秒）和“logdrop” 2,2（恆定延遲，它們只下降這麼遠），取原始的錯誤單值，並相應地進行調整。

錯誤：標籤“trackoffsets”的值數量不正確，預期為 2 個值，但找到 1 個。

案例二——亂七八糟（一團糟）

錯誤：標籤“trackoffsets”的值數量不正確，預期為 2 個值，但找到 1 個。

類別類別“TB”（截至TS2009）控制圖形渲染以及CM 驗證用於軌道樣條線。（這種對驗證和渲染的影響是在所有Trainz 資料模型的歷史中，一個怪事，關鍵字（標籤）值——歷史上一直專門用於 CM 中進行排序——主要用於在不影響軟體的情況下傳達人與人之間的分類資訊，現在用於定義 kind track的許多樣條線子型別。）但是，TS2009 和 TS2010 的驗證存在不一致，無論軌道的數量如何，它只允許偏移和方向有 2 個值。TS12 要求兩個列表中的專案數量正確。

橋樑資源類別類別“TB”需要 trackoffsets 標籤，它指定軌道距樣條線中心線的距離。標籤值是一個CSL 列表，其中包含以米為單位的十進位制數字，但所有橋樑型別（道路，單軌橋，或雙軌，甚至隧道，每個在 TS2009 之前都有唯一的 KIND 宣告）在 TS09 和 TS10 中都有一個編碼錯誤，將所有橋樑解釋為 CM 驗證過程中的雙軌，並且始終需要至少兩個值。這伴隨樣條線中的類似更改，將它們定義為 Track KIND 子型別，以及所有軌道 Track 資源。

• 根據讀取配置檔案的 ContentManager 版本，更新出現此錯誤訊息的舊資源的正確方法會有所不同。Content Manager 2.0 到 Content Manager 3.3 會錯誤地給出此錯誤，以下是如何調整它。將資源移動到 TS12（TB V3.4 及更高版本）時，需要重新調整此類更正。
• 理論
   • 如果要更正錯誤，在軌道資源中刪除標籤，則該資源將沒有任何 'bridgetrack
   • 列表中的專案數量（以及標籤 trackdirections 列表中的值數量）必須與TS12 及之前版本的 Trainz 到 TS09 的橋樑中的樣條線中的軌道數量相匹配。
   • 對於更新單軌或單樣條線道路橋樑，使用 CM 驗證這些版本的錯誤，使用兩個非常小的偏移量，例如 trackoffsets -0.001,0.001。

在更新或調整橋樑資源時...對於構建值 2.9 到 3.4，確保列表中有兩個條目。示例為 -0.01,4.99（5 米間距）或 2.5,-2.5。這些資源將在 TS12 中具有兩條軌道。對於 3.5 及更高的構建值，如 TRS 和 Trainz 系列資料模型的早期 KINDS 中，使列表中的專案數量等於軌道的數量，並且將顯示預期的軌道數量。

 

錯誤：容器“<container name>”中的十進位制標籤“<tag name>”不是有效的十進位制值。

示例：錯誤：容器 14 中的十進位制標籤“object-size”不是有效的十進位制值。

標籤值不是有效的十進位制數。例如，輸入了“0,05”而不是“0.05”。編輯標籤值，使其成為有效的十進位制數。

錯誤：無法載入動畫檔案“<animation file name>” (no resource)。

在資源中找不到動畫檔案。

• 此錯誤在 kind mocrossing 中很常見，其中網格中沒有動畫。例如，道口可能具有閃爍的燈光，但沒有欄杆或閘門，或者該資源可能是 kind mocrossing，因為它需要迎面而來的火車觸發的事件，而不是動畫。即使它未在 config.txt 中引用，CM 要求 kind mocrossing 的資源存在動畫檔案。在這種情況下，可以將任何有效的 anim.kin 檔案新增到資源中以消除錯誤。可以在 userdata 中搜索合適的檔案——所需要的只是一個有效的 .kin 檔案來滿足 CM。

如果網格支援動畫並且沒有動畫檔案，那麼修復它將很困難。如果該資源是一系列類似道口的其中一部分，那麼來自該系列中另一資源的 anim.kin 檔案可能有效——應徹底測試這一點。如果網格是動畫的並且沒有正確的 anim 檔案，仍然可以使用不同的檔案代替，最糟糕的結果是動畫不會發生。無法從網格資訊建立正確的動畫檔案。如果替換動畫檔案，請確保使用 Loco 在軌道上測試它，使其從遠處逐漸靠近。如果動畫沒有觸發，則該資源至少可以使用。如果它觸發了，那麼你可以決定效果是否可以接受，然後再決定是否進一步修復該資源。

錯誤：缺少必需的容器“<container name>”。

在某些情況下，這可能也是警告，即使它說“必需”。它表明資源型別需要特定的容器，但該容器尚未包含在 cofig.txt 檔案中。此問題的解決方法取決於容器（某些容器可以輕鬆建立，而另一些則不能）和資源型別。

錯誤：“<container>”中指定的 kuid“<kuid>”型別不正確。

當容器中需要 kuid 時，它必須是適合該容器型別的 kuid。

• 例如，allowed-categories 子容器（位於queues 容器中）要求在子容器中列出一個或多個KIND 產品類別 資源。其他型別的資源（例如產品KIND 產品）將生成此錯誤。

 

案例 1，Queues 容器示例

錯誤：“product-kuid”中指定的 kuid“<kuid:-3:10044>”型別不正確。

 

分析

當訊息為：'錯誤：在“product-kuid”中指定的 kuid '<kuid:-3:10044>' 型別不正確。'

在這種情況下，在預期產品的情況下，在allowed-products容器中指定了產品類別。

該錯誤可能發生的原因是，一些看似是產品的資產實際上並非產品，而是KIND 產品類別。產品類別用於將一組產品分類為特定型別。類別可用於限制列為可用於新增到資產的可用產品的範圍。這些 kuid 不是在需要產品的標籤中有效的標籤值，但通常會在那裡錯誤地找到它們。

如果在allowed-categories容器中使用產品，也會發生類似的錯誤。  四種標準產品類別是：

 Passenger,<kuid:-3:10091>
 Bulk Load,<kuid:-3:10040>
 Liquid Load,<kuid:-3:10044>
 Container,<kuid:-3:10042>

 

兩種簡單的解決方法

1. 如果容器是產品容器，請將無效的產品類別替換為適當的產品。如果佇列具有product-kuid標籤，請使用該產品。
2. 如果容器是產品類別容器，請將產品替換為適合車廂的產品類別。

錯誤：KUID 標籤不是有效的 KUID 值：'<KUID>'

KUID 格式錯誤。例如：'<kui2:287205:15361>'。確認 KUID 並更正格式。

這是一個常見的錯誤，可能發生在構建號小於約 2.9 的原始資產中，因為如果某些非關鍵 KUID 引用不正確，則會被簡單地忽略。它也可能發生在指令碼設定為替換紋理的資產中。在這種情況下，紋理資產由指令碼提供，因此 KUID 可以保留為任何文字，例如“NULLKUID”。對於這些情況，可以插入任何通用紋理資產的 KUID - 它要麼不在模型中使用，要麼將由指令碼替換。據報道，可以簡單地刪除帶有丟失 KUID 的標籤，但這可能取決於指令碼如何使用此標籤，因此不建議這樣做。

錯誤：無法載入聲音檔案“<sound file name>”；請確保這是一個有效的 wav 檔案。

無法載入聲音檔案。該檔案可能丟失 - 可以在使用者資料中搜索該檔案並找到它。它可能已損壞或格式不正確。如果該檔案已從資產中刪除，因為它實際上不需要，那麼任何聲音檔案都可以使用，至少可以安裝資產，以便確定聲音檔案的功能並找到合適的替代檔案。由於歷史原因，此錯誤也可能出現在從較早構建號升級的資產中 - 該檔案存在，config.txt 檔案條目似乎與檔名匹配，但警告仍然存在。在這種情況下，請確保 config.txt 中的檔名用引號（“）括起來 - 在不使用引號的情況下，尾隨空格或製表符可能會混淆 CM。

它也可能是“位元率”錯誤。使用 Audacity（免費軟體）等程式檢查，我的經驗是聲音檔案位元率為 4400mhz，更改為 22050 以匹配現有的工作 .wav 檔案，問題已解決。AssetX V3 及更高版本包含一個修復選項，可以解決聲音檔案的一些問題。

錯誤：指令碼類與資產型別 (<kind>) 不匹配。

資產指令碼試圖使用不適合資產型別 (kind) 的類。一個極端的例子是試圖將機車類用於場景資產。

• 請注意，與指令碼相關的錯誤只有在資產提交後才能完全識別。因此，當其他錯誤修復並且提交成功時，錯誤可能消失。如果與該錯誤相關的問題並不明顯，請將其保留到所有其他錯誤都修復後，提交資產，然後確認它是否仍然存在。

（當驗證開啟以進行修復的資產時，這種錯誤報告錯誤的情況並非該問題獨有。“檢視錯誤和警告”在用於開啟以進行修復的資產時不可靠，不應依賴它。在 Trainz 的更高版本中，當資產開啟時，它根本不起作用。始終在重新檢查錯誤之前提交資產。）

修復此錯誤並保留指令碼功能超出了本討論的範圍。

錯誤：在容器“attached-track”中，'<attachment point>' 和 '<attachment point>' 之間存在多個軌道段。

錯誤：在容器“attached-track”中，'<attachment point>' 和 '<attachment point>' 之間存在多個軌道段。軌道段必須是唯一的。

• 從 CM 版本 3.7 開始，這僅是 DLS 上傳驗證錯誤。

attached-track 容器包含一個或多個頂點子容器。子容器中列出的頂點對錶示頂點之間的連線。一對頂點只能有一個連線。透過刪除重複的頂點對之一來編輯頂點子容器。

錯誤：過時的 KUID <kuid> 不屬於此資產的過時歷史記錄。

此錯誤可能不再有效。請參閱以下兩項。

檢測到資產的過時歷史記錄存在問題。 但是，錯誤訊息中的描述不正確。問題是資產正在過時一個已經在資產的過時歷史記錄中的專案。例如，資產 <kuid:12345:6789> 可能包含一個過時表 -

 obsolete-table
 {
   0                                     <kuid:12345:6000>
 }

表示它過時了一箇舊版本。如果資產隨後以新版本釋出，它應該只使用 kuid <kuid2:12345:6789:1> 來表示以前的版本現在也已過時。該升級後的資產不應包含來自先前版本的過時表，因為這將在資產的過時歷史記錄中建立重複的過時引用。（但是，在版本增量方法不適用的其他情況下，需要過時表。）

編輯說明

為什麼會出現上述錯誤…

asset.tdx（資料庫索引檔案）只能包含對資產過時 KUID 的單個引用，因此雙重條目會生成錯誤訊息。雖然 CM 會“用假定的 KUID2 序列填充空白”當一個替代的 KUID2 跳過一個或多個版本字尾時，因此知道例如，使用“<KUID...:4> 來過時一個 KUID 或 <KUID...:1>；但是索引中的每個填充的數字只保留序列中的下一個替代 kuid。當考慮過時表作為替換查詢表的職責時，這是有道理的。資產的kuid-table列出較舊的 kuid 將與列表進行比較，該列表指向其替換項。計算機無法用兩件事替換一件東西，因此資產 .tdx 索引中的過時/替換表只能儲存單個條目。

• 從 CM 版本 3.7 開始，這僅是 DLS 上傳驗證錯誤。

此錯誤也已在沒有明顯重複替代資產的情況下觀察到，但序列中存在間隙

• <kuid:12345:67>
• <kuid2:12345:67:2>
• <kuid2:12345:67:3> - 被錯誤拒絕

錯誤：過時的 KUID <kuid> 已被伺服器上的 KUID <kuid> 標記為過時。

從構建 3.5 開始，這僅是 DLS 上傳錯誤。

兩個資產不應該使同一個資產過時，除非它們都是同一個修訂歷史的一部分。這個資產包含一個過時的表格，其中包含一個條目，該條目包含一個已經被其他資產過時的資產，但這兩個資產不屬於同一個版本序列。過時表格應該進行調整。

注意：當兩個資產都是同一個修訂歷史的一部分時，已經觀察到此錯誤。此不正確的驗證可能已被修復：請參閱“先前過時的 KUID <kuid> 缺少新的資產過時表”。

例如

<kuid:12345:66> 存在於 DLS 上。上傳了一個更新的版本 <kuid:12345:67>，其中包含一個過時表

obsolete-table
{
  0    <kuid:12345:66>
}

然後將資產 <kuid:12345:67> 升級到 <kuid2:12345:67:1> 並上傳。如果過時表保留在這個版本中，那麼資產 <kuid:12345:66> 現在就被這兩個更新過時了：這應該允許，但在某些情況下，上傳被拒絕。解決方法是刪除過時表，並依賴 kuid 版本號來指示過時。

此錯誤訊息可能是“過時的 KUID <kuid> 不屬於此資產的過時歷史記錄”錯誤訊息的替代。 但是，看來過時表驗證規則的更改意味著此錯誤對於上述情況不再發生。

錯誤：先前過時的 KUID <kuid> 缺少新的資產過時表

從構建 3.5 開始，這僅是 DLS 上傳錯誤。

如果此資產使具有不同內容 ID 的資產過時，則該過時資產必須包含在此資產的過時表中。此訊息表明 DLS 知道此資產使具有不同內容 ID 的資產過時，但該過時資產缺失於過時表中。DLS 可能知道該過時資產，因為它位於此資產過時的資產的過時表中。

例如，如果資產 <kuid:12345:67> 具有過時表

obsolete-table
{
  0    <kuid:12345:66>
}

那麼稍後的版本，例如 <kuid2:12345:67:2> 必須具有過時表

obsolete-table
{
  0    <kuid:12345:66>
  1    <kuid:12345:67>
  2    <kuid:12345:67:1>
}

換句話說，資產的過時表必須包含該資產的完整過時歷史記錄。

請注意，此錯誤訊息似乎與訊息“錯誤：過時的 KUID <kuid> 已被 KUID <kuid> 在伺服器上標記為過時”相矛盾，因此是過時表驗證規則的更改。

錯誤：TADCompileAsset 無法確定資產 KUID

用於資產的 kuid 無法解析為有效的 kuid。它可能是格式錯誤（例如，<kuid2:-1:110000:0>）或可能存在關於衝突的 kuid 號碼的內部問題。檢查 config.txt 中的 kuid 並確認其正確無誤。

錯誤：無法提交對資產 <kuid:xxx:yyy> 的更改，因為配置檔案包含錯誤的 KUID

資料庫中記錄的資產 kuid 與 config.txt 檔案中的 kuid 不一致。

當資產被開啟以進行編輯時，資產的狀態將記錄在資料庫中。當資產被提交時，資產將從編輯資料夾載入回資料庫，並且狀態將被更新。如果在將資產載入回資料庫的過程中檢測到資產 kuid 與資料庫中記錄的內容不同，則會發出此錯誤。

如果要更改資產 kuid，則必須透過“檔案/匯入內容”（至 TS12）或“檔案/匯入內容資料夾”（T:ANE）選單選項載入資產，並且應恢復原始資產。

錯誤：重新編譯後“<script>.gsl”上出現 CRC 不匹配。您是否同時擁有 .gs 和 .gse？

資料庫修復錯誤。資產可能在 CM 中顯示為錯誤圖示，但沒有錯誤訊息可用。開啟資產進行編輯然後重新提交可以清除錯誤。

參考文獻

 

資料模型更改

Trainz Classics 中一些過時的 資料模型 更改

這些故障和警告是在將一個成熟的 TB v2.6 機車引入 Classics 時生成的： 

在 Trainz Classics 的“steam”容器中過時的標籤。
'boiler-to-piston-flow'
'firebox-to-boiler-heat-flow'
'firebox-to-boiler-heat-flow-idle'
'firebox-volume'
'main-reservoir-volume'
'piston-to-atmosphere-flow'
'westinghouse-volume'
這些標籤-值對在指示的容器中生成錯誤
錯誤：標籤“epbrakes”在容器型別“steam-engine”中不允許
錯誤：標籤“max-fire-coal-mass”在容器型別“steam”中不允許

 

注意

解釋和闡述