Trainz/AM&C/資產修復

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

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

詞彙表

HKeys-CM

HKeys-DVR

HKeys-SUR

HKeys-WIN

滑鼠使用

符號

貢獻作者：The Yesterdayz-Trainz小組

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

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

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

如果您要對此頁面進行更改，請註冊為Wiki書籍編輯器，以便您可以被識別，並且可以就您的解決方案與您聯絡。添加了一些更改，可能會讓人質疑，因為它們對於較新的版本來說並非最佳選擇。此類修復對於TRS2004—TRS2006版本來說可能沒問題，但對於較新的版本修復來說不太理想，對於TRS版本來說也並不理想！

 

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

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

已經採用了各種技術，需要不同的資料，或者組織資料的方式不同。這些更改中的大多數在軟體內部自動處理。當它們無法處理時，它們會生成錯誤，這是一件好事。資源中出現錯誤遠比資源中的缺陷導致程式崩潰好——這在TRS2006的早期階段非常常見，當時第一個基本的錯誤測試增強措施被構建到CMP軟體及其Service Pack 1中。

T:ANE中的VE訊息

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

獲取和安裝PEVs工具

PEVs工具位於高階使用者的C:\Downloads資料夾中（您的工具可能位於其他位置）。

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

Shane Turner還在Auran論壇上主持了許多問答主題，並在此處和N3V wiki中做出了貢獻，此外還在他自己的網站上製作了一個教程系列。隨著老一代最初的Trainz使用者逐漸消失，像Shane這樣更新的愛好者正在不斷湧現，重燃Trainz社群互助的精神。Shane年輕、精力充沛、熱情，技術嫻熟，並且是一位經驗豐富的Trainz使用者，Shane的貢獻已經並將繼續惠及我們所有人很長一段時間。訂閱並瀏覽他的主題、網路論壇和新聞通訊，對於任何新的Trainz使用者來說都非常值得。而且他每天都會回答問題！讚美Shane，我們需要更多像你這樣的人。

1. 在Shane的網站上找到PEVs工具及其附帶的.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. 花一些時間在論壇上“潛伏”和觀察。使用谷歌的網站搜尋功能查詢關於您可能提出的任何主題或問題的條目。（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 內部版本號。不再支援低於 <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 中新增 thumbnails 容器。

對於 3.5 版本及以後的 DLS 上傳，這是一個錯誤，上傳將被拒絕。請參閱錯誤列表中的對應項。

警告：此資源需要陰影網格，但網格表中不包含陰影網格。

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

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

警告：紋理“<texture name>”為單色。

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

據報道，如果影像小於 64x64，則不會生成此警告，但這在 Build 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”（假）或“1”（真）。使用任何其他整數值都會導致此錯誤訊息。在某些舊資源中觀察到 2 到 7 的整數值。可以合理地假設，除了 0 之外的任何值都表示“真”。

修復 根據資源的需要，將標籤的值更改為 0 或 1。

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

 

內容管理器錯誤訊息

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

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

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

 

錯誤：此資產具有此工具無法識別的Trainz構建編號。

該資產的trainz-build標籤 (TB，TBV) 值對於您的Content Manager版本來說過高。

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

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

幾乎所有具有更高TBV的內容都可以透過降低構建編號以匹配您的版本來使用，除非使用了僅在更高版本中可用的功能（包括某些指令碼功能）。對於我們這些執行多個Trainz版本的人來說，隨著DLS軟體並不總是正確的（並且可能根本沒有在TS09、TS10和TS12中檢查TBV——每個版本都下載了幾個更高的3以及少量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-build程式碼值就可以顯著改變看到的錯誤列表！例如，請參閱第三部分（下文）。

• 在許多情況下，回退構建編號也會影響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>的容器中不允許使用。

部分 - 哦，簡介

唉，羅馬人從未有過零！

正如仍然可能困擾最老練和經驗豐富的資產修復人員一樣……一個真正、真正、非常可能的首要原因，導致這一整組問題是缺少分隔符。

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

