[e]

Trainz 資料模型

據說，如果你要四處攜帶數字位，你需要一個容器，一個帶把手的水桶，你可以抓著它四處移動並在其功能範圍內做一些事情。在 Trainz 中，在 Windows 作業系統下編寫，該水桶就是資料資料夾或目錄，所有 Trainz 版本都將其轉換為一組以樹狀層次結構排列的資料夾。
早期的 Trainz 版本在遊戲根資料夾路徑相對於遊戲根資料夾路徑的層次結構上相對嚴格。某些型別的資產被強制將資料放在特定位置，以便資產可以正常工作。好訊息是該路徑的開頭沒有被強制（指定），因此，與其將資料隱藏在 Microsoft 定義的一些架構中，深三層或四層，不如將該路徑從主硬碟的根目錄或另一個硬碟驅動器^{[註釋 1]} 開始，與許多軟體安裝不同，使用者仍然可以並且仍然可以為每個安裝的資料夾命名，她選擇的任何根路徑，只要她認為合適。

配置，Trainz 實用程式管理器

在所有 Trainz 版本中，資產資料夾中的老大是資產的 config.txt 檔案。在該檔案中，每行（原文如此）都包含資料對，一個“關鍵字”和一個配對的“值”。合法格式的標籤（關鍵字）和容器名稱以左邊的空白開始。在容器內，由配對的波浪號括起來

keyword-containername  {
       indented words and container guts
 }

尾隨的 & 匹配的閉合花括號需要平衡。慣例是將其放在第一個字母下方，並與關鍵字的第一個字母對齊。考慮到某些容器可以包含數百行，你可能會想，我們如何才能說“每一行（原文如此）都包含資料對，一個“關鍵字”和一個配對的“值”。答案既是程式性的也是概念性的；它是程式性的，關鍵字是一個容器名稱，將控制權傳遞給一個處理程式子程式。這些處理程式知道在哪裡放置與該型別容器中合法關鍵字相關聯的資料，以及如何查詢下一個非空白字元，該字元將被評估為標記、值或大括號，然後根據需要重複，直到找到與第一個（開啟）花括號後的花括號匹配的閉合大括號。只要每個關鍵字、內部花括號（是的，瑪蒂爾達，有包含子容器的容器，以及包含可變數量子容器的容器。謝謝你的提問！）是空格分隔的，並且在“預期上下文中”是合法的，一個大型長佇列容器的所有子容器仍然只是第二個標準的一部分——標籤的值。在這種情況下，控制中的標籤有子節點，這些子節點也有子節點，它們的每一行仍然只是一個標籤，一個值。（只需稍微扭轉一下你的大腦，很快你就會習慣它。別管它——那個旅客車站的那個子容器裡有 120 多行文字——在容器數學中，它只是一個單一的值。<g> 只要不要在裡面打錯字……你可能會得到不止一條錯誤訊息，如果你這樣做的話！）

從最簡單的意義上來說，所有 Trainz 資料都以文字檔案資料行上的對的形式組織，一個關鍵字告訴軟體如何處理它後面的資料。

Trainz 中的每個部分，從紋理（顏色 & 照明資源）中找到的少量配置資料到最大的路線（佈局或地圖），都必須有一個 config.txt 檔案。Trainz 的環境是在計算機內部，所以這些檔案會引用和列出其他檔案也就不足為奇了。

你可能知道、懷疑或聽說過 Trainz 使用各種影像檔案來紋理化物件。這些檔案有不同的強度、功能和大小影響，但它們是公認的型別；不包括最新的 TANE 後型別，從 DLS 下載的 500,000 多個資產中 99.99% 都依賴於.JPG 檔案、.TGA 檔案 和 Windows 自己的.BMP 檔案 的組合，現在這些都是常見的檔案型別。在這些檔案中，TGA 格式是為圖形藝術和電視的商業應用而發明的，可能最不為人所知——而且很難找到圖形編輯器來處理它。絕大多數 Trainz 紋理將在定義資產時使用 .tga 檔案。
過去是因為數字遊戲的流行需要掩蔽/透明 Alpha 通道或它們功能背後的圖層，以便與其他投影的影像混合。
有一些檔案帶有“如何使用”紋理——這些檔案帶有後綴：.texture.txt

