[e]

Trainz 資料模型

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

配置，Trainz 實用程式管理器

在所有 Trainz 版本中，資產資料夾中的老闆是資產的 config.txt 檔案。在該檔案中，每行（sic）包含資料對，一個“關鍵字”和一個配對的“值”。合法格式的標籤（關鍵字）和容器名稱從左邊緣開始。在一個容器中，該容器由一對花括號括起來

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-fileaname 被設想並實現為幾個標準子資料夾的字尾
  1. 主網格 在火車車廂中，主要（或組織）網格可以被視覺化為底盤和結構框架。這很少能看到，^{[注 2]}

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

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

模型中的型別

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 才被修正，恢復了先前的現狀：在這些版本中，單軌橋樑和隧道需要第二個（並且不正確的）引數來指定軌道偏移和軌道方向引數，以及 enginespec

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

相反，通常 TS 版本的資產，其 TBS 版本為 v2.9 及以上，可以透過理解這些標籤的作用和使用，以及一些明智的更改來消除 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 替換，或刪除。

注意：使用者名稱（英語）是 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 版本 2.4 引入了當前的 category-era 字串陣列，將這些標籤組合到了一行 config.txt 中。雖然在 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 標籤部分.

作為以前的過濾器修飾符，該標籤歷史上發現在幾乎所有舊的資產中，但它特別常見於滾動庫存、風景、脊線資產、軌道型別（包括隧道和橋樑）以及具有某種程度的本地化的路邊資產。

地圖資產仍然保留關鍵字 Region，該關鍵字在 Map 配置檔案中定義，但用途相反 — 要成為一個 kind region kuid 引用。因此，Region 在 Maps 中是必需的，而且自從 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 檔案中的 Region 標籤

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

現在，“region”關鍵字的使用範圍僅限於種地圖配置檔案，在這些檔案中，它們被指定為 KUID，對應於預定義的“菜譜”區域設定，涵蓋了各種地理和時代特定的標準，例如，道路上自動生成的 Trainz Carz 列表，carrate 值決定了所述 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]

[note 3]