[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 的工作——在這裡，我們會在認為合適的時候連結 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. 主動畫消耗了一個標記名稱，陰影網格消耗了另一個標記名稱。這種初始技術仍然會經常出現在新 Trainz 使用者檢查機車車輛時，即使子子資料夾也被用來儲存子子網格，比如門和艙口，它們會隨著動畫一起開啟和關閉，而這些動畫顯然不是主車動畫網格集。
3. 類似地，投射陰影的物體有一個用於陰影網格的子資料夾，最常見的名字是“shadow.im”。嗯，有創意，這些澳洲人！

模型中的 KIND

Trainz 數字物件沒有單一的資料模型，而是一系列廣泛的資產要求，這些要求隨著模型各部分種類繁多的變化而逐漸增長，從而導致一組資料，這些資料對內在變化和時間給予了不同的重視。請記住，最初的 Trainz 0.9 CDROM“Beta”版本是在 Y2K 執行之前釋出的，當時有些人認為計算機世界即將崩潰，並將地球再次推回石器時代。啊，哈哈。雖然這變得很有趣，但正是那些令人擔憂的日子，Auran 向世界各地眾多業餘愛好者群體發行了 Beta 版本以供評估。從本質上講，該版本定義模型資料集的方式至今仍然存在。它經歷了伸縮和蛻皮，進行了理髮，偶爾還被曬黑，但核心...仍然穩定並且在新增的一些不同資料結構中可以識別，從而為功能、容量或靈活性帶來更多便利。這些關鍵的改進功能以及 Trainz 社群在保持很大程度的向後相容性的同時提出的驅動性要求，是許多使用者儘管偶爾會對該產品感到厭煩的原因。

正在建設的定義

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

過時的標記

大多數這些標記始於原始 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 - 在歷史上幾乎所有場景、脊椎和路邊資產中都能找到。在 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 tag”（或現在的“username”標籤）的 ISO 雙字母后綴；“XX”的形式與 description-XX 一樣，是“本地化”支援其他語言的友好值的一部分。

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

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

根據慣例，子資料夾名稱將以使用者名稱/資產名稱欄位開頭，並使用_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 字串陣列將這些標籤組合到一行中。雖然在 Surveyor 中無法直接訪問，但在 TR06 和 CMP 之後，可以定義一個過濾器來選擇一個日期範圍，並使用該過濾器以及區域和型別在 Surveyor 中驗證在 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 在 Maps 中是必需的，並且自 TRS2012 以來，與標籤型別一樣，它在以前出現該標籤的大量資產中是非法的。
在 TRS2009 之後，所有將 region 標籤指定為文字字串的用法都已過時，因為在程式設計師看來，他們用 Pick List 取代了 Surveyor 工具中對“型別和區域”字串值的粗略過濾分組選擇器。這兩個標籤都具有一定的優缺點，而且這兩個標籤都可以追溯到 Trainz 0.9 Beta 版本。

type — V1.3–v2.8 — 一個以前的過濾器修飾符，在歷史上幾乎所有資產中都有出現，但尤其在機車車輛、場景、樣條、軌道型別（包括隧道和橋樑）以及路邊資產中很常見。Type 在 Trainz 0.9—TC3 版本中被用作 Surveyor 中的過濾器，它與 region 結合使用，可以顯示資產分組，而不是被放置工具選擇列表的全部列表所淹沒。這兩個標籤都預設設定為“全部”，從而顯示與 TS09 及其之後的版本中的工具所顯示的相同的大列表。

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

config.txt 檔案中的區域標籤

區域標籤，作為 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]