: 所有配置檔案可能包含“任何”關鍵字和容器，它們的含義和合法資料型別在列舉中 TBS，除了大多數這些——可以在法律上跳過，這取決於列舉的種類是否需要該標籤-值對，但更多的是因為大多數 TBS 標籤更多的是為了人的方便，而不是任何模組的渲染。有一些標籤具有至關重要的意義。

在最少的情況下，所有配置檔案都包含一個數據庫資產索引/唯一識別符號
• kuid 行——KUID，
• KIND 行（kind——TBS），
• 以及一個（外部檔案）引用標籤-值對。

在給定的最小行情況下，資產預設使用原始 TBV 1.3 資產技術標準，外部引用將是資產檔名標籤——從 TRS2004 開始就已過時的標籤，會在 Trainz Classics（TBV 2.7）中觸發警告，並在 V2.9 以上（TS2009-SP0，2008 年秋季）中觸發錯誤訊息。這種“舊標籤消除”強制首先是在 V2.7/TCC 版本中出現的，在這些版本中，引擎規格、蒸汽、電力和柴油的允許標籤和容器列表發生了重大變化。

前一段話中有幾個重要教訓

Trainz 資料模型是一個不斷變化的目標。
它在任何特定時代（版本）中的確切含義取決於以前的做法，以及以前版本技術和做法中新增的新功能、關鍵字、約束、要求或方法對其的修改。
有很多標籤純粹是為了人的方便，例如作者、組織、電子郵件和國際化資料（語言翻譯），我們將其描繪為“-XX”變體，如“description-es”或“username-ru”。這些會影響排序或顯示的資訊，以便為其他使用者提供便利，但不是強制性值。

這對初學者來說是個好訊息——這意味著許多配置檔案標籤和它們的程式碼可以忽略。壞訊息是，訣竅當然在於知道哪些標籤需要忽略以及為什麼需要忽略，以及哪些組合和資料排列在一起是非法的。這就是 KIND 的工作——在這裡，我們會根據需要提供種類連結。

1999 年的資料排列

學習舊的資料實踐是必要的。在獲取內容方面擁有任何重大經驗，都會有某些東西無法被該版本的內容管理器所接受。關於在 Trainz 社群中常見的用法的錯誤說法是將這些錯誤稱為故障、有故障的內容、修復故障、錯誤訊息。更準確的說法應該是過時、過時、更新、現代化和重新配置。DLS 上確實有一些真正的錯誤資產，但隨著 DLS 清理專案的進行，這些資產正在迅速消失，曾經很長的清單正在縮短。

Trainz 資料的第一條規則是總有一個配置檔案。
第二條規則是，所有網格和網格引用的所有相關 texture.txt 檔案必須位於同一個資料夾或子資料夾中。

紋理包含兩個部分，第一個明確引用的 texture.txt 檔案中的關於它的說明，以及實際的影像檔案。
如果編輯資產，一個重要的經驗法則：如果在對資料夾執行 PEVtool Images2TGA 之後，仍然存在任何 .texture 檔案，請再次執行它以確保，然後在提交資產之前刪除 .texture 檔案。

在最古老的做法中，一個始終需要在資產中生成網格的引用標籤是“asset-filename”，它根據種類值引用影像檔案（紋理，兩種型別）或網格檔案（一個簡單的物件骨架）。除了這兩種基本型別之外，甚至不需要資產的名稱。然而，更復雜的種類需要更多的定義

Trainz 是一款國際產品，因此需要國際化功能，這些功能很容易識別，因為它們都在基本標籤“username”、“description”和
在執行時選單中顯示的物件需要影像，標準模仿了商業 3ds Max 生成的建模世界的做法，幷包含了一個子資料夾來儲存這樣的asset-filename 以及
各種高階物件需要比將額外的網格放置在子資料夾中更靈活的資料連線性。
1. 第一個網格使用 asset-filename 槽後，如何指定輔助網格？事實上，asset-filename 被設想並實現為幾個標準子資料夾的字尾
  1. 主網格 在火車車廂中，主網格（或組織網格）可以被視為底盤和結構框架。這很少可見，^{[注 2]}

}} 但類比是合理的，因為所有將所有部件連線成一個整體的連線點都在資產的 (asset-filename) 根資料夾中。

