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 進行紋理剝離模式來解決。

如果您要對此頁面進行更改，請註冊為 Wikibook 編輯，以便您可以被識別，並且可以就您解決方案的任何問題與您聯絡。已添加了一些更改，這些更改會讓人感到驚訝，因為它們對於較新的版本來說並不理想。此類修復可能對 TRS2004——TRS2006 版本有效，但對於較新的版本修復來說不太有利，對於 TRS 來說更是微不足道！

 

編輯說明： 在以下內容中，短語在型別為<container-name>的容器中不允許通常實際上是指在所討論的 config.txt 檔案中的 資產“KIND” 資料定義。下面的一些也可能適用於 容器 和/或子容器，但大多數看到的都是指 KIND。

一些數量很少的“不良資產”可以（由於系統性地“清理 DLS”而發生的頻率越來越低），當這些資產在路線中被發現時，它們中的許多問題也可以得到修復。大多數可以歸類為關鍵詞的誤用、拼寫錯誤、缺少引號等。任何人都可以使用文字編輯器（如 Notepad 或 Notepad++）修復這些小問題。偶爾會發現某個資產缺少元件——要麼是紋理，要麼是網格（被紋理“裝飾”的線框，從而形成虛擬物件。一個是表面，另一個是底層形狀的骨架）。到目前為止，大多數這些資產都表明自己可以透過調整檔案路徑規範、在 config.txt 檔案中安裝更新的容器樣式資料結構或調整檔案資料夾內容（例如，V2.4 之前的資產處理能夠向上和向下查詢主要紋理或網格（im）檔案，這種處理在 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 中做出了貢獻，此外他還正在他自己的網站上製作教程系列。隨著老一代最初的 Trainzer 越來越少，像 Shane 這樣新興的愛好者正在崛起，重振 Trainz 作為社群互相幫助的精神。Shane 年輕、精力充沛、熱情，技術嫻熟，並且是一位不凡的 Trainzer，他的貢獻已經並且有望繼續惠及我們所有人很長時間。訂閱並瀏覽他的執行緒、網路論壇和新聞信件，對任何新的 Trainzer 來說都是非常值得的。而且他每天都會回答問題！幹得好，Shane。我們需要更多像你這樣的人。

1. 在 Shane 的網站上找到 PEV 的工具及其附帶的 .pdf 檔案 手冊（如果提供）。
2. 請參閱 設定 PEVtools，瞭解有關操作步驟和將專案放置位置的提示。
3. 請參閱 PEVtools，瞭解一些操作提示、教程連結和本地安裝中的高階設定。您也會在那裡找到節省時間的技巧和竅門。
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. 花一些時間在論壇上潛伏和觀察。使用 Google 的網站搜尋功能查詢有關您可能問到的任何主題或問題的條目。（site:forums.auran.com “問題文字關鍵字”。此方法在此網站上也適用！
2. 一旦您學會了處理 10 到 20 個錯誤，並看到了它們重複出現的方式，請在論壇上找到Asset-X 常見問題解答並訂閱，並開始逐漸學習曲線，同時定期、穩定地修復您遇到的任何其他有故障的資產。
   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 構建號。低於 <構建號> 的 trainz 構建號不再受支援

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

此訊息是警告 - 資源仍然可以使用（除非存在錯誤）。可以透過更改構建號來消除警告，但這可能會在針對更高構建標準驗證資源時產生新的錯誤。只有在您準備好進行所有其他更改以將資源更新到更高構建號時，才應更改構建號以消除此錯誤。

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

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

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

檢視 容器規範 這裡 或在 N3V Wiki 中，以確定該標籤是否已替換。如果存在替換，請選擇與已過時項中的值相對應的標籤值。如果對應的值不清楚，請接受預設值。在大多數情況下，可以簡單地刪除該標籤。

警告：檔案“<name>”不存在

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

警告：缺少必需的容器“縮圖”。

應該在 config.txt 中新增一個縮圖容器。

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

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

