Trainz/refs/TrainzBaseSpec

Trainz 註釋參考頁 Trainz 資產維護和建立

TOC | 開始 | 樂趣 | AM&C | 建立 | 書內參考 | ORP 參考:  • 索引 • 容器 • 種類 • 標籤 | 附錄  • 版本

詞彙表

HKeys-CM

HKeys-DVR

HKeys-SUR

HKeys-WIN

滑鼠使用

符號

[e]
KIND（資產型別組） 和 容器
KIND Achievement-category  KIND Achievement-group  KIND Activity  KIND Asset-group  KIND Behavior  KIND Bogey  bogeys 容器  KIND Buildable  類庫  KIND Controlset  KIND Consist  KIND Drivercharacter  KIND Drivercommand  KIND Engine [1]  KIND Enginesound  KIND Environment  extensions 容器，或 extensions  KIND Fixedtrack  flowsize 容器  KIND Gameplaymenu  KIND Groundbrush  KIND Groundtexture  KIND Hornsound  KIND HTML-asset  KIND Industry [2]  KIND Interior  junction-vertices 容器  KIND Library [3]  kuid-table  KIND Map  KIND Mesh [4]  member-of-groups  mesh-table 容器  KIND Module  KIND MOCrossing [5]  KIND MOJunction [6]  KIND MOSignal [7]  KIND MOSpeedboard  obsolete-table  privileges  queues 容器  KIND Pantograph  KIND Product [8]  KIND Product-category [9]  KIND Profile [10]  KIND Region  season-selector 容器  KIND Scenariobehavior  KIND Scenery[11]  KIND Scenery-Trackside[12]  KIND SceneryWithTrack [13]  script-include-table 容器 (TBS)  KIND Servlet  smoke 容器  KIND Steam-engine [14]  KIND Texture [15]  KIND Texture-group  thumbnails 容器，或 (TBS)  KIND Track [16]  track-lod-tree 容器  KIND Tracksound [17]  KIND Traincar [18]  KIND TrainzBaseSpec [19]  KIND Turntable  volume 容器  KIND Water2

KIND 層級結構簡介

KIND TrainzBaseSpec 為所有 Trainz 資產型別在所有 config.txt ini 檔案 中提供基礎定義。TBS 提供了一些“標準標籤”，這些標籤對所有 Trainz 資產（至少在法律上）都適用。 。

• 其中一些是強制性的，因為它們決定了資產的進一步處理以及 config.txt 檔案和其資料夾中的資產資料的解釋。
• 然而，大多數是可選的，並且在大多數子資產中可以省略使用標籤的定義行。

父類

• 無，對於所有由事實上的父容器定義的內容有效且大部分必要，即 config.txt 檔案，所有 Trainz 數字模型都需要該檔案。KIND TrainzBaseSpec (TBS) 是一個根類，其他 Trainz 資產類都源自該類。

• 之所以說它們是派生的，是因為它們繼承了處理屬性（指令）和引數中定義的值，其中最關鍵的是 kind 標籤的值。該列舉詞決定了資產的特定 種類宣告和要求，這些宣告和要求將新增到該資產的配置檔案中 TBS 的定義中。其他關鍵 TBS 定義的資料具有明顯的意義和實用性，例如資產的名稱、Kuid 識別符號和版本、Trainz 構建值 (TBV) 以及其他定義、適用性和範圍廣泛可變的項，例如字串表、過時表、kuid 表和縮圖影像都是偶然的。即使是資產名稱和描述，字串值在實踐中也大多完全不必要且可以完全省略。

• 當宣告一種型別時，該型別就成為父類，要求並指示必須在該類中滿足的必要資料對，此外還有 TBS 中列出的那些資料。