提示：搜尋錯誤訊息中**名為第一個標籤**的標籤（通常會有很長的列表……可能佔據檔案某些部分的每個單詞），然後檢視其上方是否有缺少的內容！有時它可能只是一個額外的字元，一個多餘的雙引號（或花括號）都很常見——或者缺少一個“端蓋”（分隔符）。這些是巢狀錯誤，歷史上每個程式設計師每天都會犯一堆這樣的錯誤……至少持續幾分鐘……沒有理由讓內容創作者比他們更優秀！

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（技術水平！）值低於原始碼。第三種情況與第二種情況相反，但僅僅是因為在每種情況下，某些內容都超出了其適當的時間和地點（以及 TBV 級別）。也就是說，如果將高階資料標籤引入早期技術級別的錯誤檢查，則可能會出現相同的引號。很容易理解。將 trainz-build 標籤值至少減少 0.5，並觀察錯誤訊息的變化。如果你必須編輯內建資源，經常會看到的一件事是，它們在生產過程中使用全域性更改的 TBV 進行存檔，因此，當開啟多年來存在的標籤時，它們會突然顯示為非法。有趣！哈！將 TBV 降低到 2.3--2.5 並確保它具有 mesh_table 和縮圖容器，大多數舊資源可以很好地轉換到 TANE 的 V4.2 更新。

瞭解 Trainz 資料應該始終被視為標籤（關鍵字）和配對的值（資料）。這即使對於 Trainz 的 容器資料型別 也是如此，因此外部括號定義了值邊界，可以這麼說。類似地，當被視為字串中儲存的值陣列時，例如 category-era、category-keyword 和 category-region，即使對我們人類來說是多值物件，也可以解釋為單個配對值……只是軟體期望包含多個子值的值，可以這麼說。最終，這一切都取決於計算機如何解包和利用資料。配對術語，甚至分配了明確且不會與其他內容混淆的列舉關鍵字的複合術語，是構建需要快速執行和解釋的收集整理資料的非常安全的方法，就像一輛 70 英里的火車穿過城市的後街一樣！

“看似相反地”，將資源降級到較早的 trainz-build 標籤值會直接更改錯誤檢查，因此也可能會顯示此類訊息。當然，你實際上可能正在將資源帶到 Trainz 的早期版本，就像我們中的一些人做的那樣，這將大大增加看到此類訊息中引用的“新標籤或容器名稱”的可能性。以下兩個錯誤是由將“新模型”軌道資源從原始的 V3.5 或 V3.6 帶到 TBV 2.9 而分別生成的。

• 錯誤：標籤“follows-spline-gradient”在型別為“track”的容器中不允許。
• 錯誤：標籤“attached-splines”在型別為“track”的容器中不允許。實際上，attached-splines 容器 是一個聚合值“子型別”或修飾符，它將建模軟體擴充套件到另一個子例程以解釋其值。它很像 kind SceneryWithTrack 的 軌道容器（“附加軌道容器”），它包含允許兩種“種類”混合特徵的指令，允許工業、平交道和碼頭等資源具有其功能。

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

• 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 的 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 ) 重新測試它（validate）並重新生成新的錯誤訊息列表（故障）——希望沒有！從 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' 之類的字尾，在原始資料模型資料夾中找到資源元件。從 v2.9 (TS2009-SP0) 開始，N3V 的程式設計師丟棄了使這些可預測連結自動生成的少量程式碼片段，從而迫使即使在簡單的資源中也必須使用顯式路徑和容器。最常見的需求是縮圖、網格表和轉向架容器；這導致了大量計算機處理程式程式碼產生的錯誤，以及其他可避免的錯誤生成訊息。
• 強烈建議，如果您需要修復需要新增這些容器的錯誤，也請將trainz-build版本提升至 v2.6，並消除該 TBv 下的所有警告。此類修復在 TS12 中均有效。

第二部分