1. 1. _body 以“_body”為字尾的資料夾被指定用來儲存主子網格。
2. 主動畫消耗了一個標籤名，陰影網格消耗了另一個標籤名。這種最初的技術仍然會在許多新的 Trainzer 檢查滾動庫存時被普遍看到，甚至會使用子子資料夾來儲存子子網格，例如門和艙口，它們會隨著動畫而開啟和關閉，這些動畫顯然不是主車廂動畫網格集。
3. 類似地，投射陰影的物件有一個用於陰影網格的子資料夾，最常被命名為“shadow.im”。嗯，有創意，這些澳大利亞人！

模型中的 KIND

Trainz 數字物件沒有單一的資料模型，而是一系列廣泛的資產要求，這些要求隨著模型的不同部分而逐步發展，導致了資料集的不同重要性，賦予了內在變化和時間安排不同的重要性。考慮到最初的 Trainz 0.9 CDROM “Beta” 版本是在 Y2K 臨近時釋出的，當時有些人認為計算機世界將要崩潰，並將地球再次推入石器時代。嗯，雖然這變得很有趣，但正是在那些令人擔憂的日子裡，Auran 向他們遍佈全球的眾多愛好者團體釋出了 Beta 版本以供評估。本質上，該版本定義模型資料集的方式至今仍然存在。它已經伸展和脫落了皮膚細胞，剪了頭髮，有時還會曬傷，但核心仍然穩定，並且在新增的幾個不同的資料結構中可以識別出來，以產生更多易用性、容量或靈活性。這些關鍵的改進功能，以及 Trainz 社群在保持高度向後相容性的同時提出的驅動性請求，是許多使用者堅持使用該產品的原因，儘管偶爾會發誓。

定義正在建設中

早期的 Trainz 是一個實驗，旨在探索是否存在市場利基。因此，雖然遊戲公司 Auran 的設計師和軟體工程師認為會存在這樣的市場，但沒有人確定。結果，他們做了盡職調查，進行了研究，聯絡了許多鐵路愛好者團體，併為其專有的 JET I 遊戲引擎中的建模要求制定了一個相當不錯的規範。支援這一說法的證據是，自 Trainz 1.0 進入研究階段（現在已經超過 20 年）以來，控制和選項以及軟體在測量器模組中的功能方式已經經歷了最少的演變。

已過時的標籤

大多數這些標籤始於原始的 Trainz 版本。

以下“標籤列表”是“事實上的”，因為它們的“使用約定”早於上述列出的 TBS 標籤的正式彙編，但並非早於使用它們的規範，實際上，也早於“TrainzBaseSpec”一詞的出現（於 2008-2009 年的 TrainzOnline Wiki 中引入），或其在 N3V Wiki 頁面上的正式定義 11:32，2009 年 5 月 12 日^[1]。

編輯說明： 這些“TrainzBaseSpec 標籤”在某些情況下已由程式設計師在 TB V2.7 中棄用，在所有情況下，在 TS2009-SP0 和之後的所有N3V Games 版本中棄用 （儘管許多使用者在其中一些標籤中找到了實用性，但它會給內容創作者帶來時間上的懲罰，或者僅僅忽略那些在一個預處理操作中不再有用的標籤的能力），如果資產被開啟以進行編輯並透過將trainz-build 標籤提高到 V2.9 及更高版本資料模型來進行部分升級，就會生成錯誤（錯誤訊息）。相反，透過將 TB 值保持足夠低，不需要刪除這些標籤（至少在 TS12 之前）。