• 在某個資產型別的案例中，某些引數可能保持未定義，特別是對於較老的 Trainz 構建標籤值來說，這是一種常見的做法，對於這些值，內容管理器或 內容建立者 Plus (CCP) 實用程式將分配一個預設值，但在處理時列出警告訊息。TrainzOnline wiki 中的許多標籤，這裡或舊的 TC3 時代 內容建立者指南 (CCG 將提到一個預設值。

• 從 TRS2006 和 Trainz Classics (TC1&2) 開始，每個版本的 Content Manager 模組都會施加越來越多的預先承諾錯誤測試，並且每個模組都變得越來越堅持要求警告該標籤尚未在預期標籤 - 資料對中定義。

在 TANE 之後的版本中，許多這些“昨天已預設”的定義行今天將更常生成錯誤，要求明確的數值定義，而這些數值在過去的載入中是預設的。 這種煩人的事情比以前好得多，因為在以前，錯誤的資產定義有時會導致臭名昭著的“藍色畫面宕機”或更常見的是將執行時軟體崩潰到桌面，從而導致編輯丟失，並可能需要重建資料庫。

子類

所有 Trainz 定義的資料（內容）都有三個必需的元素：一個 config.txt 檔案 用於組織資料，一個標識，即 kuid（只有使用者名稱是不行的，但是可以建立合法的資產，而無需名稱！）以及最後，一個合法定義的種類標籤。種類是負責的，是管絃樂隊的指揮，是排長或 CEO 發出指示——為在之後處理的所有內容設定要求。簡而言之，種類的值，一個由精心定義的成員組成的精選緊湊組——告訴 Trainz 軟體要呈現和顯示什麼以及如何在我們建立的虛擬世界中顯示（或在哪裡）查詢其他部分，以使那些部分在該 config.txt 檔案中連結在一起。
  以下每個子類都被認為具有 TrainzBaseSpec 作為它們的資料“父類”。 下面列出的幾種型別，那些帶下劃線的型別，是遺留型別，早於 TS2009 版本中對 Trainz 資料模型 的更改（即自 2008 年後期以來），N3V 程式設計師僅對模型施加了逐漸的（增量的）更改。
  目前可以在 N3V Trainz Wiki TrainzOnline 站點這裡 的 內容建立者指南 部分找到基於這些遺留型別的修復資產的詳細資訊，並帶有啟示性的 遺留型別的示例這裡。強烈建議所有使用 Trainz 下載站 的使用者或任何考慮建立內容的使用者仔細閱讀 CCG。從理解舊內容定義方式的歷史背景中獲得的見解，可以與 TrainzOnline 對相同資料型別的當前覆蓋範圍進行對比和比較，因為通常這種當時與現在的對比可以為修復、更改和自定義資產提供有價值的見解。更重要的是，CCG 中的寫作是專業製作的，並且更富含 tautological——它經常會讓你瞭解如果更改了某項內容的擴充套件影響，而 Trainz Wiki 卻沒有提供。TrainzOnline 上的 CCG 是 TC1&2/TC3 版本——是自 1999 年 Trainz 以來出版的幾本小冊子的最後一個版本；TC3 CCG 包含 TRS2004/TRS2006 和 UTC 資料模型中需要正確更新的已更改的引擎規範機車資產。

TrainzBaseSpec 子類 KINDs（型別資產組）
kind achievement-category  kind achievement-group  kind activity - 場景 型別  kind asset-group  kind behavior  kind bogey []  kind buildable  kind controlset  kind consist  kind drivercharacter  kind drivercommand  kind engine [20]  kind enginesound []  kind environment  kind fixedtrack []  kind gameplaymenu  kind groundbrush - 未定義  kind groundtexture []	kind hornsound []  kind html-asset []  kind industry [21]  kind interior  kind library [22]  類庫  kind map - 路線 型別  kind mesh [23]  kind module - 未定義  kind mocrossing [24]  kind mojunction [25]  kind mosignal [26]  kind mospeedboard  kind pantograph  kind product [27]  kind product-category [28]  kind profile [29] - 會話 型別  kind region	kind scenariobehavior - 未定義  kind scenery[30]  kind scenery-trackside[31]  kind scenerywithtrack [32]  kind servlet  kind steam-engine [33]  kind texture [34]  kind texture-group  kind track [35]  kind trainzbasespec [36]  kind tracksound [37]  kind traincar [38]  kind turntable  kind water2

 

表 I，TBS 標準定義

TBS 標準定義

這些標籤和容器是標準定義，幾乎所有資產中都會出現。 一些標籤是可選的，可能不會被內容創作者定義，因為這是他們的選擇。 標籤是關鍵字，並且具有單個分配的鍵值或容器，例如字串陣列或'{' ... '}' 繫結封閉的標籤值對或子容器。（Trainz 配置檔案中宣告的所有內容都是成對出現的，即使 '{' ... '}' 也被認為是一個 '鍵值'.

• 容器是'鍵' 和 '鍵值' 對的集合以及 TBS 中的 '上層容器'（與子容器相反，例如縮圖容器中的那些）通常以 '-table' 結尾。

kind	"'字串值'"
trainz-build	'浮點數'，一位小數
kuid	<Kuid 編碼值>
username	username "'字串值'"
username-XX	username-XX "'字串值'"
description	description "'字串值'"
description-XX	description-XX "'字串值'"
kuid-table (容器)   { 依賴項列表   按 kuids }	一個鍵值表，列出此資產依賴的所有資產。
obsolete-table (容器)     {     }	kuids 列出此資產替換的 (使過時的) 資產  通常沒有 (空)
string-table (容器)     {     }	資產中使用的字串和訊息的鍵值列表 通常為空，在路線和場景中很大。
string-table (容器[s])     {  非英語     語言文字 }	翻譯後的字串列表 匹配到 必須的英語 string-table
category-region 標籤 列舉 程式碼	category-region "'字串陣列'"
category-class 標籤	category-class "'列舉 字串值'"
category-era 標籤	category-era "'約束字串陣列'"  年代
category-keyword "'字串陣列'" 最大長度為 64 位元組	category-keyword 標籤 自然語言搜尋關鍵字   (替換型別，地區)
custom-category-list   "'字串陣列'"	指令碼介面功能
must-have-product-rights   "'字串值'"	DRM 字串陣列
must-not-have-product-rights   "'字串值'"	DRM 字串陣列
privileges (容器)     {     }	更多 DRM
thumbnails (容器)     {     }	縮圖容器
script (檔名)	"'字串值'"
class (指令碼資產類)	"'字串值'"，必須與 script 規範類同步。
script-include-table     {     }	(列出庫指令碼的容器)
extensions (容器)     {     }	資產也使用的正式指令碼擴充套件
license "'字串值'"	資產建立者的版權宣告
author	"身份 '字串值'"
organisation	"第三方組身份 '字串值'"
contact-email	"電子郵件地址 '字串值'"
contact-website	"作者/組的網站 URL '字串值'"
member-of-groups (容器)     {     }	此資產所屬的 KIND Asset-group 資產列表。

 

支援的標籤

TrainzBaseSpec 在 config.txt 檔案 中支援以下標籤。 ∅:  

kind 標籤

型別：字串。

欄位定義：此 config.txt 檔案 代表的資產型別。 請參閱索引 Kinds 和列表：此處（上方）

 

kuid 標籤

型別：KUID（簡短），主要：KUIDs

欄位定義：引用此資產的唯一資產 ID。

KUID

'Koolthingz Unique IDentifier'. Trainz 系統軟體的唯一資料庫引用號，擴充套件到 KUID2 形式中跟蹤多個版本。 Trainz 可升級性和資產模組化設計的核心，因為每個資產都有自己的唯一 kuid 程式碼，因此可以指定一個元件（轉向架）或來自另一個的整個車廂，並在新的資產（重新貼皮或改裝卡車）中選擇性地替換任一者。

• 基本 KUID 格式：'<kuid:wwwwww:xxxxxx>'，其中 wwwwww 是作者的“唯一 Trainz 身份”，xxxxxx 代表作者分配的模型標識程式碼。

編輯注： 請注意，許多線上網站需要使用單獨的資料欄位（作者和序列號）進行搜尋，而內容管理器將需要三個或四個冒號分隔的資料欄位，但不需要方括號 - 雖然逗號是搜尋 API 視窗中多個 kuid 的必需分隔符。通常，在完整的 kuid 標籤結尾括號中聚合資料更容易，而且通常更容易閱讀。對於貼上大量的列表，緩衝區大小限制可能會中斷列表的末尾，在這種情況下，在文字編輯器中修剪兩個結束括號可能會允許將整個列表放入 API 中。

• 大多數 Trainz 資源在其 kuid 表 中指定了依賴項列表 - 其他元件資源，由軟體套件的各個部分組裝，以構成 kuid 表容器 中的可渲染和可用的資源。
• 在許多資源的核心，特定的標籤可以由kuid 引用定義，並使用引用的資源作為一部分。這實際上是如何實現重繪的，並且可以在資源中使用網格，儘管更現代的做法建議這種引用應指向網格庫資源。

KUID2

KUID 格式的更新和更新跟蹤修改版本，允許指定版本號。<kuid:xxx:yyy> 等同於 <kuid2:xxx:yyy:0>（零修訂或版本零，表示原始版本）

• 這允許資料項（Trainz 資源）攜帶資源的固有版本程式碼。這通常與 CM Trainz 版本程式碼 不匹配，該程式碼標識軟體技術級別，但指示先前版本的歷史記錄。
• 在資料庫中，具有較高字尾程式碼的 KUID2 資源將覆蓋或替換較舊的資源。擁有早期版本不是必需的，但 CM 會將缺失的修訂鏈列為缺失的依賴項，對於那些討厭 CM 中該功能的汙染或程式設計師保持原樣的人來說，這是一個軟體錯誤，無論如何，它降低了使用 CM 來識別使用者缺少什麼的功能，並導致使用者花費時間手動找出真正是什麼。

 

trainz-build 標籤

主要內容：trainz-build 標籤，縮寫：TB & TBV（TB 值）∅

型別：小數點後一位浮點數，由 N3V 列舉，用於跟蹤和識別與進化軟體技術級別相對應的資料型別。

範圍：1.0–4.3，直接對應（'對映onto^3rd' Trainz 1.0—TANE-SP1+hf2；預計此值將隨著每次主要軟體升級以 0.1 的增量向上爬升。）

每個合法值必須與釋出的 Trainz 版本號 完全匹配，但以下情況除外

• 分配給 V1.4 的 TBV 或版本值是 Auran 的 Paintshed 版本，這是一個重繪工具，也適用於 Microsoft Trainz Simulator (MSTS)，並且也作為 TRS2004 輔助軟體模組的版本值出現；具體來說是它的 ContentManager.exe 工具。
• 1.7 和 2.0 之間的差距要麼是外語版本，要麼正如經過數小時的挖掘和研究後看起來更像那樣，Auran 未使用，因為在構建原始 Trainz 的程式設計師團隊看來，TRS2004 版本是第二款 Trainz 產品，無論前端辦公室如何炒作營銷名稱（比如 Trainz UTC，是終極的什麼東西...... 認真嗎？。來吧，夥計！認真嗎？！）

Trainz 版本和相應的 Trainz-build 標籤 值的系列是 Trainz 1.0=v1.0，Trainz 1+SP1 ⇒ V1.1，Trainz 1.0+SP2 ⇒ V1.2，Trainz 1+SP3 ⇒ V1.3，等等（但跳過 1.4 和 1.7–1.9），所以 TRS2004-SP0 = v2.0 然後遞增，其中每個版本從 2.0（TRS2004 無服務包）開始遞增 0.1 到當前版本（v3.7 = TS12-SP1，v3.8 = Mac2，3.9=TANE-CE，4.0—4.3 以及從 2016 年 3 月起，4.3 及以上版本是 TANE SP，待定）。

• 從 v2.0 (TRS2004) 開始，Trainz-build 標籤數值已透過 23 個步驟遞增，這些步驟雖然不是單調的，但卻是連續的，因為 Trainz TS09-sp3—TS09-sp4 共享一些 Trainz 版本 值；也就是說，TS2009 和 TS2010 的聯合開發時代和版本中，有一些共同的 TBV 重疊。
• 此外，N3V 進軍 Macintosh 電腦，打斷了基於 Windows 的 Trainz 版本中 TBV 的平滑遞增，3.4、3.5、3.6、3.7 和 3.8 在基於 Windows 和 Mac 的作業系統之間相互交織。
  注意： 熱修復 不更改版本號。

欄位定義：此資源構建（並存檔）到的檔案格式版本，不一定與資源使用的技術級別有任何關係，但對應於在 Content Creator Plus 中建立資源時分配的資源級別 - 與 CM 的標題欄中找到的級別相同。

• 程式設計師建議此數字通常應設定為建立和測試資源的 Trainz 安裝的 Trainz 版本號。相比之下，內容建立者社群試圖將此數字設定得儘可能低，以便在下載時為新資源提供儘可能廣泛的受眾/使用者範圍。更好的內容建立者將在裸機安裝（無附加內容）的相應版本上測試它，並驗證生成的 cdp 包含所有相關材料。
• 某些資源型別根據其trainz-build 版本標籤的解析方式有很大不同。注意：trainz-build 標籤 是強制性的。如果未指定，Trainz 將嘗試根據 config.txt 檔案 的內容，以原始 Trainz 版本進行猜測，這通常將解析為 1.3 作為 TBV。

 

使用者名稱標籤

型別：UTF-8 字串，資源的使用者名稱，強制性規範。

欄位定義：此資源的英語人類可見名稱。

在 TC1&2（v2.7）之後的 trainz 版本中，使用者名稱在編輯資源時也成為作業系統資料夾名稱，並且資原始檔名被忽略，而在 v2-6 配置檔案中，它具有優先順序。根據 N3V Games 的 TBS 標準，此欄位絕不應包含非英語文字，除非資源名稱是專有名詞（例如，地名）且沒有英語本地化變體。此值是每個人通常搜尋和記住的資料，因此建議保持清晰的名稱。

建立資源時，強烈建議您在 CM 搜尋中針對幾個試用部分名稱驗證新建議的名稱，並根據這些知識採用與現有可用內容合理匹配的名稱。 我們需要忍受多少個“house 2”或“road”資源來進一步混淆我們！？好吧，實際上，我們都會搜尋“house”，然後從影像中選擇，但能夠指定一個唯一的名稱並獲得您預期的東西真是太棒了！

 
 

使用者名稱-XX 標籤

型別：UTF-8 字串，使用者名稱標籤 的替代語言版本。

欄位定義：（其中XX 被相應本地化程式碼 替換，以表示正在使用的語言。）此資源的本地化人類可見名稱。此欄位類似於使用者名稱欄位，只是表示非英語區域設定。資源中可能存在多個使用者名稱-XX 標籤，每個支援的區域設定一個。如果不存在適當的“使用者名稱-XX”標籤來在給定的終端使用者系統上表示此資源，則改用英語使用者名稱標籤。

 

描述標籤

型別: UTF-8 多行字串，提供對資產的清晰語言描述。

欄位定義: 此資產的英文人機可讀描述性摘要。

該描述在內容管理器“資產詳細資訊”窗格中可見，用於闡明資產名稱，提供規格，通常還提供一些歷史資訊。

N3V 的 Chris Bergmann 表示，此欄位應保持簡短（1-2 段）描述資產，並透過info-url 頁面提供擴充套件詳細資訊，但可以容忍相當長的文字塊。有些人將該塊的底部用作版本變更記錄。

此欄位必須由英文描述性文字組成，儘管該文字可能會引用非英文專有名詞，如其他地方所述。其他語言翻譯或源文字應放在許多可能的替代語言本地化標籤之一中（請參閱description-xx 標籤）。 

description-XX 標籤

型別: UTF-8 多行字串，description 標籤。

欄位定義:（其中XX 被替換為所代表語言的適當本地化程式碼。）此資產的本地化人機可讀描述性摘要。此欄位類似於description 欄位，只是它代表非英文語言環境。一個資產中可能存在多個description-XX 標籤，每個支援的語言環境一個。如果在給定的終端使用者系統上不存在適當的“description-XX”標籤來表示此資產，則使用英文description 標籤。

 

string-table 容器

型別: UTF-8 字串列表容器，String-table 容器。

欄位定義: 一個包含英文字串的鍵值列表。每個鍵都是一個有意義的指令碼識別符號，對映到二進位制資料並由其引用。每個值都是一個英文字串。英文字串可能包含或引用非英文專有名詞作為識別符號。由非英語母語的作者編寫的資產必須仍然建立一個沒有後綴的 string-table 容器（如果需要的話）。軟體只連結到沒有後綴的 string-table 容器中的名稱和值並引用它們，這將讓西班牙語、法語、德語、捷克語、荷蘭語...日語作者感到非常沮喪。換句話說，帶字尾的 string-table 僅用於翻譯目的，這在路線用非英語編寫時會造成問題——沒有 string-table-en 來提供用於反向翻譯的表格。同樣，username-en 和 description-en 也是如此。這三種缺失都證明了對世界動態的一種過時且傲慢的無視。

  其他語言透過類似的 string-table（例如 string-table-XX）支援，帶有一個與 description 和 username 關鍵字/標籤的國際化字尾相匹配的本地化程式碼字尾（XX），但這些語言鍵值的 string-table 容器將始終具有相同的左手條目鍵值。 

• 這些左手鍵或標籤既用作“本地索引關鍵字”，又用作語言之間的“等效表”。
• 左側列將始終包含內容建立者賦予“特殊”名稱的物件，例如訊號、軌道標誌和工業、連線點等的名稱，這些名稱可能被引用，並且會出現在 Driver 和 Surveyor 模組的“查詢工具”（CTRL+F ) 函式小程式中。
• 另一方面，索引側也不會列出諸如連線點等地方的預設名稱，這些連線點在構建路線圖時由隨機數自動索引（即毫無意義的混亂。如果重要，路線構建 CC 將對其命名！），但會自動包含可能臨時資產，例如火車車的預設名稱。如果重新命名，這些名稱將取代其相應的預設名稱。
• 它主要用於那些旨在與指令碼引用互動並接受可變屬性的物件，例如火車站或工業所需的或準備在工業中裝運的產品數量，或由互動式火車車（滾動式工業到指令碼）和其他可配置資產攜帶的資產，以及像通用廣告牌式標誌一樣簡單的可配置資產，透過調整高度和角度扭曲，可以將其放置在庫存建築或工業的正面，以便在建築物上放置不同的公司名稱。換句話說，這是一種可配置的佈景。
• 總的來說，在路線地圖或佈局中，這些 LHS 名稱對應於地圖資產上的命名物件，這也是大多數 string table 被看到的地方（從字面上看，一個大型路線kind map 中的數千個條目填充了它們）。