這條常見且經常出現在較舊內容中的神秘訊息，並非由於'?'（?，搜尋'?'不會找到！）而是由於GMAX或其他早於 TRS2004 的實用程式（其內容未顯示此問題）建立的頁面中遺留的下劃線（___）造成的。

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

情況一

• '錯誤：'engine' 型別容器內不允許使用'?'標籤。'
• '錯誤：'bogey' 型別容器內不允許使用'?'標籤。'

 

這條常見且經常出現在較舊內容中的神秘訊息，並非由於'?'（?，搜尋'?'在 config.txt 檔案中不會找到任何內容！）。該錯誤是由gmax的遺留工件字元（通常在 config 的第二行上——不可列印字元（在大多數文字編輯器中由下劃線（___）表示）插入，由作者保留（並被 Trainz 的早期版本忽略）導致的。

修復：請參考右側影像中的文字：這可能是第 2 行上的兩個不可列印字元，只需將其刪除。

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

• '錯誤：'discription' 標籤在...型別容器內不允許使用。'

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

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

 

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

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

解釋

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

修復：刪除該行。（查閱此處華夏公益教科書中記錄的已棄用的 Config 標籤列表。這些是最常見的情況（自 V2.8 (Trainz Classics 3) 以來，風景和路旁物體發生了許多變化：其他容器、KIND 和子容器的資料模型變化較少）。

第三部分

此情況與上述情況相反：較舊版本中找不到的新標籤！

錯誤是由於 Trainz 不同版本釋出的驗證規則不一致導致的。

例如

錯誤：'enginesound' 型別容器內不允許使用'engine-sound-ramp-up-durations' 標籤。

錯誤：'enginesound' 型別容器內不允許使用'engine-sound-ramp-down-durations' 標籤。

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

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

解決方案

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

 

第四部分

子容器識別錯誤。

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

另一個類似的例子是煙霧容器 - 煙霧容器的型別由'mode' 標籤的值定義，並且該標籤值決定了該容器需要或允許使用哪些其他標籤。

錯誤：'<子容器名稱>' 中的 '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 值> 的更改。

錯誤

由於檔案訪問錯誤，無法提交對資源 <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. 此錯誤可能是由於 config 檔案中缺少關鍵資訊導致的。例如，如果找不到“kuid”標籤，則會報告此錯誤訊息，即使實際錯誤應該是“無效的配置檔案”。請檢查是否包含所有必需的標籤，並確保拼寫正確。

錯誤：此資源具有此工具無法識別的 trainz-build 編號

每個 Trainz 專案都包含版本或“構建編號”，作為必填項，即資源的 config.txt 檔案中的 trainz-build 標籤。

編輯說明：沒有 trainz-build 程式碼值的資源預設為 v1.3，這是最後一個沒有 trainz-build 程式碼值的 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 編號向遊戲定義了建立資源的技術標準。它還定義了 內容管理器 在對資源進行驗證和新增到本地資料庫的操作時進行驗證的標準。這使遊戲能夠根據適當的技術標準驗證資源，並根據需要插入預設值或忽略功能。它是維護 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 或更早版本的 trainz-build，並可能補償（TS09—TS12 的到 TRS 的需要刪除紋理檔案行，以便它們可以使用預設模式，因為 TS09 及更高版本允許對其改進的圖形處理進行更精細的控制。）texture.txt 檔案中任何次要命令更改來正常工作。

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

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

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

• 如果遇到真正的錯誤，則在沒有訪問網格原始檔的情況下無法修復此條件，則必須聯絡資源的作者。問題必須反饋給內容建立者。
• 塊號指示錯誤發生在網格的哪個部分。

• 即使網格本身有效，TANE 在某些使用非常大網格的資源中也會出現此錯誤。TANE 無法處理 TS12 中可接受的網格大小。

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

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