應該為該資產建立一個陰影網格，並更新網格表。

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

警告：紋理“<紋理名稱>”是單色。

新的資產不應該使用單色紋理，但對於需要更改網格的舊資產，則應該將紋理調整為 4x4，或至少將一個畫素更改為不同的顏色（無論顏色變化多麼微小）。大的單色紋理是資源浪費：不要為了避免警告而調整影像顏色，而沒有將紋理調整為合適的小尺寸 - 16x16 或更小。

據報道，如果影像小於 64x64，則不會生成此警告，但這似乎不適用於 Build 61388。一個畫素的差異足以消除警告。

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

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

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

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

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

漸進網格 (.pm) 可以使用 PEVtools 實用程式 PM2IM.exe 轉換為單個 索引網格 (.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 的 火車車廂，但對於構建級別為 2.9 及更高的所有資產來說，它都是一個推薦的升級。

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

警告：<值> 不是標籤“<標籤名稱>”的有效值。此標籤現在為空，必須選擇一個新值。

示例

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

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

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

警告：容器“<容器名稱>”中的布林型標籤“<標籤名稱>”不是一個有效的布林型值。

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

修復 將標籤的值更改為 0 或 1，根據資產的實際情況進行選擇。

• 請注意，在某些情況下，此訊息實際上表明標籤的定義是錯誤的 - 內容建立者遵循了正確的規則，但驗證使用的是不同的規則。例如，Trainz 的某些版本中的不透明度標籤。在這種情況下，正確的型別是 'value'（一個浮點數，範圍從 0.0 到 1.0），而不是 'boolean'。要消除錯誤，可以在 安裝根目錄\bin\TETData 資料夾中的 container.txt 檔案中重新定義 'opacity' 標籤的型別。仔細檢查該檔案的內容應該表明需要進行的更改，即使內容在第一眼看來並沒有什麼意義。

 

內容管理器錯誤資訊

使用 ORed KUID 列表來檢視修復後的資產，這是一種強大的技術，可以修改您的搜尋並準確地顯示您想要的內容 - 一些錯誤不會顯示為已修復，直到資產重新提交，或者您突然發現修復後的資產具有有問題的元件資產，就像在這種情況下探索這種情況一樣。 放大後，請參閱此影像上的描述。 點選此處影像始終可以為您提供更大的檢視。

獲取資產意味著要透過舊內容的錯誤關口，這些錯誤通常可以透過一系列簡單的編輯更改和 PEVtools 來修復。這是一個進行此類操作的指南，以及為什麼出現這樣的錯誤。 AssetX 和 TARDIS 指令碼可以用於自動修復其中許多錯誤。

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

 

錯誤：此資產的 Trainz-build 號碼不被此工具識別。

該資源的trainz-build 標籤 (TB, TBV) 值 對於您的 Content Manager 版本過高。

• 如果您收到此訊息，則可能表示您擁有 Trainz 的多個許可副本，因為對於沒有舊版本和新版本的人來說這種情況不會發生，並且您將無權訪問高於與零售版本相關的最高 TBV 的內容。

編輯注： 雖然 DLS 到 CM 的介面在 2015 年期間進行了一些大修，但 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 是在假設內容建立者或 Trainz 使用者正在嘗試“升級資源” 的情況下編寫的。設計的預期是，一個人試圖將資源轉換為更高 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>”的容器中不允許。

部分 - 哦，簡介

唉，羅馬人從未擁有過零！

正如仍然會咬人並困擾著最世故和經驗豐富的資源修復者...... 真正地，真正地，真正地，最有可能的第一個原因，一整組這些問題是缺少分隔符。

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

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

資產配置文字檔案（asset 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（技術水平！）值低於源 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' 型別的容器中使用。實際上，附加樣條線容器 是一個聚合值“子型別”或修飾符，它將建模軟體擴充套件到另一個子例程以解釋其值。它很像 場景與軌道種類 的 軌道容器（“附加軌道容器”），它包含允許兩種“種類”混合特徵的指令，允許工業、交叉路口和碼頭等資產具有其功能。

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

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

  這些錯誤訊息的底線是，軟體功能和 trainz-build 級別可能不同步。TBV 值標識何時在種類和容器調色盤上添加了某些功能。在早期版本中引用此類標籤會導致此類訊息。 

以下實際錯誤訊息：經常以 “作為一個組” 的形式，在大量使用 別名標籤 來引用外部網格的油漆棚標記的重新皮膚汽車中重複出現。

• 此組起源於 TS09 釋出之前的更鬆散的資料定義和處理方式及其更嚴格的錯誤測試。在此之前，任何以字母 字形 開頭的行首標記，該標記可能合法地被評估為可能的關鍵字（例如，height-below、width-of-interior 等），可以與引號字串配對，如果該標記不是關鍵字，則會被忽略。此外，如果該行以標點符號（'；' 和 '/' 很常見）開頭，則該行後面的內容直到行尾程式碼都被視為單個值，在這兩種情況下，Trainz 也會忽略該行。關鍵字 'REM' 來自 BASIC 語言，雖然從未正式使用，但被廣泛用於為整個用引號括起來的文字段落新增字首。因此，在 TS09 之前，CC（作者）可以嵌入他們自己的測試的替代值，或者允許使用者使用相同的網格將配置檔案自定義為完全不同的外觀，或者在應用資產時嵌入指令，如果使用指令碼，幾乎總是需要類似的東西。
• “（容器型別 'traincar'）”訊息可能會或可能不會出現，具體取決於解析配置檔案和驗證內容錯誤的 Content Manager 版本。這些示例錯誤訊息來自 TS2009-SP2's 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 容器中。貼上移動的剪貼簿（行）在 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 ) 重新測試它 (驗證) 並重新生成新的錯誤訊息列表（故障）—— 希望沒有！ 從 V3.2（TS10-SP2）開始的釋出軟體版本以及更高版本，包括 TS09 和 TS10 的 SP4（兩者都是 TBV 3.3）都會表現並解析錯誤，同時檔案仍處於開啟狀態供編輯，正如我們建議的更有效率一樣，使用久經考驗的 **ALT- **Tab ↹ 在 '活動視窗' 之間切換。

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

• 通常，在修復某些其他錯誤（通常是路徑修復）後，會顯示其他錯誤。
• 注意：路徑修復對於舊的（v2.6 之前的）資源來說是 迄今為止最常見的修復需求，因為在 trainz-build v2.9 之前，所有版本都能根據 asset-filename 標籤的分配值，以及諸如 '_art'、'_body' 和 '_shadow' 之類的字尾，在原始資料模型資料夾中正確定位資源元件。N3V 的程式設計師放棄了從 v2.9 (TS2009-SP0) 開始，使這些可預測的連結自動化的程式碼片段——迫使即使在簡單的資源中也使用 顯式路徑 和容器。最常見的需求是 縮圖、網格表 和 轉向架容器；建立大量計算機處理程式程式碼，並在其他可預防的故障生成訊息中產生故障。
• 強烈建議，如果你需要修復需要新增這些容器的故障，你也將 trainz-build 提高到 v2.6，並在該 TBv 中消除所有警告。這種修復方法在 TS12 中沒有例外。

第二部分

這個神秘的資訊，常見於較老的內容中，不是因為“？”（?，搜尋“？”不會找到這樣的！）而是因為GMAX或其他早於TRS2004（其內容不會出現此問題）的工具建立頁面時留下的下劃線（___）。

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

情況一

• '錯誤：標籤“？”在“engine”型別的容器中不允許。'
• '錯誤：標籤“？”在“bogey”型別的容器中不允許。'

 

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

解決方法：參考右側圖片的文字：這可能是第二行上的兩個不可列印的字元，應該直接刪除。 

情況二：例如，這可能只是一個簡單的拼寫錯誤。

• '錯誤：標籤“discription”在“...”型別的容器中不允許。'

因此將拼寫更正為“description”。

資產定義不是程式設計，但它們是程式碼，拼寫錯誤或其他與預期的偏差可能會產生錯誤訊息，就像在這種情況下一樣。

 

情況三，規範中不再存在的標籤

• '錯誤：標籤“origin”在這個容器中不允許。 '

解釋

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

解決方法：刪除該行。（查閱維基百科中記錄的已過時的配置標籤列表這裡。這些是最常見的情況（風景和路邊物體經過了多次更改：其他容器、KIND 和子容器自 V2.8（Trainz Classics 3）以來進行了較少的模型更改）。 

第三部分

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

錯誤是不同版本的 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 並將兩行標籤（包含逗號分隔浮點值的陣列引數）移動到描述資料中...實際上刪除了這些行，從而得到修復。

 

第四部分

子容器被錯誤地識別。

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

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

錯誤：' '<subcontainer name>' 中的 'image' 標籤必須具有影像副檔名。

實際例子

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

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

• 對於某些容器，'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 value>。

錯誤

由於檔案訪問錯誤，無法將更改提交到資產<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-build 號碼未被此工具識別

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

編輯者注：沒有 trainz-build 程式碼值的資產預設為 v1.3，這是最後一個沒有 trainz-build 程式碼值的 Trainz 版本。將Trainz UTC視為完成原始Trainz 1.0 版本設計目標的第四個服務包也是相當合理的，因為從 v1.3 到 v1.5 的最大變化是 UTC 添加了第一個 ContentManager.exe（分配為 v1.4，但與CMP 和CM 非常不同，它們取代了這些獨立的模組），以及添加了內容，以及 UTC 中包含的優秀*.doc MS Word（文字處理器）檔案的附加值。遊戲 GUI 的更改和新增（例如 TRS04—TRS06 之間的更改）非常小。

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

原因

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

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

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

網格、紋理、kuid 引用和其他類似的基本資產元素通常可以在所有構建中正常使用，回溯到 2.9。對於 2.9 之前的構建，所需的調整變得更加廣泛。

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

• 目前只有由kind track、地圖和會話資產以及包含需要指令碼功能的指令碼要求的資產（先前版本中沒有這些功能）阻止將資產降級到 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 的誤報並給出此錯誤訊息非常有效。

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

無法載入網格檔案。它可能在 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 之後）將（不出所料，因為它是由 TRS2004 引入的標準）被所有 Trainz 版本接受，並且通常被 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"
...

新手請注意！ 請注意，在具有資產檔名標籤的舊資產中，編輯資料夾和 '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. 連線點丟失，因此網格和包含資料點的容器再次不匹配。

'Numeric-name' 的解釋： 網格中由 佇列容器 中的子容器 passengers_off_0 引用的第 19 個連線點 名為 '18' 丟失。（'18' 是 佔位符引數 引用 - 一個作為名稱或標籤的數字... 並且可以重新命名為 'xyz'、'glops' 或任何不包含空格的名稱，只要它出現在容器的第 19 行（資料表）上即可）。

按照慣例，Trainz 中的子元素通常被賦予數字佔位符，但在大多數情況下，任何可解釋為字串的條目都可以正常工作。
 • 作為佔位符引數，數字被解釋為字串，沒有權重或值，就像標籤名稱一樣。
 • 重要的是，必須在{...} 對中，其中的內部行也希望關鍵字（或佔位符）與值配對，正如 Trainz 中普遍存在的那樣。
 • 請注意，配對的 { ... } 大括號 的內容與前面的 型別 或 容器名稱 配對。

錯誤：在 'container-name' 中未找到連線點 'numeric_name'。
 • 這些是製造的錯誤（透過向容器新增 3 行虛假資料），在修復第一個錯誤訊息後。
 • 這兩種情況都給出相同的錯誤訊息語法... 一個缺少正確的名稱，另一個缺少連線點。

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

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

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

錯誤：在 '<effect name>' 中的連線點 '<attachment point name>' 必須在網格 '<mesh name>' 中找到。

在 config.txt 中引用了一個連線點，但它不存在於預設網格 <mesh name> 中。這通常發生在從另一個資產複製了 config.txt 時，並且從網格中刪除了連線點。例如，一個交叉路口閘門的燈連線點已從網格中刪除，但燈的日冕效果仍然引用了丟失的連線點。

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

錯誤：在網格中必須找到 '133' 中的連線點 'a.lite121'。 ''.

錯誤：連線點 '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' 標籤，這是引用附著點所必需的。

容器（子容器）將在 mesh-table 中。訊息表明容器缺少一個必要的 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。然後調整紋理檔名以匹配。通常，紋理.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 個檔案會增加定製能力！-ed。） 重要的是要了解，在 V2.7 之前，TRS2004 和 TRS2005 沒有明確允許的 AlphaMask 模式更改行。一切都是預設模式。這些行是在後來為了擴充套件功能而新增的，因此，這兩個訊息提供了一些關於那個時代資料演變的見解。 TRS2004 及更早版本的資源可能甚至沒有使用 texture.txt 檔案，而是基於使用字尾組織的舊資料夾。（懷疑，ed.)Ø

