[e]

Trainz 資料模型

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

配置，Trainz 實用程式管理器

在所有 Trainz 版本中，資產資料夾中的老大是資產的 config.txt 檔案。在這個檔案中，每一行（實際上）包含資料對，一個“關鍵字”和一個配對的“值”。合法格式的標籤（關鍵字）和容器名稱從左邊距開始。在一個容器內，用一對大括號隔開

keyword-containername  {
       indented words and container guts
 }

後面的 & 匹配的閉合大括號需要保持平衡。習慣上，它位於第一個字母下方，並與關鍵字的第一個字母對齊。鑑於某些容器可能包含數百行，你一定會想知道我們如何仍然能夠說“每一行（實際上）包含資料對，一個“關鍵字”和一個配對的“值”。”答案既是程式性的，也是概念性的；它是程式性的，而關鍵字是一個容器名稱，它將控制權傳遞給一個處理子例程。這些處理程式知道將與該型別容器中合法關鍵字相關聯的資料放在哪裡，以及如何找到下一個非空格字元，該字元將被評估為標籤、值或大括號，然後根據需要重複，直到它找到與第一個（開啟）大括號後的括號配對的閉合括號為止。只要每個關鍵字、內部括號（是的，Matilda，存在帶有子容器的容器，以及具有可變數量子容器的容器。感謝你的提問！）是空格分隔的，並且在“預期上下文”中合法，那麼大型的佇列容器的所有子容器仍然只是第二個標準的一部分——標籤的值。在這種情況下，控制的標籤有子項，這些子項也有子項，並且它們的每一行仍然只是一個標籤，一個值。（只要稍微轉動一下你的大腦，很快你就會習慣它。別管它了 - 這個客運站的子容器中有超過 120 行文字——在容器數學中，它只是一個單一的值。<g> 只要不要在裡面輸入錯字……當你輸入錯字時，你可能會得到不止一條錯誤訊息！)

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

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

你可能知道、懷疑或聽說過 Trainz 使用各種影像檔案來紋理物件。這些檔案有不同的優勢、能力和尺寸影響，但都是成熟的型別；除了最新的 TANE 後型別，DLS 上可下載的 50 多萬個資源中 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 的工作——當我們認為合適時，我們會連結 KIND。

資料排列 1999

學習舊資料實踐是必要的。在獲取內容方面有一定經驗後，會有一些情況，某些內容對於該版本的內容管理器來說是不可接受的。關於 Trainz 社群中常用的這些情況的誤稱是稱其為錯誤、有故障的內容、修復錯誤、錯誤訊息。更準確的術語應該是過時、過時、更新、現代化和重新配置。DLS 上有一些真正糟糕的資源，但隨著 DLS 清理專案的進行，這些資源正在迅速消失，曾經的長長的清單也越來越短。

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

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

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

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

}} 但這個類比是合理的，因為所有組織連線到一個整體的所有部分的連線點都在資源的（asset-filename）根資料夾中。

1. 1. _body 以“_body”為字尾的資料夾被指定為儲存主子網格。
2. 主要動畫使用一個標籤名，陰影網格使用另一個標籤名。這種最初的技術在新的 Trainzers 檢查滾動庫存時仍然很常見，即使是子子資料夾也用於儲存子子網格，例如門和艙口，這些網格會隨著動畫一起開啟和關閉，而這些動畫顯然不是主車動畫網格集。
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 恢復之前的現狀才得以糾正：這些版本中的單軌橋樑和隧道需要第二個（且不正確的）引數用於軌道偏移和軌道方向引數，以及 enginespec

例如，大多數 TRS 時代之前的資料模型資產 (v1.0–v2.3) 可以透過在 TS 版本中新增一個網格表來替換“asset-filename”的先前被忽略的效果來進行正常工作。在 TSes 中，“asset-filename”是被忽略的。

相反，TS 版本資產通常使用 TBs v2.9 及更高版本，可以通過了解這些標籤的一些效果和用途，以及對 texture.txt 修飾符行進行一些明智的更改（例如，需要註釋掉 AlphaHint 等）來進行回溯適應，以便與早期資料模型一起工作。這些修飾符行不被早期版本理解。

asset-name、name 和 name-XX — V1.3–v2.8 — 歷史上存在於幾乎所有景觀、脊椎和路邊資產中。在 Trainz 1.x--TRS2004 Trainz 時代，Asset-name 是資產在 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 行中。雖然在 Surveyor 中無法直接訪問，但在 TR06 和 CMP 之後，可以定義一個過濾器來選擇日期範圍，並將該過濾器與區域和型別一起使用，以便在 Surveyor 的放置和選擇工具中篩選可列出的資產。在 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 — TBS V1.3–v2.8 的有效部分，作為內建過濾器和地圖資產自定義本地化識別符號 (kuid)；現在唯一合法的標籤用途是在 kind map（佈局）資產中。

請參閱當前使用此標籤的說明 config.txt 檔案中的區域標籤。

作為以前的過濾器修飾符，該標籤歷史上存在於幾乎所有較舊的資產中，但它在滾動庫存、景觀、樣條線資產、軌道型別（包括隧道和橋樑）和路邊資產中尤為普遍，這些資產具有某種程度的本地化。

地圖資產仍然保留著在對映配置中定義的關鍵字 Region，該關鍵字具有相反的用途，即作為 kind region kuid 引用。因此，Region 是地圖中必需的，並且自 TRS2012 以來，與標籤型別類似，在曾經出現過該標籤的大量資產中是非法的。
在 TRS2009 之後，任何對文字字串的 region 標籤都已過時，因為在程式設計師看來，他們用 Pick List 取代了 Surveyor 工具中“型別和區域”字串值的粗略過濾組選擇器。這兩個標籤都有一些優點和缺點，並且都追溯到 Trainz 0.9 Beta 版本。

type — V1.3–v2.8 — 以前的過濾器修飾符，歷史上存在於幾乎所有資產中，但在滾動庫存、景觀、樣條線、軌道型別（包括隧道和橋樑）和路邊資產中尤為普遍。在 Trainz 0.9—TC3 版本中，type 用作 Surveyor 中的過濾器，它與 region 相結合，給出資產組，而不是被放置工具選擇列表的全部列表所淹沒。兩者都預設為“All”，給出與 TS09 及之後版本中的工具相同的巨型列表。

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

config.txt 檔案中的區域標籤

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

現在，“region”關鍵詞的使用範圍僅限於路線圖配置檔案，在配置檔案中，它被指定為一個 KUID，指向一個預定義的“食譜”區域設定，該設定定義了各種特定於地理位置和時代的標準，例如在道路上自動生成的Trainz Carz列表，以及 carrate 值（用於確定生成的車流量和頻率），基準高度、經緯度座標以及其他可以合理地捆綁在一起的區域變數；這些關鍵詞及其用途一直保持穩定——在歷史版本和較新的TS2009-TS2012+TANE 資料模型中都有使用）。為路線提供不同氛圍的最快方法之一是指定一個不同的區域種類 KUID——陽光角度、季節外觀、地圖上的車輛都會隨之改變。

參考資料

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

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

[註釋 1]

[註釋 2]

[1]

[note 3]