• 在某些資產中，該預設名稱被掛鉤到軟體指令碼，因此 string-table 變得特別重要，而不是索然無味。（見下文）

• 使用 string-table 型別在所有型別的資產中都是合法的，就像 description 標籤和 trainz-build 和 kind 標籤一樣。與這些標籤不同，它不必存在或被定義，而且它絕不是強制性的。封裝在 string-table 容器中的值除非程式碼期望它們匹配，否則沒有任何功能或效果。

• 在其他資產中，例如以那個假設的可程式設計商業標誌為例，如果要與軟體互動，string table 必須有預設名稱。所有地圖可放置資產都可以命名或重新命名，但“特殊名稱”必須與指令碼和 string table 索引值匹配。大多數可配置資產定義一個介面變數，用於將預設名稱替換為指令碼引用的索引或查詢表，以及資產的二進位制資料。其他變數也可能會在可程式設計資產中定義。這些變數中的每一個都可能被指令碼引用，但正是索引值使它進入地圖或會話 string-table，當需要 Driver 或 Session 建立者可變性時，所有內容都能協同工作。

• 相反，如果沒有系統軟體知道索引中命名的專案的地址，則該物件的指令碼可能不會觸發、執行條件檢查或能夠更新。這是 2000 年代Trainz 1.0 中物件的特徵，自 2003 年釋出的TRS2004 以來，不是更現代的 Trainz 鐵路模擬器。（從那時起，我們已經取得了長足的進步！）
• 有些資產只能作為一組一起工作。在這種情況下，在對映或會話層中對每個資產進行命名可以使它們協同工作。例如，考慮一個有五個軌道的公路平交道，其中兩個是連線點，與透過軌道形成所謂的“交叉交叉點”。如何設定訊號，以便任何鐵路交通都能關閉公路閘門，或者，如何使用交叉交叉點來禁止其他列車透過正在穿越交叉點的列車？道路和鐵路訊號以及道岔和閘門都必須協同工作。string-table 匹配的某些“ATLS 系統”資產及其指令碼可以使這個複雜的系統正常執行。
• 有關更多資訊，請參閱 string-table-XX。

 