1. 上面的錯誤訊息對出現在一個 v1.3 的塔式泛光燈資源中，其中只有三個灰度.bmp 檔案中的一個用於更改塔上每個燈光的亮度和特性，從而賦予它們個性，並增添一些獨特之處。在庭院泛光燈資源中，與其他泛光燈並排排列，三個不同的陰影蒙版可以逼真地複製原型中單個燈光的實際屬性。
2. 當圖形檔案完全丟失時，通用的解決方法是用能夠勝任工作的檔案替換它。
   1. 在上面的情況下，只有三個 AlphaMask 中的一個存在，因此，它被複制並修改，以複製所需的個性，並滿足 'texture.txt' 包含檔案。（見上圖和右側）
3. 其他型別的故障通常是因為早期的 Trainz 會完全讀取資料夾的內容，並且不加區別地索引每個檔案並將其放入記憶體塊中 - 這使得可以引用資原始檔夾層次結構中的任何位置的 .bmp 或其他支援檔案（包括位於資源根目錄之上的檔案）。
   1. 但是，如果內容項使用相同的檔名但資料不同，則舊方法有時會產生微妙的問題。
   2. 較新的 Trainz 不會以相同的方式查詢內容，它們依賴於指定的路徑規範，並且 texture.txt 檔案用於確保明確指定了正確的 路徑規範/檔名規範。當子資料夾或資源根目錄資料夾包含在 filename.texture.txt 檔案中指定的某個檔案時，就會產生這種分支錯誤效果......在 Trainz 1.3--TRS2006 中很容易找到的檔案突然變得與路徑規範斷開連線，從而破壞了資源。