資產可以本地升級到 V2.8 及之前，並且通常可以工作，即使在經過幾代資料模型元素改進後，也可以正常執行。透過這種方式，許多資產可以與 TRS2004 或 TRS2006 資料建模一起使用，但仍與 TS 版本的內部處理和渲染相符。經驗表明，在 trainz-build 2.6（TRS2006-SP1）中使舊資產免於警告和故障，通常可以在 TS09-TS12 中無需進一步更改即可正常工作。例外情況是 TS09 中解析時引入的程式設計師錯誤，直到 TS12 才糾正，恢復了先前的現狀：這些版本中的單軌橋樑和隧道需要第二個（且不正確）引數用於軌道偏移和軌道方向引數，以及引擎規格

例如，大多數預 TRS 時代的資料模型資產（v1.0–v2.3）可以透過在 TS 版本中新增一個網格表來使它們工作，以替換 TS 中忽略的“資產檔名”的先前效果。

相反，通常帶有 TB v2.9 及更高版本的 TS 版本資產可以通過了解這些標籤的一些效果和用途以及一些明智的更改來消除 texture.txt 修飾符行（例如 AlphaHint 需要註釋掉，等等）來使其與早期資料模型一起使用，而這些行不被早期版本理解。

asset-name、name 和 name-XX — V1.3–v2.8 — 在歷史上幾乎所有風景、脊椎和路邊資產中都可以找到。Asset-name 是 Trainz 1.x--TRS2004 Trainz 時代資產的主要資料夾名稱；在當今的這些資產中，通常會發現 asset-name 也用於那個早期 Trainz 時代的資料子資料夾系統，在火車車廂資產中賦予子資料夾名稱“asset-name_art”、“asset-name_body”、“asset-name_shadow”，以及可能在其他型別資產中的其他名稱。

'name' 和 'name-XX' 是較長標籤 username 和 username-XX 的早期形式，XX 代表非英語語言翻譯的英語“name 標籤”（或當今的“username 標籤”）的 ISO 兩字母后綴；'XX' 形式與 description-XX 一樣，是其他語言使用者友好值的“本地化”支援的一部分。

如果存在，請在最舊的 Trainz 時代（v1.0-v2.4）資產中替換為 username 和 username-XX，或刪除。

注意：Username（英語）是 DLS 上的官方資產名稱，不應使用外語；它也取代並替換了“asset-filename”。

按照慣例，子資料夾名稱將具有以 username/asset-name 欄位開頭的路徑規範名稱，並使用 _art、_body 和 _shadow 字尾作為正常命名約定的組成部分。這可能是 3ds Max 和 gmax 約定延續到 Trainz 中，而 Trainz 與該圖形開發軟體具有歷史聯絡。（Gmax 與 Trainz 版本 V0.9—v2.4 捆綁在一起。）

category-era-nn — V1.3–v2.8 s.a. {tag: category-era-0, category-era-1, category-era-2, ...} — 以前的一種帶數字字尾的日期系統 — 歷史上幾乎所有可以追溯日期的資產中都可以找到，直到 Trainz-build 2.4，當時引入了當前的 category-era 字串陣列，將這些標籤組合到單個 config.txt 行中。雖然在測量器中無法直接訪問，但在 TR06 和 CMP 之後，可以定義一個過濾器來選擇日期範圍，並使用該過濾器以及區域和型別在測量器中對可在測量器放置和選擇工具中列出的資產進行驗證。在 TS09 及其之後版本中已過時，TS09 使用較短的 category-era 字串陣列位於單行中，而不是使用多個帶“-nn”字尾的標籤-值對。

字串陣列中的空格會導致錯誤；所有值必須以“s”為字尾，並具有四位數字，例如1880s；1950s；2010s（這可能完全適合某些型別進出時尚的女性服裝！）。遺憾的是，目前無法定義範圍，但使用者社群已提出請求。

替換為字串陣列型別 category-era 標籤，不帶空格，日期程式碼之間用分號隔開；這些程式碼以完整的四位數字年代數後跟一個“s”（小寫 s）字尾給出。

型別 category-region-nn — V1.3–v2.8 — 歷史上幾乎所有值得本地化的資產中都可以找到。這些已被 category-region 標籤中的兩個字母列舉的 ISO 國家程式碼的“字串陣列”所取代。