無法載入網格檔案。可能是 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 檔案，請檢查資源的 mesh-table 容器 中的資料夾/路徑規範條目，並驗證 PATH（許多舊資源都有一個 'asset-name'+'_body' 子資料夾，這是直到 TRS2006 中期版本的約定，因此可能存在於任何 v1.3-v2.4 資源中）和 檔名規範（包括副檔名）是否正確。
   1. 在這些較舊的資源中，如果路徑規範正確，則可能沒有安裝 mesh-table。新增一個（至少在 v2.0 之後）將（不出所料，因為它是在 TRS2004 中引入的標準）被所有 Trainz 版本接受，並且 N3V 的 TS09-TS12 版本中較差的解析通常會要求這樣做。
   2. 大多數將位於以 字尾 '_body' 結尾的子資料夾中。
      ‌ 實用節省時間的提示：在 ..\editing\asset-folder 中，單擊一次子資料夾，然後按鍵盤序列 F2+CTRL-A+CTRL-C，(然後 ESC) 以捕獲子資料夾名稱的精確語法(並且不更改任何內容)。
   3. 然後將其貼上為 mesh-table 路徑前端："subfolder-name_captured\mesh_filename.IM"。
   4. mesh-table 樣板示例（調整 路徑規範 和 檔名 以匹配您的資料夾內容）

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

Trainz 新手請注意！ 請注意，在具有 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. 附件點丟失，因此網格和列出資料的容器再次不匹配。

“Numeric-name” 的解釋：網格中引用的 queues 容器 在子容器 passengers_off_0 中，第十九個名為“18”的附件點丟失。（“18”是 佔位符引數 引用——充當名稱或標記的數字……並且可以重新命名為“xyz”、“glops”或任何不帶空格的名稱，只要它出現在容器（資料表）的第 19 行即可）。

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

錯誤：在 '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. 如果重新命名失敗，則可以簡單地刪除該行。如果是這樣，產品 queues 容器 中的“size” 標記編號應遞減，以正確初始化陣列的大小並節省執行時記憶體。

人員，也就是乘客是 Trainz 處理與乘客行業相關的資源（例如客運車廂和車站站臺）的方式中的“產品”。

錯誤：網格 '<mesh name>' 中必須找到 '<effect name>' 中的附件點 '<attachment point 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 } "

錯誤：連線點“<連線點名稱>”必須屬於效果<網格名稱>的父網格。

這通常與上一條訊息一起出現。連線點不僅在網格中找不到，而且在效果所附著的父網格中也找不到。其原因與上一條訊息相同。

錯誤：容器“<容器名稱>”沒有“att-parent”標籤，該標籤是引用連線點所必需的。

容器（子容器）將位於mesh-table中。該訊息表明容器缺少必需的att-parent標籤來指示容器中引用的網格所附著的父網格。當父網格具有別名時會發生這種情況 - 在這種情況下，CM 需要明確指定父網格。

解決方案

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

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

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

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

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

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

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

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

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

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

錯誤：紋理“<影像檔名>”載入失敗。

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

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

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

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

形式

錯誤：無法為紋理檔案“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檔案正確建立為更新的標準，並且比下面給出的更簡單替代的修復方法是僅透過更改新生成的texture.txt檔案條目來使用一個.bmp檔案。 （不過，那個“修復”會讓實驗變得毫無樂趣！使用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不會以相同的方式查詢內容，而是依賴於指定的pathspec，並且texture.txt檔案用於確保明確指定了正確的pathspec/filenamespec。當子資料夾或資產根資料夾在filename.texture.txt檔案中指定了一個檔案時。這會產生衍生錯誤效果...在Trainz 1.3--TRS2006中很容易找到的檔案突然斷開了pathspec，導致資產損壞。

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

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

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

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

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

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

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

錯誤：無法為紋理檔案“<texture filename>”載入主紋理“<image filename>”。

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

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

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

• 解決方案：使用了在修復資源時構建的資料夾 textures 庫中存檔的 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\billboardnight.im”缺少紋理“billboardnight/white flat.texture”或無法載入。