錯誤: 在驗證網格 '<mesh filename>' 時，無法為紋理 '<texture filename>' 載入影像檔案 '<image filename>'。

請注意，此錯誤與下面的錯誤（無法載入主紋理）經常一起出現。

紋理.txt檔案中所指的影像無法載入。該影像可能丟失，紋理.txt檔案中的名稱可能拼寫錯誤，影像檔案格式可能不正確（例如，壓縮的TGA），影像尺寸可能不是2的冪（在需要的情況下），或者影像檔案可能已損壞。 

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

  示例：錯誤：無法載入影像檔案 'shadow.bmp' 以用於紋理 'shadow'，同時驗證網格 'shadow.im'

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

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

錯誤：無法載入主紋理 '<image filename>' 以用於紋理檔案 '<texture filename>'。

請注意，此錯誤與前面的錯誤（無法載入影像檔案）經常（如果不是總是）一起出現...

紋理.txt檔案中所指的主影像無法載入。該影像可能丟失，紋理.txt檔案中的名稱可能拼寫錯誤，影像檔案格式可能不正確（例如，壓縮的TGA），或者影像檔案可能已損壞。

示例-1：錯誤：無法載入主紋理 'shadow.bmp' 以用於紋理檔案 'shadow.texture.txt'。

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

  示例-2：錯誤：無法載入主紋理 'greyhound_stop_1_nightwindows/bussstatin1.tga' 以用於紋理檔案 'greyhound_stop_1_nightwindows/bussstatin1.texture.txt'。

