Trainz/refs/TrainzBaseSpec
(重定向自 Trainz/thumbnails container)
KIND TrainzBaseSpec 為所有 Trainz 資產型別提供基礎定義，適用於所有 config.txt ini 檔案。TBS 提供了一些“標準標籤”，這些標籤對（或至少，可以合法地定義）所有 Trainz 資產都適用，包括所有 Trainz 資產[1]。
- 其中一些是強制性的，因為它們決定了資產的進一步處理以及對 config.txt 檔案和其資料夾中資產資料的解釋。
- 但是大多數是可選的，並且大多數子資產可能會省略使用該標籤的定義行。
- 所有由事實上的父容器定義的內容，包括 config.txt 檔案，都是必需的，該檔案是所有 Trainz 數字模型所必需的。 KIND TrainzBaseSpec (TBS) 是一個 根類，其他 Trainz 資源類都是由此派生的。
- 之所以說它們是派生的，是因為它們繼承了其中列出的引數定義的處理屬性（指令）和值，其中關鍵的是 kind 標籤的值。該列舉詞決定了資源的特定 型別宣告和要求，這些宣告和要求將新增到該資源的配置檔案中的 TBS 定義中。其他關鍵的 TBS 定義資料也很重要且實用，例如資源的名稱、Kuid 識別符號和版本、Trainz 構建值 (TBV) 以及其他具有廣泛可變定義、適用性和範圍的定義，例如 string-table、obsolete-table、kuid-table 和縮圖影像，每個都是偶然的。即使是資源名稱和描述的字串值，在實踐中通常也是完全不必要且可省略的。
- 當宣告一種型別時，該型別將成為父類，除了 TBS 中列出的那些，它還要求並指定類中必須滿足的必要的成對資料。
- 某些引數在資源型別的某個案例中可能未定義，特別是針對較舊的歷史 Trainz 構建標籤值而言，對於這些值，內容管理器或 內容建立者 Plus (CCP) 實用程式將分配預設值，但在處理它時列出警告訊息。TrainzOnline wiki、此處或較舊的 TC3 時代 內容建立者指南 (CCG) 中的許多標籤會提到一個預設值。
- 從 TRS2006 和 Trainz Classics (TC1&2) 開始，每個版本的 內容管理器 模組都實施了越來越多的事前承諾錯誤測試[note 1]，並且每個模組在警告此類標籤未定義時變得越來越堅決，因為它期望此類標籤 - 資料對。
在 TANE 釋出後的版本中，許多這些“昨天預設”的定義行今天更有可能生成一個錯誤，要求明確的定義值，而過去在載入時這些值是預設的[note 2]。與舊時代相比，這是一個更可取的煩人之處，在舊時代，有缺陷的資源定義有時會導致臭名昭著的“藍色畫面宕機”，或者更常見的是，將執行時軟體崩潰到桌面，導致編輯丟失，並可能需要重建資料庫。
子類
[edit | edit source]
所有 Trainz 定義的資料（內容）都包含三個必需的元素：一個用於組織資料的 config.txt 檔案、一個表示 kuid 的身份（僅使用者名稱對你沒有用，但可以建立合法資源，而無需名稱！）以及最後，一個合法定義的型別標籤。型別負責，是管絃樂隊的指揮，是排長或 CEO 指揮——為在之後處理的所有事物設定要求。簡而言之，型別的價值——一個很小的、精心挑選的、嚴格定義的成員專用組——告訴 Trainz 軟體在虛擬世界中要渲染和顯示什麼，以及在哪裡（或如何）找到構成該配置檔案中該資源這些部分的其他部分。
下面的每個子類都被認為具有 TrainzBaseSpec 作為它們的“父類”資料[note 3]。下面列出的一些型別，那些帶下劃線的型別，是早於 Trainz 資料模型 在 TS2009 釋出（即從 2008 年後期開始）的更改之前的遺留型別，此後 N3V 程式設計師只實施了逐漸的（增量的）更改。
目前可以在 N3V Trainz Wiki TrainzOnline 網站此處 的 內容建立者指南 部分找到有關根據這些遺留型別修復資源的詳細資訊，其中包含具有啟發性的 遺留型別的示例此處。強烈建議 Trainz 下載站 的任何使用者或任何考慮建立內容的人員仔細閱讀 CCG。瞭解舊內容定義方式的背景歷史資訊可以與 TrainzOnline 對相同資料型別的當前覆蓋範圍進行對比，因為這種“過去與現在”的比較通常會為修復、更改和自定義資源提供寶貴的見解。更重要的是，CCG 中的寫作是由專業人士製作的，並且更具邏輯性——它通常會讓你瞭解如果更改了這一點或那一點，會產生什麼擴充套件影響，而 Trainz Wiki 並沒有提供這些資訊。TrainzOnline 上釋出的 CCG 是 TC1&2/TC3 版本——是自 1999 年的 Trainz 開始印刷的幾本小冊子的最後一個已釋出版本；TC3 CCG 包含來自 TRS2004/TRS2006 和 UTC 資料模型的已更改的 Enginespecs 機車資源，需要進行適當的更新。
表 I，TBS 標準定義
[edit | edit source]TBS 標準定義
[編輯原始碼]這些標籤和容器是標準定義，幾乎可以在所有資源中找到。一些標籤是可選的，並且可能不會被內容建立者定義，因為他們的選擇。標籤是關鍵字，並且有一個分配的鍵值或容器，例如字串陣列或'{' ... '}' 繫結封閉的標籤值對或子容器。（Trainz 配置檔案中宣告的所有內容都是成對的，即使 '{' ... '}' 也被認為是一個“鍵值”。
- 容器是'鍵' 和 '鍵值' 對的集合以及 TBS 中的 '上層容器' （與縮圖容器中的子容器相反）通常以 '-table' 為字尾。
| 種類 | "'字串值'" |
| trainz-build | '浮點數', 1 位小數 |
| kuid | <Kuid 編碼值> |
| 使用者名稱 | 使用者名稱 "'字串值'" |
| 使用者名稱-XX | 使用者名稱-XX "'字串值'" |
| 描述 | 描述 "'字串值'" |
| 描述-XX | 描述-XX "'字串值'" |
| kuid-table (容器) { 依賴項列表 |
一個鍵值表，列出了此資源所依賴的所有資源。 |
| obsolete-table (容器) { } |
kuids 列表，此資源替換（使之過時） 通常為無（空）[註釋 5] |
| 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 資源組 資源列表。 |
TrainzBaseSpec 支援 config.txt 檔案 中的以下標籤。 ∅:
- 型別：字串。
- 欄位定義：此 config.txt 檔案 所代表的資源型別。參見索引 種類 和列表：這裡（上面）
- KUID
- 'Koolthingz Unique IDentifier'. Trainz 系統軟體的唯一資料庫參考編號，也擴充套件到在 KUID2 格式中跟蹤多個版本。Trainz 可升級性和資源模組化設計的核心，因為每個資源都有自己的唯一 kuid 程式碼，因此可以在新資源中指定元件（轉向架）或整個火車車廂，並在新資源中選擇性地替換任一元件（重新蒙皮或修改卡車）。
- 基本 KUID 格式：'<kuid:wwwwww:xxxxxx>'，其中 wwwwww 是作者的“唯一 Trainz 身份”，而 xxxxxx 代表作者分配的 模型標識程式碼。
 |
|
- 大多數 Trainz 資源在其 kuid-table 中指定依賴項列表——軟體套件的各個部分組裝的其他元件資源，以在 kuid-table 容器 中組成一個可渲染和可使用的資源。
- 在許多資源的核心，特定標籤可以透過kuid 引用來定義，並使用引用的資源作為一部分。實際上，這就是重新蒙皮的實現方式，並且可以使用網格在資源中，儘管更現代的做法建議這種引用應該指向網格庫資源。
- KUID2
- KUID 格式的更新版本和更新跟蹤修改版本，允許指定版本號。一個
<kuid:xxx:yyy>等於說<kuid2:xxx:yyy:0>（零修訂或版本零，表示原始版本）- 這允許資料項（Trainz 資源）攜帶資源的固有版本程式碼。這通常不會與 CM Trainz-build 程式碼 相匹配，該程式碼標識軟體技術水平，但表示之前的版本歷史記錄。
- 在資料庫中同時存在兩種資源的情況下，具有較高字尾程式碼的資源會在 KUID2 中覆蓋或替換較舊的資源。擁有早期版本不是必需的，但 CM 會將丟失的修訂鏈列為丟失的依賴項，對於那些不喜歡 CM 中該設施受到汙染的人來說，這是一個軟體錯誤，或者對於程式設計師來說，這是一個“功能”保留了原樣，在任何情況下，都降低了使用 CM 來識別使用者缺少什麼內容的實用性，並導致使用者花費時間手動弄清楚什麼是真正的什麼內容。
- 主要範圍：trainz-build 標籤，縮寫：TB & TBV (TB-value)∅
- 型別：一位小數浮點數 列舉 由 N3V[2] 追蹤和識別與演化軟體的技術水平相對應的資料型別。
- 範圍：1.0–4.3 直接對應（'對映onto3rd' Trainz 1.0—TANE-SP1+hf2；此值預計會隨著每次新的主要軟體升級而增加 0.1。
每個合法值必須與 Trainz 的釋出版本號完全匹配 版本號，但以下情況除外
- 分配給 TBV 或版本值的 V1.4 是 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 無服務包）到當前版本（v3.7 = TS12-SP1，v3.8 = Mac2，3.9=TANE-CE，4.0—4.3 及其後？從 2016 年 3 月起，4.3 及以上是 TANE SPs TBDL）遞增 0.1。
- 從 v2.0 (TRS2004) 開始，Trainz-build 標籤編號值已經透過 23 個步驟增加，這些步驟是連續的，儘管是非單調的，因為 Trainz TS09-sp3—TS09-sp4 共享一些 Trainz-build[2] 值；也就是說，在 TS2009 和 TS2010 的聯合開發時代和釋出中，有一些 TBV 是共同共享的。
- 此外，N3V 進軍蘋果電腦領域打斷了 Windows 版本的 Trainz 版本中 TBV 3.4、3.5、3.6、3.7 和 3.8 的平滑遞增，這些 TBV 在 Windows 和 Mac 作業系統之間相互交織。
注意： 熱修復 不會改變版本號。
- 欄位定義： 此資源構建（和存檔）到的檔案格式版本（不一定與資源使用的技術級別有關），但與在 Content Creator Plus 中建立資源時分配給資源的級別相對應——與在 CM 的標題欄中找到的級別相同。
- 程式設計師建議此數字通常應該設定為正在建立和測試資源的 Trainz 安裝的 Trainz 版本號。相比之下，Content Creator 社群試圖將此數字設定得儘可能低，以便在下載時為新資源提供儘可能廣泛的受眾/使用者範圍。優秀的資源創作者會在對應版本的裸機安裝（無新增內容）上進行測試，並驗證生成的 cdp 是否包含所有相關材料。
- 某些資源型別根據其trainz-build 版本標籤的解析方式顯著不同。注意：trainz-build 標籤 是強制性的。如果沒有指定，Trainz 將根據 config.txt_file 的內容嘗試以原始的方式猜測 Trainz 版本，這通常會將 TBV 解析為 1.3。
使用者名稱標籤
[edit | edit source]- 型別： UTF-8 字串，資源的使用者名稱，強制性規範。
- 欄位定義： 此資源的英文人可見名稱。
在 TC1&2（v2.7）之後的 trainz-build 中，當資源被編輯時，使用者名稱也變成了作業系統資料夾名稱，而資原始檔名被忽略，而在 v2-6 配置檔案中，資原始檔名優先。根據 N3V games 的 TBS 標準，此欄位絕不應該包含非英語文字，除非資源名稱是專有名詞（例如，地名）且沒有英語本地化變體。此值是每個人通常搜尋和記住的依據，因此建議使用清晰的名稱。
 |
|
使用者名稱-XX 標籤
[edit | edit source]- 型別： UTF-8 字串，使用者名稱標籤 的替代語言版本。
- 欄位定義：（其中XX 被替換為代表該語言的適當 本地化程式碼。）此資源的本地化人可見名稱。此欄位類似於使用者名稱欄位，但代表非英語區域設定。一個資源中可能存在多個使用者名稱-XX 標籤，每個支援的區域設定一個。如果在給定的終端使用者系統上沒有適當的“使用者名稱-XX”標籤來表示此資源，則改為使用英文使用者名稱標籤。
描述標籤
[edit | edit source]- 型別： UTF-8 多行字串，提供資源的清晰語言描述。
- 欄位定義： 此資源的英文人可見描述性摘要。
描述在內容管理器“資源詳細資訊”窗格中可見，用於澄清資源名稱、提供規格，通常還提供一些歷史資訊。
N3V 的 Chris Bergmann 表示，此欄位應該保持簡短（1-2 段），描述資源，並透過info-url 頁面提供擴充套件的詳細資訊，但可以容忍相當長的文字塊。有些人將塊的底部用作版本變更記錄。
此欄位必須由英文描述性文字組成，儘管文字可以引用非英語專有名詞，如其他地方所述。其他語言翻譯或源文字應放置在許多可能的替代語言本地化標籤之一中（參見 description-xx 標籤）。
description-XX 標籤
[edit | edit source]- 型別： UTF-8 多行字串，描述標籤。
- 欄位定義：（其中XX 被替換為代表該語言的適當 本地化程式碼。）此資源的本地化人可見描述性摘要。此欄位類似於description 欄位，但代表非英語區域設定。一個資源中可能存在多個description-XX 標籤，每個支援的區域設定一個。如果在給定的終端使用者系統上沒有適當的“description-XX”標籤來表示此資源，則改為使用英文description 標籤。
字串表容器
[edit | edit source]- 型別： UTF-8 字串列表容器，字串表容器。
- 欄位定義： 英文字串的鍵值列表。每個鍵都是一個有意義的指令碼識別符號，對映到二進位制資料並被其引用。每個值都是一個英文字串。一個英文字串可能包含或引用一個非英語專有名詞作為識別符號。非英語母語的資源作者仍然必須建立一個沒有後綴的字串表容器（如果有需要）。軟體只連結和引用字串表容器中沒有後綴的名稱和值，這必然會讓西班牙語、法語、德語、捷克語、荷蘭語……日語的作者感到厭煩。換句話說，帶字尾的字串表僅僅用於翻譯目的，當地圖是用非英語編寫的時，就會產生問題——沒有 string-table-en 來提供一個用於反向翻譯的表格。同上，username-en 和 description-en。這三種缺失體現了一種過時的、傲慢和對世界動態的漠不關心。
其他語言透過類似的字串表（例如 string-table-XX）得到支援，這些字串錶帶有與 description 和 username 關鍵字/標籤的國際化字尾相匹配的本地化程式碼字尾（XX），但這些語言鍵控的字串表容器總是會在左側條目中擁有相同的鍵值。
- 這些左側鍵或標籤既充當“本地索引關鍵字”，又充當“不同語言之間的等價表”。
- 左側列將始終包含資源建立者賦予“特殊”名稱的物件，例如訊號、軌道標記和行業、交叉口等的名稱，這些名稱可能會被引用，並且會出現在駕駛員和勘測模組的“查詢實用程式” (CTRL+F ) 小程式功能。
- 反過來，索引端也不會列出預設的地名，例如在構建路線圖時，由隨機數自動索引的無數交叉口集合（即毫無意義的混亂。如果重要，路線構建 CC 將對其命名！），但會自動包含可能臨時的資源，如火車車的預設名稱。如果重新命名，這些名稱將取代其相應的預設名稱。
- 其主要用途是針對那些旨在與指令碼引用互動並承擔可變屬性的物件，例如火車站或行業所需的或準備在行業發貨的產品數量，或由互動式火車車廂（滾動行業到指令碼）和其他可配置資產（如簡單通用的廣告牌樣式標誌）攜帶，這些標誌可以透過一些高度調整和角度扭矩放置在股票建築或行業的正面，以在建築上放置不同的公司名稱。換句話說，只是一些可配置的風景。
- 總體而言，在路線地圖或佈局中，這些 LHS 名稱對應於地圖資產上的命名物件，這也是大多數字符串表出現的地方（從字面上看，由大型路線kind map中的數千個條目填充）。
- 在某些資產中，該預設名稱被掛鉤到軟體指令碼，因此字串表變得特別重要，而不是無聊。（見下文）
- 在每種型別的資產中，使用字串表型別始終是合法的，就像描述標籤和 trainz-build 和 kind 標籤一樣。與它們不同，它不必存在或定義，並且絕不是強制性的。除非程式碼期望它們的結合，否則封裝在字串表容器中的值沒有功能或效果。
- 在其他資產中，再次以那個假設的可程式設計商業標誌為例，如果字串表要與軟體互動，則必須為其指定一個預設名稱。所有地圖可放置資產都可以命名或重新命名，但“特殊名稱”必須與指令碼和字串表索引值匹配。大多數可配置資產定義一個介面變數，用於替換預設名稱作為索引或查詢表，該表引用指令碼和資產的二進位制資料。其他變數也可能在可程式設計資產中定義。這些變數中的每一個都可以透過指令碼引用，但正是索引值使它進入地圖或會話字串表，從而使一切在需要驅動程式或會話建立者可變性時協同工作。
- 相比之下，如果沒有系統軟體知道索引中命名的專案的位置，則物件的指令碼可能沒有觸發、條件檢查或更新的能力。這是 2000 年代Trainz 1.0中物件的特徵，而不是自 2003 年TRS2004釋出以來的現代 Trainz 鐵路模擬器。（我們已經走了很長一段路了！）
- 有些資產只能作為一個組一起工作。在這種情況下，在對映或會話層中為每個資產命名使它們能夠協同工作。例如，考慮一個有五條軌道的公路平交道，其中兩條是脫節的，形成所謂的“交叉交叉”與直通軌道。如何設定訊號以便任何鐵路交通關閉公路閘門，或者使用交叉交叉不允許其他火車穿過一個正在穿過交叉的火車。道路和鐵路訊號以及道岔和閘門必須協同工作。某些“ATLS 系統”資產及其指令碼透過字串表相結合可以使這個複雜系統正常工作。
- 有關更多資訊，請參閱 string-table-XX。
- 型別： UTF-8 字串列表容器，即本地化字串表，每個字尾對應於除英語以外的其他語言。
- 欄位定義：（其中XX被替換為表示的語言的適當本地化程式碼。）此欄位類似於string-table欄位，但代表非英語語言環境。
英語字串表（無後綴）是強制性的，其他本地化語言是可選的，由資產作者決定。提交到 DLS 然後也用於 Trainz 版本捆綁路線中的許多資產通常會被翻譯並具有描述-XX 和字串表的完整本地化翻譯集。特別是，與版本捆綁在一起的路線和會話在每次零售版本中都經過專業翻譯成多種語言。
請注意，字串表的左列是相同的，因為它是一個對映符號表，並且是二進位制資料的索引，例如網格、會話或路線檔案。只有使用名稱、兩個元素中的右手或資料元素是本地化的，並由執行時本地化軟體替換。如果需要，可以在英語字串表中手動編輯這些名稱，以使其更友好。索引或左側引用列語法不得以任何方式更改，因此在資料列中更改名稱時要小心使用全域性 SAR 規範。
資產中可能存在多個string-table-XX標籤，每個支援的語言一個。每個標籤應包含一個字串列表，該列表與string-table列表中的鍵相同，但值不同。如果不存在適當的“string-table-XX”標籤來代表給定終端使用者系統上的此資產，或者該列表中缺少適當的字串，則會改為引用英語string-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 列表容器，與obsolete-table 容器（在下文）格式相同。一個虛擬引數+ 一個（依賴）kuid
- 欄位定義：區分此資產所依賴的資產列表的鍵值。
- 一般來說
- 只有具有子元件或具有備選選擇（貨物）的資產才會具有具有任何可觀長度的 kuid-table。大多數具有子元件的資產只有幾個。
- 其次，存在一個約定，它源於有時內部關鍵字是“自動定義”的事實——僅僅列出為一個沒有名稱的數字，作為佔位符引數，偽關鍵字可以是任何唯一值（通常是零索引的順序整數。[註釋 1]）它們可以根據使用者或作者的喜好被命名或不命名。
- 此表中的條目有兩個目的
首先：確保遊戲系統知道該依賴關係，以便安裝和載入此資產將成功安裝和載入任何依賴關係，以及
其次：允許指令碼找到相關的子資產。 - 只有第一級依賴關係應包含在 kuid-table 中——具有自身依賴關係的子級或部件資產將在該子資產的驗證和資料庫提交過程中處理。
- 迴圈依賴關係是非法的。
- 如果資產也被標記為此資產的過時版本，則不能將其列為依賴關係。（Trainz 資產索引（歷史上是 assets.tdx 檔案）中只有一個替換 kuid 插槽，這將建立一個需要自身較早版本的迴圈定義！）
- 同樣，資產不能被列為它自身的依賴關係。[OTOH，這已在 TSxx CMs 中作為成功提交的無故障資產被體驗（即見證）過，將地圖和會話移植到安裝之間，並使用 GSARS 更改 kuids，以便重疊不會覆蓋已經在目標安裝上使用相同 kuids 的資產，而不會看到錯誤訊息。] 是否執行得也需要比我更勇敢或更愚蠢的人！——Fabartus，ed.
- 格式(所有值都為 <kuid:aaaaa.bbbbb> 格式)
kuid-table {
0 Kuid-1
1 Kuid-2
3 Kuid-3
... kuid-ii
N-1 Kuid-N
}
|
|
- 利用這些是虛擬引數這一事實的一個非常有用的方法是將複雜滾動庫存資產中產品的 kuids 配對。一個箱車可能包含各種各樣的產品……獲得許可將你自己的作者 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>
} ...
請注意連線單詞的下劃線……兩個符號，鍵和值！我們讓學生弄清楚在哪裡將 kuids 新增到裝載和允許的產品隊列表條目中。（歡迎使用，但這是更改名稱的充分理由！使事情井井有條几乎是製作資產的整個戰鬥！）
- 型別： KUID 列表容器，與Kuid-table 容器格式相同。
- 欄位定義：一個“佔位符鍵-鍵值”列表，其中列出了被此資產淘汰的資產。嘗試載入此列表中的任何資產將導致改為載入此資產。
- 此外：如果兩個資產都標記第三個資產已過時，則是非法的，除非其中一個資產也標記另一個資產已過時。[註釋 6]
- 迴圈過時引用是非法的。
- 所有較低編號的 KUID2 版本的此資產都隱含為已過時，無需包含在此列表中。同時，具有較高 Kuid2 的較新改進資產及其前身之一不應為“中間”的中間前身列出相同的先前版本（例如原始版本！）——因為這些值用作替換條目表，並且只有一個資產可以替代早期版本。（陣列只儲存一個值，不能用兩個值替換一個值！）
- 標記此資產的較高編號的 KUID2 版本已過時是非法的，因為這會建立一個隱式迴圈引用。
- 此列表中引用的資產必須與此資產具有相同的建立者，才能透過 DLS 上傳過程稽核和接受該資產，此限制不適用於你的本地版本，例如，它可能用於使用一個在圖形上更令人愉悅且更新的資產來替換一組大型火車車廂上的所有舊紙質輪轂 kuids。
- 目的: 在 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" (大多數第一世界國家)
- 目的: 在 CM 和 Surveyor 中過濾 (搜尋條件)；根據 KIND 聲明確定 CM 軟體如何處理資產，以及 Surveyor 在哪裡列出資產。
- 型別: 列舉字串。
- 欄位定義: 單個 2-3 個字元的 category-class 程式碼，用於描述此內容項。category-class 標籤用於提供超出資產種類隱含含義的額外的人工子分類。每個 Trainz 資產的 category-class 標籤有助於描述資產在遊戲中的“意圖”，而不是資產的內部結構。
|
|
請注意，許多 category-class 程式碼只與特定資產種類相關 - 不得將 category-class 程式碼應用於不合適的種類的資產。
- 示例
| category-class "XBG" | Boxcar - 來自 PRR 60' | |
| category-class "BR" | 鐵路（風景非功能性） - 可能是一棟建築 | |
| category-class "BIN" | 具有產品處理功能的工業資產 |
- 每個時代程式碼代表一個十年，由一個四位數字整陣列成，然後 必須 以 's' 結尾
(例如 "1990s;2000s;2010s"),從而建立一個列舉軟體令牌（值），它必須與指定合法 時代程式碼 完全匹配。 - 字串中不應包含其他字元（包括空格等），包括（尤其是在字串末尾）在終止雙引號字元之前。
- 允許的年份範圍是 1800-2010s[註釋 7]
- 此資產的唯一意義是對其他人類來說，此資產被認為在指定的時代範圍內是有效的並且適當地相關，並且 內容管理器 將接受指定適用年份的搜尋過濾器。
- 示例
category-era "1920s;1930s;1940s;1950s"
- 目的: 在 CM 和 Surveyor 中過濾 (搜尋條件)
- 型別: 縮圖容器。
- 欄位定義: 用於在整個遊戲環境中以 2D 預覽框、列表和圖示形式表示此資產的縮圖。每個資料集都包含在一個子容器中（通常）使用 佔位符引數 作為鍵名稱或標籤。[註釋 8] 慣例使這些成為 0 索引整數，但值可以是任何可以評估為 字串 的非空文字值。（參見下面的第二個示例）
- 實際示例
- (來自資產修復編輯[3])
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 True Color）（Trainz 1.0-TC3 慣例：_art、_body 和 _shadow 是早期 Trainz 資料模型需求指定的三個子資料夾，名為 'asset-filename_suffix'（過時的 tag-<value> 對），如下所示[註釋 9]
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 的早期版本中，上傳沒有正確縮圖容器的資產會將沒有縮圖容器的資產標記為有故障。補丁隨後將這些變成了警告。[註釋 10] 這種做法在 TS12 熱修復程式中被放棄，此前使用者社群對此提出了很多抱怨。
• 如果缺少縮圖容器的資產（即使使用過時的 thumb 標籤）後來在新的內建路線或會話中被選中，該資產通常將作為沒有影像的專案進行分發 - 如果沒有被 texture.txt 或 config.txt 縮圖容器正確引用，它們將被剝離。[註釋 11]
- 型別: URL 字串。
- 欄位定義: 指向資產線上描述、資產說明（幫助）或 TrainzOnline wiki 上其他幫助頁面的連結，旨在從嵌入的特殊用途 N3V 瀏覽器中使用。該 URL 必須解析到 Trainz Online 安全區 中的站點。目前，嵌入式瀏覽器可以接受三個域
auran.com
ts2009.com
ts2010.com
此外，建議使用自定義 Trainz 短 URL 格式來防範未來的站點佈局更改，而不是直接連結到這些域。'短 URL' 是 Trainz 特定的 URL，它們有助於防範未來內容，允許內容建立者引用 N3V 網站上的特定頁面，而不依賴於特定的網頁佈局。短 URL 旨在用於遊戲內使用，例如 info-url 連結，並且僅在嵌入式網頁瀏覽器中有效，而在任何外部網頁瀏覽器中無效。在存在此標籤的地方，遊戲內按鈕將允許使用者檢視資產描述或幫助，而無需離開遊戲環境。
這在駕駛員中非常有價值，可以訪問路線地圖、指南或會話說明或說明。
建議在任何情況下使用通用組頁面，以便對所有提供類似功能但外觀略有不同的資產進行分類。這減少了建立、維護和本地化此類文件的時間成本。
- 型別: ASCII 字串。
- 欄位定義: 由分號 (';') 分隔的必需產品權利列表。如果本地安裝沒有必需的產品權利，則某些遊戲系統可能無法載入資產。
- 型別: ASCII 字串。
- 欄位定義： 一列衝突的產品許可權，用分號 (;) 分隔。如果本地安裝包含列出的產品許可權之一，則某些遊戲系統可能無法載入資產。
- 型別： 許可權容器 是由一些作者使用的 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”副檔名，如果路徑具有其他副檔名。
- 型別：字串。
- 欄位定義： 指示要載入的指令碼類名稱作為此資產的主類，如果有。此類從此資產的主指令碼檔案載入。
- 型別： KUID 引數和相應的名稱作為鍵的列表。
- 欄位定義： 指令碼資產的鍵值表，在編譯此資產的指令碼檔案時搜尋指令碼包含。鍵（一個變數，因此不是一個標籤）目前未使用，但必須唯一；值指示要包含的資產的 KUID。
指令碼包含表容器 是任何從 KIND TrainzBaseSpec 派生的資產（簡而言之，所有資產）都可以使用的頂級config.txt 檔案 條目。此容器允許資產直接從父資產的指令碼檔案使用包含另一個資產的指令碼，使用N3V TrainzScript 的 Script_Include_Directive。
- 相關
擴充套件容器是具有特定命名約定的自定義標籤或子容器的列表。
此容器是指令碼資產名稱及其 KUID 的簡單鍵值表，在編譯資產的指令碼檔案時搜尋指令碼包含。鍵或標籤名稱目前未使用（即是一個佔位符引數）在搜尋中；值指示要包含的資產的 KUID。能夠搜尋和識別鍵名稱是內容建立者請求的功能，因此建議使用指令碼檔名而不是數字虛擬標籤名稱作為最佳實踐，因為它比 KUID 引用傳達的資訊更多。
通常最好將此類引用限制在KIND 庫 資產，但這並非強制性要求，任何資產都可以被引用。
script-include-table {
a-key <kuid:nnnn:nnnnn>
enginespec <kuid2:www:xxxxx:yy>
anim-doors <kuid:tttt:uuuuuu>
}
- 型別： 擴充套件容器。
- 欄位定義： 一組擴充套件屬性，它們為指令碼提供了超出為該資產型別定義的Config.txt 檔案 規範的附加資訊。建立新的擴充套件時，應注意遵守擴充套件命名指南，並在為現有擴充套件提供資料時遵守擴充套件建立者的指南。Auran 保留權利，在將來基於擴充套件建立者的指南，對擴充套件容器 中的特定條目新增驗證。
以下關鍵詞是相對較新的發展，在舊的資產中不會有類似物或存在。
- 型別： UTF-8 字串。
- 欄位定義： 一列自然語言關鍵字，用分號 (;) 分隔。字串中不應包含其他字元（包括空格或不相關的標點符號）。這些關鍵字構成資產關鍵字搜尋的基礎。資產的使用者名稱 不需要在類別關鍵字列表中重複。
- 基於資產型別 (KIND+類別類)，會自動提供各種預設搜尋關鍵字，因此不需要，可能也不應該重複。 Ø
- 標籤可能不會以空字串 (“”) 或空白形式存在於標籤之後 - 這些情況會生成錯誤。
- 明顯的用途：公司，如 ATSF、Santa Fe 和 AT&SF、B&O、Chessie、CSX、NS、PRR 或 NYC 等，而基本型別，如平板車、箱車、料斗車應該自動生成。橋接鍵，如低位、井車和側卸（換句話說，修飾符）可能應該被用來增強自動關鍵字生成的有限智慧。重複自動生成的術語不應引起關注。
{{anchor|custom-category-list container|自定義類別列表容器|custom-category-list tag|自定義類別列表標籤|custom-category-list string|自定義類別列表字串|自定義類別列表容器|custom-category-list container
- 型別： ascii 字串陣列容器。
- 欄位定義： 一列自定義類別識別符號，用分號 (;) 分隔。每個自定義類別識別符號 應為一個簡短（例如 3-6 個字元）的字母數字標記。字串中不應包含其他字元（包括空格）。
- 這些自定義類別用於使指令碼能夠快速定位特定類別的資產。強烈建議謹慎引入新的自定義類別識別符號。
- custom-category-list 標籤值最多隻能包含 64 個字元。除非存在現有的特定指令碼要求，只能透過自定義類別列表方法來滿足，否則應將此標籤留空。
- 最小構建： V3.5 及更高版本
- 型別： Member-of-groups 容器 配對列表佔位符引數 和資產組 KUID。
- 欄位定義：該資產所屬的 KIND_Asset-group 資產列表。有關如何以及何時使用該列表的詳細資訊，請參閱 kind KIND Asset-group 文件。
該容器包含一個常規的 KIND Asset-group KUID 列表。該包含是一個宣告，表明此後，特別是在搜尋操作（包括指令碼介面和 TrainzUtil）中，該資產將被視為每個列出的資產組的成員。
如果未為給定的“member-of-groups”容器指定任何條目，或者如果資產省略了“member-of-groups”容器，則模擬器軟體可能會根據資產的 Config.txt 檔案指定一些預設資產組。模擬器不同版本之間的確切行為可能會發生變化，但是當前邏輯在 此處 描述。
- 以下標籤對於任何資產都不是強制性的，許多資產將其留空。
- 從歷史角度來看，標識和許可標籤始於 Trainz 0.9（Beta）。
- 型別：UTF-8 多行字串。（已透過程式設計師命令棄用。）
- 欄位定義：描述資產建立者希望如何使用該資產的許可證。最常見的是許可證宣告禁止在任何付費路線、依賴資產（例如轉向架、聯軸器等火車部件）或重新繪製中使用受版權保護的資產，包括在任何付費運營的網站上分發該資產。（從理論上講，即使是 DLS 也是如此。FCT 費用用於更快地訪問和無限下載，而不是用於訪問資產。）
- DLS 上的大多數資產都是對被稱為 Creative Commons Attribution-ShareAlike 3.0 Unported License（CC-BY-SA）的許可證的措辭不當的版本，例如本維基專案和其他維基媒體維基專案。
- license 標籤的含義不明確，N3V 不建議使用它，但它的出現早於 N3V 的管理 6-7 年。
- 上傳到 Download Station 或提供用於包含在遊戲中的內容可能受特定再分發合同或許可協議的約束，該協議取代該欄位中的任何文字。license 欄位不提供本地化支援。license 欄位的文字未經 Auran 或 N3V 驗證或強制執行，並且可能對終端使用者具有法律約束力，也可能沒有法律約束力。
- 另一方面，Planet Auran 的歷史表明，有人透過使用他人的內容冒充自己來侵犯版權，可能會導致其迅速被禁止訪問 Auran 網站並失去下載站特權，等等，並永久封禁。此外，社群將嚴厲打擊其他使用者侵犯他人的版權行為，並排斥違規者，並忽略任何允許保留在 DLS 上的資產。
- 總而言之，實驗和修改資產是 Trainzer 嘗試攀登陡峭的內容創作學習曲線的一種被接受甚至被認可的生活方式（每個人都希望有更多內容創作者！），但如果資產具有依賴部分，尤其是網格、指令碼、紋理等，這些是智慧財產權——在上傳您的作品之前，請獲得使用他人作品的許可。
|
|
- 型別：UTF-8 字串。（已棄用，取而代之的是可更新的 Planet Auran 資料庫。）
- 欄位定義：作者的姓名或標識。不建議使用該欄位，因為屬性可以透過程式設計方式確定。
- 注意英國拼寫，北美拼寫“organization”也可以！
- 型別：UTF-8 字串。（已棄用，取而代之的是可更新的 Planet Auran 資料庫。）
- 欄位定義：負責建立該資產的組織的名稱或標識。不建議使用該欄位，因為屬性可以透過程式設計方式確定。
- 型別：字串，電子郵件地址。（已棄用，取而代之的是可更新的 Planet Auran 資料庫。）
- 欄位定義：該資產建立者的聯絡電子郵件地址。不建議使用該欄位，因為屬性可以透過程式設計方式確定，並且可以針對建立者的 Auran 帳戶 Planet Auran 帳戶 註冊聯絡方式，並在那裡可以限制或更新它們，具體取決於需要。
- 型別：URL 字串。（已棄用，取而代之的是可更新的 Planet Auran 資料庫。）
- 欄位定義：該資產建立者的聯絡網站。不建議使用該欄位，因為屬性可以透過程式設計方式確定，並且可以針對建立者的 Auran 帳戶 Planet Auran 帳戶 註冊 [聯絡方式]，並在那裡可以限制或更新它們，具體取決於需要。
|
|
- 在初始編譯之後，在資料模型的舊版本中發現的一些常見但現在已過時的標籤已新增到下面，例如在許多橋樑資產中發現的 bendy 及其下面的朋友。
|
|
- 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 標籤
[edit | edit source]- 範圍：在 v2.9 標準之前，在 軌道或橋樑資產 中找到，當時樣條線物件經歷了重大更改，轉變為統一的資料模型定義，放棄了混合中的幾個先前的 KIND，轉而支援所有樣條線物件在 kind track 下統一。
casts-shadow 標籤
[edit | edit source]- 請參閱上面的 bendy，已棄用/過時的 TS2009 之前的遺留 kind track 標籤。
name 和 name-XX 標籤
[edit | edit source]- '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 存在，則直接刪除。
- 如果資產的 trainz-build 版本為 v2.7 或更高版本，則 name-XX 會導致錯誤。有趣的是，即使在 TS12 這樣的晚期版本中，name-XX 標籤也會在 Surveyor 工具的搜尋列表中顯示為資產名稱，如果不存在，則會顯示 TrainzBaseSpec。
|
|
category-era-nn 標籤
[edit | edit source]- 已被 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 檔案的單行上[note 12]。雖然在 Surveyor 中無法直接訪問，但在 TR06 和 CMP 之後，可以定義一個過濾器以選擇日期範圍，並將該過濾器與區域和型別一起使用，在 Surveyor 中審查可以在 Surveyor 的放置和選擇工具中列出的資產。在 TS09 及更高版本中已棄用，TS09 使用更短的 category-era 標籤 字串陣列 在單行上，而不是使用多個 '-nn' 字尾的標籤-值對。
- 字串陣列中的空格會導致錯誤；所有值都必須以 's' 字尾結尾，並且必須包含四個數字，例如 1880s;1950s;2010s（對於某些型別的女士服裝來說可能非常合適，這些服裝的流行會隨著時間推移而起伏！）。遺憾的是，目前無法定義範圍，但使用者社群已經提出了請求。
- 替換為字串陣列型別的 category-era 標籤，在日期程式碼之間沒有空格和分號；這些程式碼以完整的四位數年代數字開頭，後跟 's'（小寫字母 s）字尾。
category-region-nn 標籤
[edit | edit source]- 已被 category-region 標籤 取代
- 型別 category-region-nn — V1.3–v2.8 —在歷史上幾乎所有與位置相關的資產中都能找到。這些已被 category-region 標籤中的 兩個字母的列舉 ISO 國家程式碼 '字串陣列' 取代。
- 替換為字串陣列型別的 category-region，在兩個字元的國家程式碼之間沒有空格和分號，這些程式碼在引用的標籤部分中列舉；這些程式碼以完整的兩個大寫字母開頭，構成 列舉 程式碼，在程式碼之間使用 ';' 分隔符，但在最後一個程式碼之前的末尾引號之前不使用。
- 字串陣列中的任何 空格 都會導致讀取錯誤和錯誤訊息，包括結尾引號之前的空格。
- region —TBS V1.3–v2.8 中有效的內建過濾器和地圖資產自定義本地化識別符號 (kuid)；現在，唯一合法的標籤使用是在 kind map（佈局）資產中。
- 作為以前的過濾器修飾符，該標籤在歷史上幾乎所有資產中都能找到，但它在車輛、場景、樣條線資產、軌道型別（包括隧道和橋樑）以及具有本地化程度的軌道旁資產中尤其常見。
- 地圖資產仍然保留了在 Map 配置檔案中定義的關鍵詞 Region，其使用方式相反——作為 kind region kuid 引用。因此，Region 在 Map 中是必需的，並且自 TS2012 起，就像標籤型別一樣，它在曾經作為 TRS 系列版本 Surveyor 工具視窗的 '分組資料' '快速過濾器' 出現的眾多資產中是非法的。
- 在 TRS2009 之後，任何指向文字字串的 region 標籤都已過時，因為在程式設計師的意識中，他們用 Pick List 取代了 Surveyor 工具中的 '型別和區域' 字串值的 粗略過濾 分組選擇器。這兩個標籤都有一些優點和缺點，並且都追溯到 Trainz 0.9 Beta 版本。
shadows 標籤
[edit | edit source]- 請參閱上面的 bendy，已棄用/過時的 TS2009 之前的遺留 kind track 資產模式控制標籤。
thumbnail 標籤
[edit | edit source]thumbnail 標籤是 thumbnails 容器 的早期單檢視實現（上面也有簡要介紹）。早期 Trainz 的 N3V 之前的程式設計師版本會在主資產根資料夾或 asset-name_art 或 asset-name_body 資料夾中找到一個 .jpg 檔案，最好是 240x180 畫素，並將其用於在 CMP 和 DLS 中顯示資產（如果已上傳）。該標籤在 TRS2006 期間已被棄用，因為 thumbnails 容器是在 v2.0（TRS2004-SP0）中引入的。在舊的已修復資產中，如果 TBV 保持在 v2.4 以下，則 thumb 通常仍會在更新的 CM 中正常工作，前提是它位於 _art 子資料夾中，並且 asset-name 與 username 匹配。
- 型別 — V1.3–v2.8 — 以前的一種過濾器修飾符，在幾乎所有資產的歷史記錄中都可以找到，但在滾動庫存、場景、脊柱、軌道型別（包括隧道和橋樑）和路邊資產中尤其普遍。
- 型別標籤，就像“區域標籤”一樣，在 Trainz 0.9—TC3 版本中用作“Surveyor 組內過濾器”，它與區域結合使用，可以提供更小的資產選擇（工具組）。自 TS2009 移除這些區域性可點選過濾器，轉而採用一種新的、更繁瑣的過濾器。這些工具選擇變得快速而簡單，而不是在工具選項卡之間切換時緩慢和暫停 - 如今的 TANE 之前的版本在工具選項卡之間來回切換時，通常會因重新載入整個選擇列表而不堪重負。
- 型別和區域都預設設定為“全部”，從而提供與 TS09 及其後的工具相同的超大型列表。
- ↑ 資產 提交（TANE 的提交）是將內容整合到資料庫中並將其交叉引用到 DB 索引中的過程和步驟，以便可以在執行時模組中訪問它。
- ↑ 驗證資產的一種方法是，除了這些值之外，其他方面都很好，可以將 TBV 降低到 2.5-3.7 範圍，看看這些訊息是否消失。您可能需要嘗試多次降低它，直到足夠低，反過來也可能起作用，在較舊的 TBV 中無法識別的較新關鍵字可能會顯示不同的錯誤訊息。不要害怕嘗試 - 即使在這種情況下失敗也會產生知識和經驗，而且您不會破壞任何東西！如果是這樣，您可以確信，只提供一個值就是問題的解決方案。通常，一些現代需求只需要關鍵字對，因此在標籤後面加一個空行或在標籤後面加一個空的方括號集來表示容器，就可以滿足需求，而錯誤測試有點過於嚴格。
- ↑ 注意： 此列表在 N3V TrainzOnline Wiki 上是“維基化”的，這意味著“KIND”一詞後的第一個字母已大寫，而 config.txt 檔案中的實際資料標籤名稱全部是小寫文字。該維基還使用雙引號來表示相當多的術語，這種做法我們將在此處避免。
- ↑ “kind consist” 並不經常直接看到，它只是存在於選單和內容管理器列表中。
- ↑ 必須謹慎使用過時表，並且最常見於 Auran 創作的資產中。該表用更新的版本替換了舊的 kuid，大多數內容建立者正確地使用 kuid 的 Kuid2 形式來取代舊版本。相比之下，N3V 過度使用了過時表來表示新發布的“升級”內建資產，這會導致很多混淆，並且無法獲得人們期望看到的資產。（例如，許多漂亮的 'Flip-trees' 在 TS10 和 TS12 中被 Speedtrees 取代，這影響了許多路線，因為建立者並不希望或需要 Speedtrees。在安裝過程中，這還會導致缺少依賴項，直到找到包含過時表的資產。
• 此外，在 Assets.tdx 資料庫索引中，每個 kuid 只支援一個過時條目，並且用 Kuid2 版本來使 kuid 過時會導致問題（即，您將看到哪個？）。
• 過時表的一個極好的用途是使用特定部件（尤其是轉向架）升級一系列資產。新增要被更新的良好轉向架取代的一組 kuid 可以顯著改善路線或會話的外觀（前提是轉向架例如相容且尺寸合適！） - ↑ 最近將過時資產引入 TANE 的經驗表明，有不止 5 種替代 kuid 使那個可憐的 Flip-tree 資產 過時。在 Speedtrees 引入和 TANE 大修（其積極尋求最更新的適當資產）所造成的混亂之下，看來現在在 ContentManager 程序中容忍多個具有不同 kuid 的資產使同一個 kuid 過時。作為一種良好的實踐，只有在絕對必要時才使用過時表... 例如，在您要上傳到 DLS 或在網站上自行釋出的依賴資產中，用它來取代不想要的付費資產。
- ↑ 關於類別時代標籤範圍：安全起見，已知有效。其他“未來十年”值應在依賴這些值之前進行測試。
- ↑ 許多容器在列表中使用虛擬/佔位符名稱。這些可以是描述性詞語，只要它們不包含空格字元。在短語構造的名稱中使用下劃線或句點可以保持可讀性，並顯著提高畫質晰度。例如，貨運車廂可以裝載 45 種合法產品型別。這些將列在依賴項容器中。使用 Coal、granite、crushed_limestone 等可以使維護和更改表格變得更容易。從 76 年開始做程式設計師的 Jes Sayin'
- ↑ 在第二個縮圖容器示例中，有一個第二個 512x512 尺寸的影像，即額外的影像。DLS 將使用哪一個尚不清楚。也可以包含更大的影像尺寸，並且透過電子郵件聊天，T:ANE 可能會支援一個較大的影像尺寸，該尺寸將在預覽操作或 DLS 列表中找到用途。N3V Games 通常不會發布此類資訊。
- ↑ 早期的做法可以追溯到 Trainz 1.x，即使用關鍵字/標籤“thumb”以及帶引號的路徑規範引用，來引用執行時選單的 240x180 縮圖影像。藝術資料夾包含一個帶有 alpha 遮罩（通常為 bmp 檔案，但格式正確的 tga 可以用作自遮罩）的 512x512 tga 和 64x128 選單圖示影像及其控制紋理 texture.txt 檔案。
- ↑ 在 2014 年至 2015 年冬季與前版本經理 James Moody 進行的私人電子郵件交流中，在這一點上，DLS 上傳審查軟體可能已被修改，以強制執行適當的縮圖容器。
- ↑ 關於類別時代-nn 與類別時代標籤值： TRS 會接受類別時代資料的兩種形式；但是 TS2009-SP0 及其後的版本會從以前合法的關鍵字-值對中建立錯誤，並試圖迫使內容建立者更改程式設計師故意破壞的所有資產。後來，DLS 上傳軟體強制執行了這些轉換，但這要好得多，因為第一個操作會導致人們花費很多時間來修復一些不必要的更改，而這些更改本來應該在審查舊 Trainz 構建資產時自動透過軟體預過濾傳遞來實現。這些操作幾乎可以肯定的是，舊資產的下載將會有錯誤。這是 N3V 程式設計師做過的最愚蠢、最傲慢的事情之一，Auran 更有經驗的軟體人員永遠不會對社群的時間成本如此漫不經心。
- 本頁面的主要內容來自 N3V TrainzOnline Wiki，網址為 KIND_TrainzBaseSpec。Yesterdayz-Trainz 使用者組的成員添加了更多資訊。
- ↑ N3V 的 KIND_TrainzBaseSpec，未經修改的源頁面，缺少此處找到的歷史資訊（標籤）；訪問日期：2014 年夏季
- ↑ a b "Trainz-build" 標籤 直接連結
- ↑ 根據 fabartus，2014 年夏季；可能是在新增此示例的同一天。
- ↑ Christoph Bergman，N3V Games 首席程式設計師，又名 'Windwalkr'，KIND TrainzBaseSpec 歷史記錄 頁面。
|
本參考頁面改編自 TrainzOnline Wiki，根據 CC-BY-SA 3.0 許可。本頁面可能會包含比 同一主題的源頁面 更多文字說明、解釋、歷史和/或示例。 TrainzOnline Wiki 主要由程式設計師或瞭解 內容建立者 維護，並且可能包含有關當前 trainz-build 程式碼 標準的更新資訊，這些標準在軟體新增功能時會有所改變。 |