替換為字串陣列型別 category-region，不帶空格，兩個字元國家程式碼之間用分號隔開，這些程式碼在引用標籤部分中列舉；這些程式碼以完整的兩個大寫字母給出，構成列舉程式碼，程式碼之間用“;”分隔符隔開，但在最後一個程式碼之前不使用分隔符。
字串陣列中的任何空格都會導致讀取錯誤和故障訊息，包括結尾處引號之前的空格。

region — 作為內建過濾器和地圖資產自定義本地化識別符號（kuid），TBS V1.3–v2.8 中的有效部分；現在唯一的合法標籤使用方式是在 kind map（佈局）資產中。

請參見該標籤的當前用法 config.txt 檔案中的區域標籤。

作為一種之前的過濾器修飾符，該標籤在歷史上幾乎所有舊資產中都有發現，但在滾動庫存、場景、樣條資產、軌道型別（包括隧道和橋樑）以及具有一定程度本地化的軌道邊資產中尤為普遍。

地圖資產仍然保留著“Region”關鍵字，該關鍵字在 Map 配置檔案中定義，但使用方式相反——成為一個 kind region kuid 引用。因此，Region 在 Maps 中是必需的，並且從 TRS2012 開始，就像標籤型別一樣，在曾經出現過該資料的數量非常龐大的資產中是非法的。
任何將 Region 標籤與文字字串關聯的做法在 TRS2009 之後都已過時，因為在程式設計師看來，他們用 Pick List 替換了 Surveyor 工具中“型別和區域”字串值的粗略過濾組選擇器。這兩個標籤都有一些優點和缺點，並且都可追溯到 Trainz 0.9 Beta 版本。

type — V1.3–v2.8 —一種之前的過濾器修飾符，並且在歷史上幾乎所有資產中都有發現，但在滾動庫存、場景、樣條線、軌道型別（包括隧道和橋樑）以及軌道邊資產中尤為普遍。Type 在 Trainz 0.9—TC3 版本中用作 Surveyor 中的過濾器，它與 Region 結合使用，形成了資產組，而不是被放置工具選擇列表的全部內容所淹沒。兩者都預設設定為“All”，與 TS09 及更高版本中的工具提供的超級列表相同。

在 TRS2006 分支（即 TC3）之後，每個 type 標籤都已過時，因為在程式設計師看來，他們用 TS09 Pick List 替換了 Surveyor 工具中“型別和區域”的粗略過濾組選擇器。

config.txt 檔案中的 Region 標籤

Region 標籤，作為 Surveyor 的快速按分組標籤過濾器排序，是在 Trainz 中實現的，在 TS2009 及更高版本的 Trainz 版本中不再是可接受的標籤，除非在 kind map 資產中（它們仍然是 KUID 引用，而不是過濾器^{[note 3]}）。category-region 標籤，由兩位字母程式碼指定，仍然用於幫助在 CM 和 Surveyor 模組中進行排序。

Region 關鍵字現在僅限於在 kind map 配置檔案中合法存在，其中它們被指定為 KUID，指向預定義的“食譜”區域設定，該設定定義了各種地理和時代相關的標準，例如 Trainz Carz 列表，這些列表在道路上自動生成，車速值決定了所生成 Trainz Carz 的密度和頻率，基本海拔高度、緯度、經度座標以及可以合理地捆綁在一起的區域變數；這些關鍵字及其用途一直保持穩定——在歷史上以及在較新的 TS2009-TS2012+TANE 資料模型中都使用過。為路線提供不同感覺的最快速方法之一，是指向另一個 kind region KUID——太陽角度會發生變化，季節性外觀也會發生變化，地圖上的汽車會發生變化等等。

參考文獻

↑ Christoph Bergman，N3V Games 首席程式設計師，又名“Windwalkr”，KIND TrainzBaseSpec 歷史頁面。

[TBS_hist-3] Christoph Bergman，N3V Games 首席程式設計師，又名“Windwalkr”，KIND TrainzBaseSpec 歷史頁面。

[註釋 1]

[注 2]

[1]

[note 3]