• 解決方案：關鍵是關注關鍵詞“主紋理”('//bussstatin1.tga')，但是...該檔案位於資產資料夾的根目錄中，需要將其複製下來，而夜間模式紋理.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 壓縮 'ON'（在許多圖形應用程式中單擊框選項）。TS09 及更高版本無法容忍預壓縮的TGA檔案（Trainz 從那時起在提交資產時進行自己的壓縮，PEV的Images2TGA 會提取這些壓縮檔案）。

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

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

或者，在Windows中複製檔案，然後進行調整 - 允許跳過對紋理.txt檔案的更改。

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

編輯者注： 新使用者可能不知道你可以大膽...CTRL+R（或透過選單下拉）會將修復失敗的資產恢復到從未修復的狀態，包括關閉編輯資料夾和刪除修復失敗的內容。因此，雖然像上面這樣儲存檔案是一個好習慣，可以讓你掌握控制權，但弄亂了也不是世界末日。

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

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

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

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

注意：許多內建資產在資產詳細資訊窗格中不顯示縮圖影像。這是因為資產使用對 JPG 影像的直接引用作為縮圖。來自 JA 檔案的資產將丟失未從紋理.txt 檔案引用的影像，因為這些影像未包含在 JA 中。這與使用者無關，使用者無法建立 JA 檔案。