string-table-XX 容器

型別: UTF-8 字串列表容器，本地化 string-table，每個字尾對應除英語以外的語言。

欄位定義:（其中XX 被替換為所代表語言的適當本地化程式碼。）此欄位類似於string-table 欄位，只是它代表非英文語言環境。

英文 string-table（無後綴）是強制性的，其他本地化語言是可選的，由資產作者決定。提交到 DLS 然後在與 Trainz 版本捆綁在一起的路線中使用的許多資產通常會被翻譯，並且會有一套完整的本地化翻譯，用於 description-XX 和 string-table。特別是，與版本捆綁在一起的路線和會話在每次零售版本釋出時都會被專業翻譯成多種語言。

請注意，字串表格的左側列是相同的，因為它是一個對映的符號表，並索引到二進位制資料，例如網格、會話或路線檔案。只有使用名稱，兩個元素的右側或資料元素是本地化的，並由執行時本地化軟體替換。如果需要，即使在英文字串表中，也可以手動編輯這些名稱以使其更易於使用者理解。索引或左側引用列語法在任何方面都不能更改，因此在資料列中更改名稱時要小心全域性 SAR 規範。

資產中可能存在多個 string-table-XX 標籤，每個支援的語言一個。每個標籤都應包含一個字串列表，該列表與 string-table 列表中的鍵相同，但值不同。如果不存在適當的 'string-table-XX' 標籤來表示給定終端使用者系統上的此資產，或者該列表中缺少適當的字串，則將引用英文 string-table 容器。 

kuid-table 容器

kuid-table   {
 numberit_library                      <kuid2:75134:99003:7>
 0                                     <kuid:-3:10164>
 1                                     <kuid:-1:42004201>
 2                                     <kuid2:50567:11155:1>
 3                                     <kuid2:58422:50120:1>
 4                                     <kuid:-3:10003>
 5                                     <kuid2:30671:94407101:1>
 6                                     <kuid2:87907:94407101:1>
 7                                     <kuid2:87907:94407103:1>
 8                                     <kuid2:87907:94407105:1>
 9                                     <kuid2:30671:9870190:1>
 10                                    <kuid2:30671:94407100:1>
 11                                    <kuid2:87907:94407100:1>
 12                                    <kuid2:87907:94407102:1>
 13                                    <kuid2:87907:94407104:1>
 14                                    <kuid:-3:10013>
 15                                    <kuid2:60318:10008:1>
 16                                    <kuid2:60318:10010:2>
 17                                    <kuid2:189041:301:1>
 18                                    <kuid2:50567:11121:1>
 19                                    <kuid2:30671:9840820:1>
 20                                    <kuid2:30671:9870899:1>
 21                                    <kuid2:50567:12646:3>
 22                                    <kuid2:124017:30000:2>
 23                                    <kuid2:124017:30001:2>
 24                                    <kuid2:124017:30002:2>
 25                                    <kuid2:124017:30003:2>
 lodi_icon                             <kuid2:124017:35000:1>
 lodi_lib                              <kuid2:124017:40000:1>
 26                                    <kuid2:30671:69006:1>
 27                                    <kuid2:124017:35000:1>
 28                                    <kuid2:30671:90810901:1>
 29                                    <kuid2:30671:9081290:1>
 30                                    <kuid2:60318:10009:1>
}

型別： KUID 列表容器，與 已過時表格容器 （下面）格式相同。一個 虛擬引數 + 一個 (依賴) kuid

欄位定義： 指定此資產依賴的資產列表的鍵值分隔。

 

通常

只有具有子元件或備選選擇（貨物）的資產才會有長度可觀的 kuid-table。大多數具有子元件的資產只有幾個。

• 其次，存在一種約定，因為它有時內部關鍵字是“自動定義的”——僅僅列為一個數字，沒有名稱，作為 佔位符引數，偽關鍵字可以是任何唯一值（通常是零索引順序整數。）使用者或作者可以根據需要為它們命名或不命名。
• 此表中的條目有兩個目的
  ‌ 首先：確保遊戲系統知道依賴關係，以便安裝和載入此資產將成功安裝和載入任何依賴關係，以及
  ‌ 其次：允許指令碼定位相關的子資產。
• kuid-table 中只應包含第一級依賴關係——具有自身依賴關係的子資產或零件資產將在該子資產的驗證和資料庫提交中處理。
• 迴圈依賴關係是非法的。
• 如果某個資產也標記為此資產的已過時版本，則該資產不能列為依賴關係。（Trainz 資產索引（歷史上是 assets.tdx 檔案）中只有一個替換 kuid 槽，這將建立一個迴圈定義，需要它自己的舊版本！）
• 同樣，資產不能列為自身依賴關係。[另一方面，這已經體驗過（即在 TSxx CM 中已成功提交且沒有錯誤的資產）在安裝之間移植地圖和會話，使用 GSARS 更改 kuid，以便重疊不會覆蓋已經使用相同 kuid 的資產在目標安裝上，而不會看到錯誤訊息。] 是否它也需要比我更勇敢或更愚蠢的人！--Fabartus，編。

格式 (所有值都採用 <kuid:aaaaa.bbbbb> 格式)

kuid-table {
 0            Kuid-1
 1            Kuid-2
 3            Kuid-3
 ...          kuid-ii
 N-1          Kuid-N
 }

大多數使用者首先的內容將是自動克隆一個內建路線及其關聯的會話。通常是因為人們想要修改某些東西。檢查路線或會話的 kuid-table 將使新手或老手 Trainzer 擁有路線中資產的可編輯列表。這些可以很容易地轉換為樣式表“過濾器”（一個選擇列表），它允許一個人使用與原始作者相同的資產來新增和更改路線……或者在你自己的擴充套件中複製他的樣式。

