[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 下載的 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 的工作——在這裡，我們將在我們認為合適的時候連結種類。

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-fileaname 被設想並實現為幾個標準子資料夾的字尾
  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 是一款實驗性產品，旨在探究是否存在市場需求。雖然 Game Company，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 才得到修復，恢復了先前的現狀：在這些版本中，單軌橋樑和隧道需要一個額外的（且不正確）引數來表示軌道偏移和軌道方向引數，以及 enginespec

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

反之，通常情況下，帶有 TBs 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 中，它與圖形開發軟體有著歷史聯絡。（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 — TBS V1.3–v2.8 中有效的內建過濾器和地圖資產自定義本地化識別符號（kuid）；現在唯一合法的標籤使用方式是在 kind map（佈局）資產中。

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

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

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

type — V1.3–v2.8 —以前的過濾器修飾符，在歷史上幾乎所有資產中都能找到，但它在滾動庫存、風景、樣條線、軌道型別（包括隧道和橋樑）以及路邊資產中尤為普遍。在 Trainz 0.9—TC3 版本中，Type 被用作測量儀中的過濾器，與 Region 相結合，提供了資產組，而不是被放置工具選擇的整個列表所淹沒。兩者都預設為“所有”，這與 TS09 及之後的工具提供的列表相同。

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

config.txt 檔案中的區域標籤

區域標籤，作為 Surveyor 快速 *按分組標籤排序過濾器* 實現的，是 Trainz 1.3 版本的一部分。在 TS2009 及其後的 Trainz 版本中，區域標籤不再是可接受的標籤，除了種類對映資源（它們仍然是 KUID 引用，而不是過濾器^{[注 3]}）。類別區域標籤，由兩個字母程式碼指定，仍在 CM 和 Surveyor 模組中用於幫助排序。

區域關鍵字現在僅限於在種類對映配置檔案中合法存在，它們被指定為預定義的 “食譜” 區域的 KUID，設定各種地理和時代特定標準，例如在道路上自動生成的 Trainz Carz 列表、決定所述 Trainz Carz 生成密度和頻率的車載率值、基礎海拔、經度和緯度座標，以及可以合理地捆綁在一起的此類區域變數；這些關鍵字及其用途一直保持穩定，無論是在歷史上還是在更新的 TS2009-TS2012+TANE 資料模型中。為路線賦予不同感覺的最快速方法之一是，指向另一個種類區域 KUID，太陽角度會改變，季節外觀也會改變，地圖上的車輛也會改變等等。

參考文獻

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

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

[註釋 1]

[注 2]

[1]

[注 3]