關於如何使用紋理.txt和影像檔案，在 此處引用的腳註 中有詳細的討論。

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

紋理.txt檔案中所指的影像由於某種原因無法處理。參見上文。

錯誤：主紋理和alpha紋理的大小不相同，用於 'texture.txt 檔案'

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

如果出現以下情況，就會報告該錯誤

• 使用了兩個不同的影像，但這兩個影像的大小不一致。
• 需要兩個不同的影像，但只能載入一個影像。

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

• 1- 如果提供了兩個不同的影像，但它們的大小不一致，請調整其中一個影像的大小，使其與另一個影像的大小一致。

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

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

當紋理檔案壓縮時，也會出現此錯誤，並伴隨著一條無法載入紋理檔案的錯誤訊息。這在 GIMP 中很常見，因為在 “另存為”模式 對話方塊的選項選單中隱藏了將檔案儲存為壓縮/未壓縮、24 位/32 位的選項。對於 Paint.Net 使用者，這些選項將作為“另存為”對話方塊頁面的一部分顯示。（對於 Irfanview，TGA 檔案沒有選項頁面 - 預設格式為 32 位未壓縮）。

選項 1 可能是修復某些資源的更簡單方法，但 32 位 TGA 檔案是更好的選擇。

示例問題和解決方案

示例情況 1

錯誤顯示在藝術子資料夾中

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

錯誤：'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（透明蒙版）檔案造成的。

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

編者注：修復火車車廂資源的藝術檔案資料夾中的問題或警告是一個簡單的過程，這有助於確保資源在 Trainz 的後續版本中保持有效。