• 利用這些是虛擬引數的事實的一個非常有用的方法是將複雜滾動庫存資產中產品的 kuid 配對。一個貨車可能包含各種產品……獲得允許將你的作者 ID 分配給你的自己的系列，並使用不同的負載集，這可能是你建立的第一個重要的內容！考慮一輛貨車，允許的產品容器，kuid 列表可能包含以下條目

...  {

Animal_chickens		<kuid:-25:230>

Animal_Horses		<kuid:-25:236>

Animal_Cows		<kuid:-25:239>

Animal_Piggies		<kuid:-25:238>

Animal_Sheep_Flock	<kuid:-25:240>

} ... 

請注意下劃線連線了單詞……兩個符號，鍵和值！我們讓學生弄清楚在哪裡將 kuid 新增到負載和允許的產品隊列表條目。（歡迎你，但這是一個更改名稱的好理由！保持事情井井有條几乎是製作資產的全部戰鬥！） 

obsolete-table 容器

型別： KUID 列表容器，與 Kuid-table 容器 格式相同。

欄位定義： 一個“佔位符鍵-鍵值”列表，該列表包含被此資產標記為已過時的資產。任何嘗試載入此列表中的任何資產都將導致載入此資產。

• 此外：兩個資產都將第三個資產標記為已過時是非法的，除非兩個資產之一也將另一個標記為已過時。
• 迴圈過時引用是非法的。
• 所有低編號的 KUID2 版本都將隱含地視為已過時，無需包含在此列表中。同時，更新的改進資產（具有更高的 Kuid2）及其前身之一永遠不應將同一個前身（例如，原始！）列入“中間”中間前身——因為這些值用作 替換條目表，並且只有一個資產可以替換較早的版本。（陣列只能容納一個值，不能用兩個替換一個！）
• 將此資產的更高編號的 KUID2 版本標記為已過時是非法的，因為這會建立一個隱式的迴圈引用。
• 此列表中引用的資產必須與此資產具有相同的建立者，才能透過 DLS 上傳過程進行稽核和接受，此限制不適用於你的本地版本，例如，它可能用於將一大批 Traincars 上的所有舊紙質車輪 kuid 替換為一個圖形更精美、更新的車輪 kuid。

 

category-region 標籤

目的：CM 和 Surveyor 中的過濾器（搜尋標準）

型別： 列舉字串或字串陣列。

欄位定義： 一個以分號 (;) 分隔的兩位數 category-region 標籤 程式碼列表。字串中不應包含其他字元（包括空格等）。此資產被認為與每個指定的區域相關——這與 kind traincar 和 kind mosignal 資產最為相關，但可以為任何資產提供。

示例

category-region "CA;US"

category-region "CA;MX;US"（北美國家，加拿大、墨西哥、美國）

category-region "CA;CS;DE;MX;US;VE;AU;FR;IN;IT;JP;KR;ES;AR;AT;BE;CH;DK;IE;EE;NL; NO;NZ;PA;PL;PR;PT;RO;RU;SE;SK;UA;UK"（大多數第一世界國家）

 

category-class 標籤

目的：CM 和 Surveyor 中的過濾器（搜尋標準）；與 KIND 宣告一起確定 CM 軟體如何處理資產，以及 Surveyor 在哪裡列出它。

型別： 列舉字串。

欄位定義： 一個單一的 2-3 個字元的 category-class 程式碼，用於描述此內容項。category-class 標籤用於提供超出資產種類隱含內容的額外人工子分類。每個 Trainz 資產的 category-class 標籤有助於描述資產在遊戲中的“意圖”，而不是資產的內部結構。

TRS2006 和 Trainz Classics 的 內容建立者指南 (CCG) 解釋了這些類別代表了一種標準化系統，用於指代各種型別的機車、車輛、景觀、樣條線和工業資產。當搜尋和/或過濾適合的資產以在會話或路線（佈局）中建立內容時，類別分類程式碼對所有 Trainzers 來說都變得很重要。

 

請注意，許多類別程式碼只與特定的資產種類相關 - 類別程式碼不應用於不合適的種類資產。

示例

	類別程式碼 "XBG"	盒式貨車 - 來自 PRR 60'
	類別程式碼 "BR"	鐵路（景觀非功能性） - 也許是一座建築物
	類別程式碼 "BIN"	具有產品處理功能的工業資產

 

category-era 標籤

目的：CM 和 Surveyor 中的過濾器（搜尋標準）

型別： 列舉格式字串陣列。

欄位定義： 一個由五個字元的 時代程式碼 組成，以 分號 (';') 分隔。

• 每個時代程式碼代表一個十年，由一個四位數字組成，然後 必須是 's' 結尾 (例如 "1990s;2000s;2010s"), 從而建立一個列舉的軟體令牌 (值)，它必須與指定的合法 時代程式碼 完全匹配。
• 字串中不應該存在其他字元（包括空格等），包括（尤其是在字串末尾）在終止雙引號字元之前。
• 允許的年份範圍是 1800-2010s
• 此資產對其他人的唯一意義在於，此資產被認為在指定的時代範圍內有效且相關，並且 內容管理器 將接受指定適用年份的搜尋過濾器。

 

示例

category-era              "1920s;1930s;1940s;1950s"

 

縮圖容器

目的：CM 和 Surveyor 中的過濾器（搜尋標準）

型別： 縮圖容器。

欄位定義： 用於在整個遊戲環境中（包括遊戲內、內容管理器 和 下載站）的 2D 預覽框、列表和圖示形式中代表此資產的縮圖。每個資料集都包含在一個子容器中（通常）使用 佔位符引數 作為鍵名或標籤。 慣例使這些成為 0 索引的整數，但該值可以是任何可以作為 字串 評估的非空文字值。（參見下面的第二個示例）

一個實際的例子

(來自資產修復編輯)

thumbnails {
	0 {
		width					240
		height					180
		image					"$Screenshot (240)(kuid 68787 25222).jpg"
	}
	1 {
		width					512
		height					512
		image					"$Screenshot (512)(kuid 68787 25222).jpg"
	}
}

另一個常見尺寸是在 調車場 和測量員資產選擇 API 中使用的 128x64 '圖示'，它應該有一個 Alpha 遮罩 或一個非常淺的背景。許多舊的資產沒有使用 jpg 檔案，而是列出了 _art 子資料夾中的 .tga 檔案（Targa 真彩色）（Trainz 1.0 - TC3 慣例：_art、_body 和 _shadow 是早期 Trainz 資料模型要求的三個子資料夾，名為 'asset-filename_suffix'（已過時的 tag-<value> 對），看起來像下面這樣

thumbnails
{
  Icons
  {
    width 128
    height 64
    image "40ft_boxcar_art\40ft_boxcar_art_icon.texture"
  }
 CM
 {
   width 240
   height 180
   image "$screenshot PRR 40ft_boxcar (240).jpg"
 }
 DLS1
 {
   width 512
   height 512
   image "40ft_boxcar_art\40ft_boxcar_art_512.texture"
 }
 DLS2
 {
   width 512
   height 512
   image "$screenshot PRR 40ft_boxcar (512).jpg"
 }
}

在 TS2009 和 TS2010 的早期版本中，沒有正確縮圖容器的資產被標記為有問題的。補丁後來將其轉換為警告。 這種做法在 TS12 熱修復程式中被取消，因為使用者社群中有很多抱怨。
 • 如果缺少縮圖容器的資產（即使使用過時的 thumb 標籤）後來在新的內建路線或會話中被選中，該資產通常會作為沒有影像的專案進行分發 - 如果沒有被 texture.txt 或 config.txt 縮圖容器正確引用，它們會被剝離出去。 .  

軟體連結

info-url 標籤

型別： URL 字串。