• 在這種 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 標籤”已新增到 config 中，並且影像檔案已從標籤直接引用而不是透過 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 file”的主紋理和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 位，將 Alpha 通道新增到現有的 TGA 檔案中。然後，TGA 檔名會在 texture.txt 檔案的“主紋理”和“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）的影像檔案，正如 2014 年 9 月 N3V Games 版本經理 James Moody 所強烈建議的那樣。在腳註中詳細引用的電子郵件中，J. Moody 強烈建議對所有影像格式檔案（包括 *.jpg 240x180 縮圖螢幕截圖）使用 texture.txt 檔案。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 版本簡單地忽略無效的關鍵字，從而使許多結構實際上成為了註釋）。如果它只是一條註釋，則可以將其刪除。
   
    • 指令碼使用的標籤常常利用了 TRS 版本 簡單忽略無效標籤的事實——這種處理方式應該繼續保持，因為它可以讓計算機在眨眼間完成一項任務，並避免數千使用者花費時間去“**修復程式設計師武斷行為導致的資源損壞**”——這就是為什麼需要建立此頁面！
    • 例如，一些指令碼使用標籤來提供執行編號範圍（起始和結束合法值），這些標籤通常作為配置檔案中的頂級標籤包含。這些“自定義標籤”不再允許作為頂級標籤 - 它們必須移動到“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 解決多個聲音處理問題的預期方案來說是不必要的，然後在 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”。許多其他標籤也有類似的允許值列表。如果標籤值不是允許值之一，則將報告此錯誤。

錯誤：'＆lt;container name>'中的標籤'tag name'指向不存在的檔案：'＆lt;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 的 trainz-build V2-4——SS Log Dump 柴油機， <kuid2:86661:144048:2>,在升級到 V3-7 時，來自 V2-9-SP2（TS2009-SP2 訊息）的錯誤。值得注意的是，TS12 沒有報告相同的錯誤，在匯入到 V3.1 之前沒有報告任何錯誤和警告，儘管 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 中進行排序——並且主要用於傳達人與人之間的分類通訊而不會影響軟體，現在用於定義軌道種類的許多樣條子型別。）但是，TS2009和TS2010的驗證存在不一致，無論軌道數量多少，都只允許偏移量和方向有兩個值。TS12 要求兩個列表中的專案數量正確。

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

• 給定此錯誤訊息的更新舊資源的正確方法取決於讀取配置檔案的 ContentManager 版本。Content Manager 2.0 到 Content Manager 3.3 將錯誤地給出此錯誤，這就是調整方法。此類更正需要在將資源移動到 TS12（TB V3.4 及更高版本）時重新調整。
• 理論
   • 如果要更正錯誤，則在軌道資源中刪除標籤，則資源將沒有任何“橋樑軌道
   • 列表中的專案數（以及 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 系列資料模型的早期 KIND 中，使列表中的專案數等於軌道數，並且將顯示預期的軌道數。

 

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

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

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

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

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

• 此錯誤在網格中沒有動畫的 mocrossing 種類中很常見。例如，道口可能具有閃爍的燈光，但沒有欄杆或柵欄，或者資源可能是 mocrossing 種類，因為它出於動畫之外的某些目的需要接近的火車觸發的事件。即使 config.txt 中未引用，CM 也要求 mocrossing 種類的資源存在動畫檔案。在這種情況下，任何有效的 anim.kin 檔案都可以新增到資源中以消除錯誤。可以在使用者資料中搜索合適的檔案——只需要一個有效的 .kin 檔案即可滿足 CM 的要求。

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

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

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

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

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

• 例如，allowed-categories子容器（在佇列容器內）要求在子容器中列出一種或多種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的標籤可以簡單地刪除，但是這可能取決於指令碼如何使用此標籤，因此不建議這樣做。

錯誤：無法載入聲音檔案'<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上傳驗證錯誤。

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

錯誤：過時的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”中不允許。

 

備註

解釋和詳細說明

 

腳註