• 512x512 藝術檔案不再使用，因此可以刪除 texture.txt 檔案和影像檔案，並刪除匹配的縮略圖表條目。
• 可以透過引用控制的 texture.txt 檔案 來使用 512x512 影像作為 240x180 縮圖，但在縮圖容器標籤中仍然將高度和寬度分別指定為 180 和 240。但是，這將建立失真影像。首選的方法是在影像編輯器中編輯 512x512 影像並將其儲存為正確大小的 JPG。
• 128x64 圖示藝術檔案仍然用於列表（例如，Railyard 中的火車車廂列表或測量師的“火車車廂”選項卡列表）。它是可選的，另一個大小相似的影像將按比例縮放以適應，但結果通常不可接受。影像應該是側面檢視，透視效果最小且背景透明，火車車廂位於影像的上半部分。
• 對於 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 時代的版本簡單地忽略了無效的標籤——這種處理方式應該一直延續下去，因為它讓計算機在眨眼之間完成了一項任務，但卻給成千上萬的使用者帶來了時間上的壓力，“修復因程式設計師的命令而損壞的資源！”——這就是為什麼這頁成為必需的原因！
    • 例如，一些指令碼使用的標籤用於提供執行編號範圍（起始和結束的合法值），它們通常作為 config 檔案中的頂級標籤包含在內。這些“自定義標籤”現在不再允許作為頂級標籤使用——它們必須移動到 'extensions' 容器中，並且必須修改指令碼程式碼，以便在 config 程式碼湯中找到它們的新位置。或者，可以從 config 檔案中刪除這些值，並在指令碼檔案中硬編碼——具體細節取決於指令碼。
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 解決多個聲音處理問題的預期方案中是不必要的，然後在 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 個。

情況一——聲音指令碼容器中成對的 repeat-delay 標籤值

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

實際示例——具有三個不同聲音效果的資產

Slugsmasher's trainz-build V2-4 —SS Log Dump 柴油機，<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 驗證過程中將所有橋樑解釋為雙軌，並且始終至少需要兩個值。這伴隨著樣條線的類似變化，將其定義為軌道 KIND 子型別，以及所有軌道軌道資產。

• 更新出現此錯誤訊息的舊資產的正確方法取決於哪個 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 一樣，使列表中的專案數量等於軌道數量，並將顯示預期的軌道數量。

 

錯誤：容器“<容器名稱>”中的十進位制標記“<標記名稱>”不是有效的十進位制值。

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

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

錯誤：無法載入動畫檔案“<動畫檔名>” (無資源)。

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

• 此錯誤在 kind mocrossing 中很常見，其中網格中沒有動畫。例如，道口可能有閃爍的燈光，但沒有欄杆或閘門，或者資產可能是 kind mocrossing，因為它需要由駛近的列車觸發的事件，而不是為了動畫。CM 要求，即使動畫檔案在 config.txt 中沒有被引用，對於 kind mocrossing 的資產也必須存在動畫檔案。在這種情況下，任何有效的 anim.kin 檔案都可以新增到資產中以消除錯誤。可以在 userdata 中搜索合適的檔案 - 只需要一個有效的 .kin 檔案來滿足 CM。

如果網格支援動畫，但沒有動畫檔案，那麼修復它將很困難。如果資產是多個相似道口的一部分，則來自該系列中另一個資產的 anim.kin 檔案可能有效 - 這應該經過徹底測試。如果網格是動畫的，但沒有可用的正確 anim 檔案，仍然可以用不同的檔案進行替換，最壞的結果是動畫不會發生。無法從網格資訊建立正確的動畫檔案。如果替換動畫檔案，請務必使用 Loco 在軌道上進行測試，使其從遠處逐漸靠近。如果 anim 沒有觸發，那麼資產至少可以使用。如果它確實觸發了，那麼你可以在決定是否進一步修復資產之前，決定效果是否可以接受。

錯誤：缺少所需的容器“<容器名稱>”。

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

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

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

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

 

案例 1，佇列容器示例

錯誤：“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 的標記可以簡單地刪除，但這可能取決於指令碼如何使用此標記，因此不建議這樣做。

錯誤：無法載入聲音檔案“<聲音檔名>”，請確保這是一個有效的 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 上傳驗證錯誤。

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

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

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

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

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

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

編輯註釋

上述錯誤發生的原因...

asset.tdx（資料庫索引檔案）只能包含一個關於資產使 KUID 過時的引用，因此雙重條目會生成錯誤訊息。當一個取代的 KUID2 跳過一個或多個版本字尾時，CM 將“填補空白”，並使用一個假定的 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' 中

 

備註

解釋和詳細說明