欄位定義： 指向資產線上描述、資產說明（幫助）或 TrainzOnline wiki 上其他幫助頁面的連結，旨在從嵌入式專用 N3V 瀏覽器中使用。該 URL 必須解析到 Trainz 線上安全區域 中的某個站點。目前嵌入式瀏覽器接受三個域

     auran.com
    ts2009.com
    ts2010.com 

此外，建議使用自定義 Trainz 短 URL 格式來防止 URL 針對將來可能的站點佈局更改而失效，而不是直接連結到這些域。'短 URL' 是 Trainz 特定的 URL，它們透過允許內容建立者引用 N3V 網站上的特定頁面而不依賴於特定的網頁佈局來幫助防止內容失效。短 URL 旨在用於遊戲內使用，例如 info-url 連結，並且只會在嵌入式網頁瀏覽器中使用，而不會在任何外部網頁瀏覽器中使用。如果存在此標籤，遊戲內將提供按鈕以允許使用者檢視資產描述或幫助，而無需離開遊戲環境。

這在駕駛員中對於訪問路線地圖、指南或會話說明或澄清可能非常有價值。

建議在任何情況下，對於所有提供類似功能但外觀略有不同的資產類別，都使用通用組頁面。這減少了建立、維護和本地化此類文件的時間成本。

 

must-have-product-rights 標籤

型別： ASCII 字串。

欄位定義： 一個由分號 (;) 分隔的必需產品許可權列表。如果本地安裝沒有所需的 product 許可權，則某些遊戲系統可能無法載入該資產。

 

must-not-have-product-rights 標籤

型別： ASCII 字串。

欄位定義： 一個由分號 (;) 分隔的衝突 product 許可權列表。如果本地安裝具有列出的 product 許可權之一，則某些遊戲系統可能無法載入該資產。

 

特權容器

型別： 特權容器 是一種 DRM，是某些作者使用的版權保護實現，也可以稱為特權 DRM 容器。DRM 指數字版權管理，這是它所實現的。如果已定義，某些引數將阻止檢視該資產的 config.txt 檔案。

欄位定義： 由資產建立者設定的一組特權，用於控制如何操作此資產。

privileges {
  is-payware-content 0 
  permit-listing 1
  permit-edit 1
  permit-commit 1
}

  上面的容器使用預設值設定，這意味著

0) 這不是付費軟體，因此其他欄位具有相關性 [當付費軟體編輯和提交將為零時，但可能允許列出]；

允許

1) 檢視該資產的 config.txt 檔案

2) 編輯資產，包括檢視其主資料夾中元件檔案的內容

3) 重新儲存對資產的任何更改（提交（提交）重新驗證的資產到資料庫）。

 

指令碼標籤

型別： 字串檔名。

欄位定義： 指示此資產的主指令碼檔案的檔案路徑（如果有）。此檔案路徑應始終以 ".gs" 副檔名結尾 - 執行時將嘗試新增或替換 ".gs" 副檔名，如果檔案路徑具有其他副檔名。

 

類別標籤

型別：字串。

欄位定義： 指示要載入的指令碼類名稱作為此資產的主要類，如果有的話。此類從此資產的主要指令碼檔案載入。

 

script-include-table 容器

型別： KUID 引數及其對應名稱作為鍵的列表。

欄位定義： 指令碼資產的鍵值表，在編譯此資產的指令碼檔案時，會搜尋這些指令碼資產以進行指令碼包含。鍵（變數，因此不是標記）當前未使用，但必須唯一；值指示要包含的資產的 KUID。

該 script-include-table 容器 是一個頂級 config.txt 檔案 條目，可用於從 KIND TrainzBaseSpec 派生的任何資產（簡而言之，所有資產）。此容器允許資產直接 包含另一個資產的指令碼 來自父資產的指令碼檔案，使用 N3V TrainzScript 的 Script_Include_Directive.

相關

擴充套件容器是使用特定命名約定的自定義標記或子容器的列表。

S-I-T 容器支援的標記

此容器是指令碼資產名稱及其 KUID 的簡單鍵值表，在編譯資產的指令碼檔案時，會搜尋這些指令碼資產以進行指令碼包含。鍵或標記名稱當前未使用（即為一個 佔位符引數）在搜尋中；值指示要包含的資產的 KUID。能夠搜尋和識別鍵名是內容建立者請求的功能，因此建議使用指令碼檔名而不是數字虛擬標記名作為最佳實踐，因為它比 KUID 引用傳達的資訊更多。

S-I-T 容器驗證

通常最好將此類引用限制為 KIND 庫 資產，但這並非強制性，任何資產都可以被引用。

S-I-T 容器示例

script-include-table {
                       a-key        <kuid:nnnn:nnnnn>
                       enginespec   <kuid2:www:xxxxx:yy>
                       anim-doors   <kuid:tttt:uuuuuu>
                     }

 

extensions 容器

型別： 擴充套件容器.

欄位定義： 一組擴充套件屬性，它們為指令碼提供了超出 Config.txt 檔案 為此資產型別定義的規範的資訊。在建立新擴充套件時，應注意遵守擴充套件命名指南，並在為現有擴充套件提供資料時遵守擴充套件建立者的指南。Auran 保留將來基於擴充套件建立者的指南對 擴充套件容器 中特定條目的新增驗證的權利。

 

---

更新且不太常見的

以下關鍵詞是相對較新的發展，在較舊的資產中不會有類似物或存在。 

category-keyword 標記

型別： UTF-8 字串。

欄位定義： 由分號 (;) 分隔的自然語言關鍵字列表。字串中不應存在其他字元（包括空格或無關的標點符號）。這些關鍵字構成資產關鍵字搜尋的基礎。資產的 使用者名稱 不需要在category-keyword 列表中重複。

• 各種 預設搜尋關鍵詞 是根據資產型別（KIND+category-class）自動提供的，因此不需要，可能也不應該重複。 Ø
• 標記可能不會作為空字串 ("") 或標記後為空出現，這些條件會導致錯誤。
• 明顯用途：公司，例如 ATSF、Santa Fe 和 AT&SF、B&O、Chessie、CSX、NS、PRR 或 NYC 等，而平板車、箱車、料斗車等基本型別應該是自動的。橋接鍵，如凹陷的、井車和側卸（換句話說，修飾符）可能應該用於增強自動關鍵詞生成的有限智慧。自動生成的術語的重複不應令人擔憂。

 

{{anchor|custom-category-list 容器|自定義類別列表容器|custom-category-list 標記|自定義類別列表標記|custom-category-list 字串|自定義類別列表字串|自定義類別列表容器|custom-category-list 容器

custom-category-list

型別： ASCII 字串陣列容器。

欄位定義： 自定義類別識別符號列表，由分號 (;) 分隔。每個 自定義類別識別符號 應該是一個簡短的（例如，3-6 個字元）字母數字標記。字串中不應存在其他字元（包括空格）。

• 這些自定義類別用於使指令碼能夠快速定位某些類別的資產。強烈建議謹慎引入新的自定義類別識別符號。
• custom-category-list 標記值總共不超過 64 個字元。除非存在只能透過 custom-category-list 方法滿足的現有特定指令碼要求，否則應將此標記留空。

 

member-of-groups 容器

最小構建： V3.5 及更高版本

型別： Member-of-groups 容器 將 佔位符引數 和 asset-group KUID 配對列表。

欄位定義： KIND_Asset-group 資產列表，此資產屬於這些資產。有關如何使用以及何時使用的詳細資訊，請參閱 kind KIND Asset-group 文件。

容器包含 KIND Asset-group KUID 的常規列表。此包含是一個宣告，宣告此後，特別是在搜尋操作（包括指令碼介面和 TrainzUtil）中，此資產將被視為每個列出的資產組的成員。

如果給定“member-of-groups”容器未指定任何條目，或者資產省略了“member-of-groups”容器，則模擬器軟體可能會根據資產的 Config.txt 檔案指定一些預設資產組。確切的行為可能會在模擬器軟體的不同版本之間發生變化，但是當前的邏輯在 此處 描述。 

可選的已棄用標記

以下標記對於任何資產都不是強制性的，並且許多資產將其留空。

從歷史上看，標識和許可標記從 Trainz 0.9（測試版）開始。

 

license

型別： UTF-8 多行字串。（已由程式設計師法令棄用。）

欄位定義： 描述資產建立者希望如何使用此資產的許可。最常看到的是許可宣告，禁止在任何付費路線、依賴資產（例如，轉向架、聯軸器等火車部件）或重製皮膚中使用受版權保護的資產，包括在任何付費運營的網站上分發該資產。（從理論上講，這對於 DLS 也是正確的。FCT 費用用於更快的訪問和無限次下載，而不是用於訪問資產。）

• DLS 上的大多數資產都以糟糕的措辭形式出現了被稱為 知識共享署名-相同方式共享（CC-BY-SA）像這樣和其他維基媒體維基專案。

license 標記的含義是模稜兩可的，N3V 不推薦使用它，但它的出現早於 N3V 管理 6-7 年。

上傳到 下載站 或提供用於包含在遊戲中的內容可能受特定再發行合同或許可協議的約束，該協議優先於此欄位中的任何文字。許可欄位不提供本地化支援。許可欄位的文字不受 Auran 或 N3V 驗證或執行，並且可能具有或可能不具有對終端使用者的法律約束力。

另一方面，Planet Auran 的歷史表明，任何透過使用他人的內容作為自己的內容來侵犯版權的人，可能會被迅速禁止訪問 Auran 網站，並永久失去下載站許可權，等等。此外，社群會嚴厲打擊其他使用者侵犯他人版權的行為，並回避侵權者，並忽略允許留在 DLS 上的任何資產。

總而言之，對於試圖克服內容創作學習曲線陡峭的 Trainzer 來說，實驗和修改資產是一種 *被接受甚至被認可的生活方式*（每個人都希望有更多內容創作者！），但如果資產有依賴部分，尤其是網格、指令碼、紋理，這些是智慧財產權 - 在上傳你的作品之前，請獲得使用屬於其他人的部分的許可。

*由 'kuid 引用' 指定的資產部分* 不屬於本宣告的範圍 - 使用常見的耦合器、轉向架或基本火車車廂網格（Auran 鑄造了多種標準型別，許多作者預設使用它們，透過對網格進行 kuid 引用，例如，檢查 Boxcars（英國：Covered Wagons 或 Vans）的依賴關係 - 其中一半以上可能使用對 Auran 在 Trainz 1.0 中釋出的基本網格的 kuid 引用！

 

作者標籤

型別： UTF-8 字串。（已棄用，取而代之的是可更新的 Planet Auran 資料庫。）

欄位定義： 作者的姓名或標記。不建議使用此欄位，因為歸屬可以透過程式設計方式確定。

 

組織標籤

注意英國拼寫，北美拼寫 'organization' 也適用！

型別： UTF-8 字串。（已棄用，取而代之的是可更新的 Planet Auran 資料庫。）

欄位定義： 負責建立此資產的組織的名稱或標記。不建議使用此欄位，因為歸屬可以透過程式設計方式確定。

 

聯絡電子郵件標籤

型別： 字串，電子郵件地址。（已棄用，取而代之的是可更新的 Planet Auran 資料庫。）

欄位定義： 此資產建立者的聯絡電子郵件地址。不建議使用此欄位，因為歸屬可以透過程式設計方式確定，並且可以針對建立者的 Auran 帳戶 Planet Auran 帳戶 註冊聯絡資訊，以便根據需要限制或更新。

 

聯絡網站標籤

型別： URL 字串。（已棄用，取而代之的是可更新的 Planet Auran 資料庫。）

欄位定義： 此資產建立者的聯絡網站。不建議使用此欄位，因為歸屬可以透過程式設計方式確定，並且 [聯絡資訊] 可以針對建立者的 Auran 帳戶 Planet Auran 帳戶 註冊，以便根據需要限制或更新。

 

已過時的標籤

以下 '標籤列表' 為 '事實上的'，因為它們的 '使用約定' 早於上述列出的 TBS 標籤的正式彙編，但不是使用它們的規範，實際上，也早於 TrainzBaseSpec 這個詞的創造（在 2008-2009 年的 TrainzOnline Wiki 中引入），或它在 N3V Wiki 頁面 11:32, 2009 年 5 月 12 日的正式定義。

 

• 在初步彙編之後，一些在舊版資料模型中發現的常見但現在已過時的標籤已在下面新增，例如在許多橋樑資產中發現的 bendy 及其下面的朋友。

 

編輯說明： 這些 'TrainzBaseSpec 標籤' 在某些情況下已由程式設計師在 TB V2.7 中棄用（主要是那些與機車 KIND 相關的標籤），並且在所有情況下，在 TS2009-SP0 以及之後的所有 N3V Games 版本中也是如此（儘管許多使用者在其中一些標籤中發現了實用性，但它會給內容創作者帶來的時間損失，也不是能夠在 預處理操作 中忽略那些不再有用的標籤），如果資產被開啟以進行編輯並且透過將 trainz-build 標籤 提升至 V2.9 及更高版本的 資料模型 進行部分升級，則會生成錯誤（錯誤訊息）： 資產可以在本地升級至 V2.8 或更早版本，並且通常可以正常工作，即使在經過了幾代資料模型元素的改進之後，也能正常執行。透過這種方式，許多資產可以與 TRS2004 或 TRS2006 資料建模一起使用，但仍符合 TS 版本的內部處理和渲染。 例如，大多數 TRS 時代之前的資料模型資產（v1.0–v2.3）可以透過新增一個網格表來與 TS 版本一起使用，該表取代了自 TS 版本以來被忽略的 '資產檔名' 的舊效果，以使用原始 Trainz 資料模型 的資料夾分組來定義路徑，使用具有 '_art'、'_body' 和 '_shadow' 字尾的子資料夾和名稱（其中由資產名稱加字尾定義的字串設定資產元件的路徑。 相反，具有 TB v2.9 及更高版本的 TS 版本資產通常可以通過了解這些標籤的效果和用法，以及適當地進行一些修改以消除 texture.txt 修飾符行（例如，AlphaHint 需要被註釋掉，等等），以使其與早期資料模型一起使用，這些行不被早期版本理解。

• asset-name、name 和 name-XX - V1.3–v2.8 - 歷史上在幾乎所有 v1.3-v2.0 資產中發現。雖然 'asset-name' 一直保留到 v2.8 而不引起抱怨，但在 v2.5 後開始不鼓勵使用它；因此，在 v1.5 之後，資產的 config.txt 檔案中唯一需要的、想要的或認可的名稱是 username-XX 變體。

 

資產名稱

Asset-name 是 Trainz 1.x--TRS2004 Trainz 時代資產的 主要資料夾名稱，而且大多數情況下，它是 CM 在開啟檔案以進行編輯時會開啟的資料夾的名稱；在當今這種早期資料模型資產中，通常會發現 asset-name 也用於早期 Trainz 時代的資料子資料夾系統，在火車車廂資產中，它會給出子資料夾名稱 'asset-name_art'、'asset-name_body'、'asset-name_shadow'。在修復此類資產時，大多數情況下，該值可以使用資原始檔中的樣板複製和貼上到 SAR 中進行替換。此替換通常會正確定義和連結資產子資料夾以用於車身、陰影和藝術品，因為早期方案中的檔名基於 asset-name 標籤。  

bendy 標籤

範圍： 在 軌道或橋樑資產 中發現，在 v2.9 標準之前，樣條物件經歷了重大更改，成為統一的資料模型定義，放棄了混合中的一些先前 KIND，轉而支援所有樣條物件統一在 kind track 下。

 

casts-shadow 標籤

參見上面的 bendy，已棄用/過時的 TS2009 之前遺留的 kind track 標籤。

 

name 和 name-XX 標籤

• 'name' 和 'name-XX' 是早期資料模型中更長的 username 和 username-XX 標籤的早期形式，XX 代表英文 'name 標籤'（或今天的 'username' 標籤）的非英語語言翻譯的 ISO 兩字母后綴；'XX' 形式與 description-XX 一樣，是 '本地化' 支援其他語言使用者友好值的組成部分。

• 在最古老的 Trainz 時代（v1.0-v2.4）的資產中，將 name 和 name-XX 替換為 username 和 username-XX，或者如果 username(s) 存在，則直接刪除。

• • 如果資產具有 trainz-build v2.7 及更高版本，則 name-XX 會導致錯誤。有趣的是，即使在 TS12 中，name-XX 標籤也會作為資產名稱出現在 Surveyor 工具的搜尋列表中，如果不存在，則會顯示 TrainzBaseSpec。

 

注意：Username（英文）是 DLS 上的官方資產名稱，永遠不應該使用外語；在 TB v2.5 (TRS2006-SP0 之後，它也會取代並替換 'asset-name'，當 CM 開啟資料夾以進行編輯時。 根據約定，子資料夾名稱將具有以 username/asset-name 欄位開頭的路徑規範名稱，並使用 '_art'、'_body' 和 '_shadow' 字尾作為正常命名約定的組成部分。這可能是 3ds Max 和 gmax 約定延續到 Trainz 中，與該圖形開發軟體有歷史聯絡。（Gmax 與 Trainz 版本 V0.9—v2.4 捆綁在一起）

 

category-era-nn 標籤

被 category-era 標籤 取代

• category-era-nn — V1.3–v2.8 s.a. {tag: category-era-0, category-era-1, category-era-2, ...} —以前使用數字字尾的日期系統——在 TBV 2.0 之前幾乎所有需要日期的資產中都可以找到（甚至在 TBV 2.8 構建的資產中也可以找到！），當時引入了當前的 category-era 字串陣列，將這些數組合併到一個 config.txt 行中。雖然在 Surveyor 中無法直接訪問，但在 TR06 和 CMP 之後，可以定義一個過濾器來選擇一個日期範圍，並將該過濾器與 Surveyor 中的區域和型別一起使用，以檢驗 Surveyor 安置和選擇工具中可以列出的資產。在 TS09 及之後版本中被廢棄，TS09 使用更短的 category-era 標籤 字串陣列 在一行中，而不是使用多個以 '-nn' 為字尾的標籤-值對。

• 字串陣列中的空格會導致錯誤；所有值必須以 's' 為字尾，幷包含四個數字，s.a. 1880s;1950s;2010s （這可能完全適合某些型別的女性服裝，這些服裝會隨著時尚的變遷而流行起來！）。目前無法定義範圍，但使用者社群已提出請求。

• 用字串陣列型別的 category-era 標籤 替換，不使用空格，日期程式碼之間使用分號分隔；這些程式碼以完整的四位數年代為字尾，後面加上 's'（小寫字母 s）字尾。

 

category-region-nn 標籤

被 category-region 標籤 取代

• 型別 category-region-nn — V1.3–v2.8 —在幾乎所有需要位置資訊的資產中都可以找到。這些已被兩個字母的 ISO 國家程式碼的 '字串陣列' 取代，該陣列位於 category-region 標籤中。

• 用字串陣列型別的 category-region 替換，不使用空格，在兩個字元的國家程式碼之間使用分號分隔，這些程式碼在引用的標籤部分中列出；這些程式碼以兩個大寫字母組成，包含 列舉 程式碼，程式碼之間用 ';' 分隔，但最後一個程式碼除外，最後一個程式碼之前沒有分隔符。
• 字串陣列中的任何 空格 都會導致讀取錯誤和錯誤訊息，包括結尾處的空格，這些空格在尾部引號之前。

 

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

作為以前的過濾器修飾符，該標籤在歷史上出現在幾乎所有資產中，但在機車車輛、風景、樣條線資產、軌道型別（包括隧道和橋樑）和具有某種程度的本地化的路邊資產中尤其常見。

• 地圖資產仍然保留著 Region 關鍵字，該關鍵字是在地圖配置中定義的，其使用方式相反——它是 kind region kuid 引用。因此，Region 在地圖中是必需的，並且自 TS2012 以來，與標籤型別類似，在大量資產中都是非法的，因為這些資產曾經作為 TRS 系列版本 Surveyor 工具視窗的 '分組資料' '快速過濾器' 出現。
• 在 TRS2009 之後，任何指向文字字串的 region 標籤都已過時，因為程式設計師用 Pick List 替換了 Surveyor 工具中 '型別和區域' 字串值的粗略過濾分組選擇器。這兩個標籤都有一些優點和缺點，而且都可追溯到 Trainz 0.9 Beta 版本。

 

shadows 標籤

請參見上面的 bendy，該標籤已過時/廢棄，是 TS2009 之前遺留的 kind track 資產模式控制標籤。

 

thumbnail 標籤

thumbnail 標籤是 thumbnails container 的早期單檢視實現（上面也有簡要介紹）。Trainz 的早期 N3V 之前的程式設計師版本將找到一個 .jpg 檔案，該檔案最好大小為 240x180 畫素，位於主資產根目錄，或 asset-name_art 或 asset-name_body 資料夾中，並將其用於在 CMP 和 DLS 中顯示資產（如果已上傳）。該標籤在 TRS2006 期間被廢棄，因為 thumbnails container 是隨著 v2.0（TRS2004-SP0）推出的。在舊的修復過的資產中，如果 TBV 保持在 v2.4 以下，則在較新的 CM 中拇指通常仍然有效，前提是它位於 _art 子資料夾中，並且資產名稱與使用者名稱匹配。 

type 標籤

• type — V1.3–v2.8 —以前的過濾器修飾符，在歷史上出現在幾乎所有資產中，但在機車車輛、風景、樣條線、軌道型別（包括隧道和橋樑）和路邊資產中尤其常見。
• type 標籤與 'region 標籤' 類似，在 Trainz 0.9—TC3 版本中用作 'Surveyor 內分組過濾器' ，與 region 結合使用，可以提供更小的資產選擇（工具組）。自 TS2009 以來，該版本刪除了這些本地可點選過濾器功能和用法，轉而使用一種新的更繁瑣的過濾器。這些使工具選擇變得快速簡單，而不是在工具選項卡之間切換時變得緩慢和暫停——如今的 TANE 之前的版本在工具選項卡之間來回切換時，通常會因重新載入整個選擇列表而感到不堪重負。
• type 和 region 都預設設定為 'All'，與 TS09 及之後版本中工具提供的列表相同。

• 在 TRS2006 分支版本（即 TC3）之後，所有 type 標籤都已過時，因為程式設計師用 TS09 Pick List 和過濾器替換了 Surveyor 工具中粗略過濾的 '型別和區域' 分組選擇器——沒有賦予使用者儲存多個 Pick List 或輕鬆載入在 CM 中定義和細化的過濾器的能力。

 

參考資料

• 本頁面的主體內容取自 N3V TrainzOnline Wiki，來自 KIND_TrainzBaseSpec。Yesterdayz-Trainz 使用者組成員添加了增強資訊。