Trainz/refs/TrainzBaseSpec
KIND TrainzBaseSpec 為所有 Trainz 資源型別在所有 config.txt ini 檔案 中提供基礎定義。TBS 提供了一些“標準標籤”，這些標籤對所有 Trainz 資源（至少可以合法地定義）都是通用的[1]。
- 其中一些是強制性的，因為它們決定了資源的進一步處理以及 config.txt 檔案和其資料夾中資源資料的解釋。
- 然而，大多數都是可選的，並且在大多數子資源中可以省略使用標籤的定義行。
父類
[edit | edit source]- 沒有，有效且大多數對於所有由預設父容器定義的內容都是必需的，即所有 Trainz 數字模型所需的 config.txt 檔案。KIND TrainzBaseSpec (TBS) 是一個根類，其他 Trainz 資源類都是從它派生的。
- 之所以說它們是派生的，是因為它們繼承了處理屬性（指令）和其中列出的引數定義的值，其中關鍵的一個是 kind 標籤的值。這個列舉的詞語決定了資源的特定 種類宣告和要求，這些要求將新增到該資源 config 檔案中的 TBS 定義中。其他關鍵的 TBS 定義資料也具有明顯的意義和實用性，例如資源的名稱、Kuid 識別符號和版本、Trainz 構建值 (TBV)，以及其他對定義、適用性和範圍有廣泛變化需求的資料，例如string-table、obsolete-table、kuid-table 和縮圖都是偶然的。字串值，甚至資源名稱和描述在實踐中大多數時候都是完全沒有必要的，完全可以省略。
- 當聲明瞭一種種類時，該種類將成為父類，要求並規定該類中必須滿足的必要資料對，除了 TBS 中列出的資料之外。
- 某些引數可能在資源種類的某個特定情況下保持未定義，尤其是一些常見的舊歷史 Trainz 構建標籤值，對於這些標籤，內容管理器或 Content Creator Plus (CCP) 實用程式將分配預設值，但在處理時會列出警告訊息。TrainzOnline Wiki 中的許多標籤，以及更早的 TC3 時代 Content Creator's Guide (CCG) 中都會提到預設值。
- 從 TRS2006 和 Trainz Classics (TC1&2) 開始，每個版本的 Content Manager 模組都會強加越來越多的預先承諾錯誤測試[note 1]，並且每個模組都變得越來越堅持，強調在預期存在這樣的標籤-資料對時，如果未定義這樣的標籤會發出警告。
在 TANE 後版本中，這些過去“預設”的定義行現在往往會產生故障，要求清晰的值定義，而過去這些值是預設的[note 2]。與過去那些年代相比，這是一種更可取的煩人之處，在過去那些年代，錯誤的資源定義有時會導致臭名昭著的“藍色畫面宕機”，或者更常見的是，導致執行時軟體崩潰回桌面，導致編輯丟失，並可能需要重建資料庫。
子類
[edit | edit source]
所有 Trainz 定義的資料（內容）都有三個必需的元素：一個 config.txt 檔案 來組織資料，一個標識，即 kuid（只有使用者名稱對你沒有用，但是可以建立合法資源，不需要名稱！）和最後，一個合法定義的種類標籤。種類負責，它是管絃樂隊的指揮，是排長或 CEO，負責下達指令——為所有後續處理內容設定要求。簡而言之，種類的值是一個緊密定義的成員限定的小組——告訴 Trainz 軟體在虛擬世界中要渲染和顯示什麼，以及如何在 config.txt 檔案中找到將這些資源部分連結在一起的其他部分。
以下每個子類都被認為具有 TrainzBaseSpec 作為它們的“父類”資料[note 3]。下面列出的幾種種類（帶下劃線的）是過時的種類，早於 TS2009 版本中對 Trainz 資料模型 進行的更改（即從 2008 年後期開始），N3V 程式設計師自此只對這些種類進行了逐漸（增量）的更改。
目前可以在 N3V Trainz Wiki 的 Content Creator's Guide 部分中找到有關修復基於這些過時種類的資源的詳細資訊TrainzOnline 站點在此，其中包含啟發性的 過時種類的示例在此。強烈建議 Trainz Download Station 的所有使用者或任何考慮建立內容的使用者仔細閱讀 CCG。通過了解過去內容定義方式的背景歷史可以獲得的見解，可以與 TrainzOnline 對同類資料的當前覆蓋範圍進行對比，因為這種過去與現在的對比往往可以為修復、更改和定製資源提供寶貴的見解。更重要的是，CCG 中的文字是專業製作的，而且更具解釋性——它往往會告訴你如果更改了某些內容，會產生哪些擴充套件影響，而 Trainz Wiki 卻沒有提供這些內容。TrainzOnline 上釋出的 CCG 是 TC1&2/TC3 版本——幾本小冊子中的最後一個已釋出版本，這些小冊子可以追溯到 1999 年的 Trainz；TC3 CCG 包含來自 TRS2004/TRS2006 和 UTC 資料模型的已更改的 Enginespecs 機車資源，需要進行適當的更新。
TBS標準定義
[編輯原始碼]這些標籤和容器是標準定義，幾乎所有資產中都會找到它們。一些標籤是可選的，內容建立者可以根據自己的選擇來定義。標籤是關鍵詞，並具有一個指定的鍵值或容器，例如字串陣列或'{' ... '}' 繫結的封閉標籤-值對或子容器。（Trainz配置檔案中宣告的所有內容都是成對的，因為即使 '{' ... '}' 也被認為是一個'鍵值'。
- 容器是'鍵' 和 '鍵值' 對的集合，並且 TBS 中的 '上層容器'（與子容器（例如縮圖容器中的子容器）相反）通常以 '-table' 為字尾。
| 種類 | "'字串值'" |
| trainz-build | '浮點數', 1位小數 |
| kuid | <Kuid編碼值> |
| 使用者名稱 | 使用者名稱 "'字串值'" |
| 使用者名稱-XX | 使用者名稱-XX "'字串值'" |
| 描述 | 描述 "'字串值'" |
| 描述-XX | 描述-XX "'字串值'" |
| kuid-table (容器) { 依賴項列表 |
一個鍵值表，列出所有此資產依賴的資產。 |
| obsolete-table (容器) { } |
kuid列表，此資產替換的資產（使其過時） 通常為空（空）[註釋 5] |
| string-table (容器) { } |
資產中使用的字串和訊息的鍵值列表 通常為空，在路線和場景中很大。 |
| string-table (容器[s]) { 非英語 語言文字 } |
翻譯後的字串列表與強制性的英語string-table匹配 |
| 類別-地區標籤 列舉 程式碼 | 類別-地區 "'字串陣列'" |
| 類別-類別標籤 | 類別-類別 "'列舉 字串值'" |
| 類別-時代標籤 | 類別-時代 "'受約束的字串陣列'" 年代 |
| 類別-關鍵詞 "'字串陣列'" 最長64位元組 | 類別-關鍵詞標籤 自然語言搜尋關鍵詞 (替換型別、地區) |
| 自定義類別列表 "'字串陣列'" |
指令碼介面功能 |
| 必須擁有產品許可權 "'字串值'" |
DRM字串陣列 |
| 不得擁有產品許可權 "'字串值'" |
DRM字串陣列 |
| 許可權 (容器) { } |
更多DRM |
| 縮圖 (容器) { } |
縮圖容器 |
| 指令碼 (檔名) | "'字串值'" |
| 類 (指令碼資產類) | "'字串值'", 必須與指令碼規範類同步。 |
| script-include-table { } |
(列出庫指令碼的容器) |
| 擴充套件 (容器) { } |
資產也使用的正式指令碼擴充套件 |
| 許可證 "'字串值'" | 資產建立者的版權宣告 |
| 作者 | "身份 '字串值'" |
| 組織 | "第三方組身份 '字串值'" |
| 聯絡郵箱 | "郵箱地址 '字串值'" |
| 聯絡網站 | "作者/組的網頁連結 '字串值'" |
| 所屬組 (容器) { } |
一個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 版本號 完全匹配，但以下情況除外
- 分配給 V1.4 的 TBV 或版本值是 Auran 的 Paintshed 版本，這是一個也適用於 Microsoft Trainz Simulator (MSTS) 的重繪工具，並且也作為 TRS2004 輔助軟體模組的構建值出現；具體來說，它是 ContentManager.exe 實用程式。
- 1.7 和 2.0 之間的差距要麼是外語版本，要麼是在經過幾個小時的挖掘和研究後似乎更有可能的是，Auran 沒有使用，因為在構建最初 Trainz 的程式設計師團隊的眼中，無論前臺如何炒作營銷名稱（比如 Trainz UTC，是終極的任何東西…… 真的嗎？。拜託！真的嗎！？），TRS2004 版本是第二款 Trainz 產品。
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 無 Service Pack）開始遞增 0.1，直到目前的版本（v3.7 = TS12-SP1，v3.8 = Mac2，3.9=TANE-CE，4.0—4.3 以及之後？從 2016 年 3 月開始，4.3 及以上版本是 TANE SPs TBDL）。
- 從 v2.0 (TRS2004) 開始，Trainz-build 標籤數字值已經透過 23 個步驟遞增，這些步驟是連續的，儘管不是單調遞增的，因為 Trainz TS09-sp3—TS09-sp4 共享一些 Trainz-build[2] 值；也就是說，在 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_file 的內容來猜測一箇舊版 Trainz 版本，通常會解析為 1.3 作為 TBV。
使用者名稱標籤
[edit | edit source]- 型別: UTF-8 字串，資產的 使用者名稱，**必填** 規範。
- 欄位定義: 此資產的 **英文** 人類可讀名稱。
在 TC1&2（v2.7）之後的 trainz-build 中，使用者名稱在編輯資產時也變成了作業系統資料夾名稱，並且資產檔名被忽略，而在 v2-6 配置檔案中，它具有優先權。根據 N3V games 的 TBS 標準，此欄位 絕不包含非英語文字，除非資產名稱是專有名詞（例如地名），並且沒有英語本地化變體。此值是每個人通常搜尋和記住的資料，因此建議保持一個清晰的名稱。
 |
|
使用者名稱-XX 標籤
[edit | edit source]- 型別: UTF-8 字串，使用者名稱標籤 的替代語言版本。
- 欄位定義: （其中 XX 被替換為適當的 本地化程式碼，用於表示正在使用的語言。）此資產的本地化人類可讀名稱。此欄位類似於 使用者名稱 欄位，但表示非英語語言環境。資產中可能存在多個 username-XX 標籤，每個支援的語言環境一個。如果適當的“username-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 字串列表容器，字串表容器。
- 欄位定義: **英文** 字串的鍵值對列表。每個鍵都是一個有意義的指令碼識別符號，對映到二進位制資料並由其引用。每個值都是一個 **英文** 字串。英文字串可能包含或引用非英語專有名詞作為識別符號。非英語母語作者必須在需要時建立一個沒有後綴的字串表容器。軟體只連結到字串表容器中的名稱和值並引用它們，而不使用字尾，這將使西班牙語、法語、德語、捷克語、荷蘭語……日語作者感到困惑。換句話說，帶字尾的字串表僅用於翻譯目的，這在用非英語編寫地圖時會造成問題——沒有字串表-en 可以提供一個用於反向翻譯的表。同樣，username-en 和 description-en 也是如此。這三種缺失都體現了一種陳舊的、傲慢的、對世界動態的漠視。
其他語言透過類似的字串表（例如字串表-XX）獲得支援，這些字串表具有與描述和使用者名稱關鍵字/標籤的國際化字尾匹配的本地化程式碼字尾 (XX)，但這些語言鍵字串表容器的左側條目將始終具有相同的鍵值。
- 這些左側的鍵或標籤既充當 “本地索引關鍵字”，也充當 “語言之間的等效表”。
- 左側列始終包含內容建立者賦予“特殊”名稱的物件，例如訊號、軌道標記、行業、連線等名稱，這些名稱可能會被引用，並且會出現在 Driver 和 Surveyor 模組的“查詢公用設施” (CTRL+F ) 功能小程式中。
- 另一方面，索引側也 *不會列出* 地點（例如大量連線）的預設名稱，這些地點在構建路線圖時會由隨機數自動索引（即無意義的雜亂。如果重要，路線構建 CC 會命名它！），但會自動包含潛在的臨時資產，例如火車車的預設名稱。如果重新命名，這些名稱將取代其相應的預設名稱。
- 它的主要用途是針對那些旨在與指令碼引用介面並獲取可變屬性的物件，例如火車站、行業所需的或準備運往行業的貨物數量，或由互動式火車車（向指令碼滾動行業）和其他可配置資產（如通用廣告牌式標誌）運送的貨物，透過稍微調整高度和角度扭矩，可以將這些標誌放置在庫存建築或行業的立面前，在建築上放置不同的商業名稱。換句話說，這是一種可配置的風景。
- 總體而言，在 路線圖或佈局 中，這些左側名稱對應於地圖資產上的命名物件，而大多數字符串表（從字面上看，由大型路線 kind map 中的數千個條目填充）都是在那裡看到的。
- 在某些資產中，該預設名稱連線到軟體指令碼，因此字串表變得 *特別重要*，而不是 *平淡無奇*。（見下文）
- 在每種型別的資產中，字串表型別的使用始終是合法的，就像描述標籤、trainz-build 和 kind 標籤一樣。與它們不同的是，它不必存在或定義，也不是強制性的。封裝在字串表容器中的值除非程式碼期望它們配對，否則沒有功能或效果。
- 在其他資產中，再次以假設的可程式設計商業標誌為例，如果字串表要與軟體介面，則必須為其提供預設名稱。所有地圖可放置資產都可以命名或重新命名，但“特殊名稱”必須在指令碼和字串表索引值中匹配。大多數可配置資產定義了一個介面變數，該變數用於將預設名稱替換為指令碼引用的索引或查詢表，以及資產的二進位制資料。其他變數也可能在可程式設計資產中定義。這些變數中的每一個都可能被指令碼引用，但正是索引值使其進入地圖或會話字串表，從而使一切在需要 Driver 或 Session 建立者可變性時協同工作。
- 相反，如果沒有系統軟體知道索引中命名的專案的地址，則物件的指令碼可能沒有觸發、條件檢查或更新能力。這正是 2000 年代 Trainz 1.0 中物件的特徵，而 2003 年釋出的 TRS2004 以來的現代 Trainz 鐵路模擬器則不然。（從那時起，我們已經取得了長足的進步！）
- 有些資產只能作為一個組一起工作。在這種情況下，在對映或會話層中命名每個資產將使它們能夠協同工作。例如，考慮一個擁有五條軌道的公路平交道，其中兩條軌道是脫離連線的，並與透過軌道形成所謂的 '交叉交叉'。如何設定訊號，以便任何鐵路交通都關閉公路閘門，或者使用交叉交叉不允許其他列車穿過正在穿過交叉的列車？道路和鐵路訊號以及道岔和閘門都必須協同工作。由字串表連線的某些“ATLS 系統”資產及其指令碼可以使這個複雜的系統發揮作用。
- 請參閱 string-table-XX 以獲取更多資訊。
string-table-XX 容器
[edit | edit source]- 型別: UTF-8 字串列表容器，即 **本地化字串表**，每個字尾對應於除英語以外的語言。
- 欄位定義: （其中 *XX* 被替換為表示該語言的適當 本地化程式碼。）該欄位類似於 *string-table* 欄位，只是表示非英語區域設定。
英語字串表（無後綴）是強制性的，其他本地化語言是可選的，由資產作者決定。提交到 DLS 的許多資產，然後也在捆綁在 Trainz 版本中的路線中使用，通常會進行翻譯，並具有完整的一套本地化翻譯，用於 description-XX 和字串表。尤其是，捆綁在某個版本中的路線和會話會在每次零售版本釋出時收到專業的多語言翻譯。
請注意，字串表的左側列是相同的，因為它是一個對映的符號表，並索引到二進位制資料（例如網格、會話或路線檔案）。只有使用名稱（兩個元素的右側或資料元素）是本地化的，並被執行時本地化軟體替換。如果需要，這些名稱可以在英語字串表中手動編輯，以獲得更友好的名稱。索引或左側引用列語法絕不能更改，因此在資料列中更改名稱時請小心使用全域性 SAR 規範。
資產中可能存在多個 *string-table-XX* 標籤，每個支援的語言一個。每個標籤都應包含一個字串列表，該列表與 *string-table* 列表中的鍵相同，但值不同。如果不存在適當的“string-table-XX”標籤來表示給定終端使用者系統上的此資產，或者該列表中缺少適當的字串，則將引用英語 *string-table* 容器。
kuid-table 容器
[edit | edit source]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-table。大多數具有子元件的資產只有幾個。
- 其次，有一個約定來自這樣一個事實，即有時內部關鍵字是“自動定義”的——僅列出為一個沒有名稱的數字，作為 佔位符引數，偽關鍵字可以是任何唯一的值（通常是零索引的連續整數。[notes 1]）它們可以根據使用者或作者的喜好被命名或不命名。
- 此表中的條目有兩個目的
首先：確保遊戲系統知道依賴關係，以便安裝和載入此資產將成功安裝和載入任何依賴關係，以及
其次：允許指令碼定位相關的子資產。 - 僅應將一級依賴關係包含在 kuid-table 中——具有自身依賴關係的子級或部件資產將在該子資產的驗證和資料庫提交中進行處理。
- 迴圈依賴關係是非法的。
- 如果資產也被標記為此資產的過時版本，則該資產不能被列為依賴關係。（Trainz 資產索引（歷史上是 assets.tdx 檔案）中只有一個替換 kuid 槽，這將建立一個迴圈定義，要求它自己的舊版本！）
- 同樣，資產不能被列為其自身的依賴關係。[OTOH，這是有經驗的（即在 TSxx CM 中被證明為成功無故障提交的資產）將地圖和會話移植到安裝之間，使用 GSARS 更改 kuids，以便重疊不會覆蓋已經在目標安裝中使用相同 kuid 的資產，而不會看到錯誤訊息。] 是否也起作用了，需要一個比我更勇敢或更愚蠢的人！--Fabartus，編輯。
- 格式 (所有值都為 <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 表格容器 格式相同。
- 欄位定義： 由此資產使之過時的資產的“佔位符鍵-鍵-值”列表。嘗試載入此列表中的任何資產將導致載入此資產。
- 此外：兩個資產都標記第三個資產為過時是不合法的，除非其中一個也標記另一個為過時。[註釋 6]
- 迴圈過時引用是非法的。
- 此資產的所有低編號 KUID2 版本都隱含為過時，無需包含在此列表中。同時，較新的改進資產（具有較高的 KUID2）及其前任不應在“中間”前任中列出同一個前任（如原始資產！），因為這些值用作替代條目表，並且只有一個資產可以替換為較早的版本。（陣列只儲存一個值，不能用兩個值替換一個值！）。
- 標記此資產的更高編號 KUID2 版本為過時是非法的，因為這會建立隱式迴圈引用。
- 此列表中引用的資產必須與此資產具有相同的建立者，以便資產透過 DLS 上傳過程稽核和接受，此限制不適用於您的本地版本，例如，它可以用於將大型火車車廂組中的所有舊紙質車輪 KUID 替換為一個更具視覺吸引力和更新的 KUID。
- 目的：在 CM 和 Surveyor 中進行篩選（搜尋條件）
- 型別： 列舉字串或字串陣列。
- 欄位定義： 由分號 (;) 分隔的兩個字元 類別-區域標籤 程式碼列表。字串中不應存在其他字元（包括空格等）。此資產被認為與每個指定的區域相關 - 這對於 kind traincar 和 kind mosignal 資產最相關，但可以為任何資產提供。
- 示例
- 類別-區域 "CA;US"
- 類別-區域 "CA;MX;US"（北美國家：加拿大、墨西哥、美國）
- 類別-區域 "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 個字元 類別-類別 程式碼。類別-類別 標籤用於提供超出資產型別隱含的附加的人類子類別。每個 Trainz 資產的類別-類別標籤有助於描述資產在遊戲中的“意圖”，而不是資產的內部結構。
|
|
請注意，許多類別-類別程式碼只與特定資產型別相關 - 類別-類別程式碼不能應用於不合適的資產型別。
- 示例
| 類別-類別 "XBG" | 貨車 - 來自 PRR 60' | |
| 類別-類別 "BR" | 鐵路（非功能性風景）——可能是一座建築 | |
| 類別-類別 "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"
}
}
另一個常用大小是 128x64 的“圖示”，用於 排程場 和測量員資產選擇 API，它應該具有 Alpha 遮罩 或非常淺的背景。許多較舊的資產沒有使用 jpg 檔案，而是將 .tga 檔案（Targa 真彩色）列在 '_art' 子資料夾中（Trainz 1.0-TC3 慣例：_art、_body 和 _shadow 是早期 Trainz 資料模型要求規定的三個子資料夾，名為“asset-filename_suffix”（過時標籤-<值> 對），它看起來像下面這樣[註釋 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 修補程式後被放棄，因為使用者社群中出現了許多抱怨。
• 如果缺少縮圖容器的資產（即使具有過時的縮圖標籤）後來在新的內建路線或場景中被選擇，該資產通常會作為沒有影像的專案進行分發——如果紋理文字或配置文字縮圖容器未正確引用，它們將被剝離[註釋 11]。
- 型別： URL 字串。
- 欄位定義： 指向資產線上描述、資產說明（幫助）或 TrainzOnline wiki 上其他幫助頁面的連結，旨在從嵌入式特殊用途 N3V 瀏覽器內使用。該 URL 必須解析到 Trainz Online 安全區域 中的網站。目前，嵌入式瀏覽器接受三個域
auran.com
ts2009.com
ts2010.com
此外，建議使用自定義 Trainz 短連結 格式，而不是直接連結到這些域，以防止將來網站佈局發生變化而導致 URL 無法使用。“短連結”是 Trainz 特定的 URL，它有助於透過允許內容建立者引用 N3V 網站上的特定頁面來保護內容免受未來影響，而無需依賴於特定的網站佈局。短連結旨在用於遊戲內使用，例如 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。
script-include-table 容器 是頂級 config.txt 檔案 條目，可用於任何從 KIND TrainzBaseSpec 派生的資產（簡而言之，所有資產）。此容器允許資產直接 包含另一個資產的指令碼 來自父資產的指令碼檔案，使用 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 字串。
- 欄位定義：自然語言關鍵字列表，用分號 (;) 分隔。字串中不應包含其他字元（包括空格或不相關的標點符號）。這些關鍵字是資產關鍵字搜尋的基礎。資產的 使用者名稱 不需要在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 字串|Custom-category-list 字串|Custom-category-list 容器|custom-category-list 容器
- 型別： ASCII 字串陣列容器。
- 欄位定義：自定義類別識別符號列表，用分號 (;) 分隔。每個 自定義類別識別符號 應為一個簡短的（例如 3-6 個字元）字母數字標記。字串中不應包含其他字元（包括空格）。
- 這些自定義類別用於使指令碼能夠快速定位某些類別的資產。強烈建議謹慎地引入新的自定義類別識別符號。
- custom-category-list 標籤值總共不應超過 64 個字元。除非存在僅能透過 custom-category-list 方法實現的現有特定指令碼要求，否則應將此標籤留空。
- 最小版本: V3.5 及以上
- 型別: 成員分組容器 成對列表，包含 佔位符引數 和 資產組 KUIDs。
- 欄位定義: 一個包含 KIND_Asset-group 資產的列表，該資產屬於這些資產。有關如何以及何時使用此功能的詳細資訊，請參閱 kind KIND Asset-group 文件。
該容器包含一個 KIND Asset-group KUIDs 的常規列表。此包含是宣告，在之後，特別是在搜尋操作（包括指令碼介面和 TrainzUtil）中，該資產將被視為每個列出的資產組的成員。
如果為給定的“成員分組”容器未指定任何條目，或者資產省略了“成員分組”容器，則模擬器軟體可能會根據資產的 Config.txt 檔案指定一些預設資產組。 不同版本的模擬器之間的確切行為可能會改變，但是當前邏輯描述 這裡。
可選的已棄用標籤
[edit | edit source]- 以下標籤對於任何資產都不是強制性的，許多資產將它們留空。
- 從歷史上看，識別和許可標籤從 Trainz 0.9（Beta）開始。
許可
[edit | edit source]- 型別: UTF-8 多行字串。（已根據程式設計師命令棄用。）
- 欄位定義: 描述資產建立者希望如何使用該資產的許可證。最常見的是許可宣告，禁止在任何付費路線、依賴資產（例如火車部件，如轉向架、聯接器等）或重製中使用受版權保護的資產，包括在任何付費運營的網站上分發該資產。（從理論上講，即使對於 DLS 也是如此。FCT 費用是為了更快的訪問和無限下載，而不是為了訪問資產。）
- DLS 上的大多數資產都使用的是與 知識共享署名-相同方式共享 3.0 未移植許可 (CC-BY-SA) 類似的文字，就像維基百科和其他維基媒體維基專案一樣。
- 許可標籤的含義不明確，N3V 不建議使用它，但它的出現早於 N3V 的管理 6-7 年。
- 上傳到 下載站 或提供用於包含在遊戲中的內容可能受特定的再分發合同或許可協議約束，該協議會取代此欄位中的任何文字。許可欄位不提供本地化支援。許可欄位的文字未經 Auran 或 N3V 驗證或強制執行，可能對終端使用者具有法律約束力也可能不具有法律約束力。
- 另一方面，Planet Auran 的歷史表明，有人透過將其他人的內容作為自己的內容來侵犯版權，可能會導致從 Auran 網站上被快速封禁，以及下載站許可權的丟失等永久性封禁。此外，社群會嚴厲打擊其他使用者侵犯他人版權的行為，並且會避開侵權者，並忽略任何被允許保留在 DLS 上的資產。
- 總之，對於嘗試克服內容建立學習曲線（每個人都希望有更多內容建立者！）的 Trainzer 來說，實驗和修改資產是一種被接受甚至被認可的生活方式，但如果資產具有依賴部分，尤其是網格、指令碼、紋理，這些是智慧財產權——在上傳您的作品之前，請獲得使用屬於他人的這些部分的許可。
|
|
作者標籤
[edit | edit source]- 型別: UTF-8 字串。（已根據可更新的 Planet Auran 資料庫 棄用。）
- 欄位定義: 作者的姓名或標誌。不建議使用此欄位，因為歸屬可以透過程式設計方式確定。
組織標籤
[edit | edit source]- 注意英國拼寫，“組織”的北美拼寫也適用！
- 型別: UTF-8 字串。（已根據可更新的 Planet Auran 資料庫 棄用。）
- 欄位定義: 負責建立此資產的組織的名稱或標誌。不建議使用此欄位，因為歸屬可以透過程式設計方式確定。
聯絡電子郵件標籤
[edit | edit source]- 型別: 字串，電子郵件地址。（已根據可更新的 Planet Auran 資料庫 棄用。）
- 欄位定義: 此資產建立者的聯絡電子郵件地址。不建議使用此欄位，因為歸屬可以透過程式設計方式確定，並且聯絡方式可以註冊到建立者的 Auran 賬戶 Planet Auran 賬戶，在那裡可以根據需要限制或更新它們。
聯絡網站標籤
[edit | edit source]- 型別: URL 字串。（已根據可更新的 Planet Auran 資料庫 棄用。）
- 欄位定義: 此資產建立者的聯絡網站。不建議使用此欄位，因為歸屬可以透過程式設計方式確定，並且 [聯絡方式] 可以註冊到建立者的 Auran 賬戶 Planet Auran 賬戶，在那裡可以根據需要限制或更新它們。
已廢棄的標籤
[edit | edit source] |
|
- 在初始彙編之後，在資料模型的較舊版本中發現的一些常見但現在已過時的標籤已新增在下面，例如 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
[edit | edit source]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 tag”（或今天的“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-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-nn——V1.3-v2.8——歷史上在幾乎所有值得本地化的資產中都能找到。它們已被category-region標籤中由兩個字母組成的列舉ISO國家程式碼的“字串陣列”取代。
- 替換為字串陣列型別的category-region，標籤之間沒有空格，並用分號隔開，兩個字元的國家程式碼在該引用的標籤部分中列舉；這些標籤以兩個大寫字母組成的列舉程式碼開頭，程式碼之間用“;”隔開，但在最後一個程式碼之前沒有分號，直到結束引號之前。
- 字串陣列中的任何空格都會導致讀取錯誤和故障訊息，包括結尾處引號之前的空格。
- region——TBS V1.3-v2.8中作為內建過濾器和地圖資產自定義本地化識別符號（kuid）的有效部分；現在唯一合法的標籤用法是在kind map（佈局）資產中。
- 作為以前的過濾器修飾符，該標籤歷史上出現在幾乎所有資產中，但它在滾動庫存、場景、樣條資產、軌道型別（包括隧道和橋樑）以及具有某種程度本地化的軌道旁資產中尤為普遍。
- 地圖資產仍然保留了在Map configs中定義的關鍵詞Region，它具有相反的用法——作為kind regionkuid引用。因此，Region在Maps中是必需的，並且自從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程式設計師版本會找到一個.jpg檔案，該檔案最好大小為240x180畫素，位於主資產根資料夾或asset-name_art或asset-name_body資料夾中，並使用它在CMP和DLS中顯示資產（如果資產已上傳）。該標籤在TRS2006期間已棄用，因為thumbnails容器是在v2.0（TRS2004-SP0）中引入的。在較舊的修復後的資產中，如果TBV保留在v2.4以下，則該縮圖通常仍然可以在較新的CM中使用，前提是它位於_art子資料夾中，並且asset-name與username匹配。
- type — V1.3–v2.8 — 以前是一個過濾器修飾符，在幾乎所有資產中都有歷史記錄，但在滾動庫存、場景、脊柱、軌道型別（包括隧道和橋樑）和路邊資產中尤為普遍。
- type 標籤與 region 標籤類似，在 Trainz 0.9—TC3 版本中用作“Surveyor 中的組過濾器”，它與 region 結合使用，提供了更小的資產選擇（工具組）。自從 TS2009 移除這些本地可點選過濾器的功能和使用，轉而使用一個新的、更繁瑣的過濾器。這些讓工具選擇變得快速簡單，而不是在工具選項卡之間切換時變得緩慢和暫停——如今的 TANE 之前的版本在工具選項卡之間來回切換時，常常會被重新載入一整套選擇項所淹沒。
- type 和 region 都預設為“All”，提供了與 TS09 及其後續版本中工具提供的相同的大型列表。
- ↑ 資產 提交（TANE 的提交）是將內容合併到資料庫中的過程和步驟，並在 DB 索引中交叉引用，以便可以在執行時模組中訪問它。
- ↑ 驗證資產的一種方法是，除了這些值之外，其他方面都是可以的，方法是將 TBV 降低到 2.5-3.7 範圍，看看這些訊息是否消失。您可能需要多次降低它，直到足夠低，反之亦然，在較舊的 TBV 中無法識別的較新的關鍵字可能會給出不同的錯誤訊息。不要害怕嘗試，即使失敗也會產生知識和經驗，而且您不會破壞任何東西！如果是這樣，您可以確信提供一個值就是問題的解決方案。通常，一些現代需求只需要關鍵字對，因此在標籤後面新增一個空行，或者在標籤後面新增一個空花括號集，就可以滿足需求，而錯誤測試過於嚴格。
- ↑ 注意：此列表在 N3V TrainzOnline Wiki 上是“維基化”的，這意味著在“KIND”這個詞之後，第一個字母被大寫，而 config.txt 檔案中的實際資料標籤名稱是全部小寫的文字。該維基還對許多術語使用雙引號，我們在此將免除您體驗這種做法。
- ↑ “kind consist” 不常直接看到，它只存在於選單和內容管理器列表中。
- ↑ obsolete-table 必須謹慎使用，最常見於 Auran 編寫的資產。該表用更新的版本替換舊的 kuid，大多數內容建立者正確地使用 kuid 的 Kuid2 形式來取代舊版本。相比之下，N3V 過度使用 obsolete-table 來升級新發布的內建資產，這會導致很多混淆，並且無法獲得預期看到的內容。（例如，許多漂亮的 'Flip-trees' 在 TS10 和 TS12 中被 Speedtrees 取代，這影響了許多路線，而建立者在這些路線中不想要或不希望使用 Speedtrees。在跨安裝中，這也會導致依賴項缺失，直到找到包含 obsolete-table 的資產。
• 此外，Assets.tdx 資料庫索引中僅支援每個 kuid 一個過時條目，用 Kuid2 版本使 kuid 過時會導致問題（例如，您會看到哪個？）。
• obsolete-table 的一個很好的用法是升級使用特定部件的資產系列，尤其是轉向架。新增一些要被更新的好的轉向架取代的 kuid 可以極大地改善路線或會話的外觀，只需一次編輯即可（前提是轉向架，例如，相容且尺寸合適！）。 - ↑ 最近將一個過時的資產引入 TANE 的經驗表明，有五種不同的 kuid 替代了那個可憐的 Flip-tree 資產。隨著 Speedtrees 引入帶來的混淆以及 TANE 的大修，它積極地追求最合適的更新資產，ContentManager 現在允許使用多個不同 kuid 的資產來取代同一個 kuid。作為一項良好的實踐，僅在絕對必要時使用 obsolete-table... 例如，在您要上傳到 DLS 或在網站上自行釋出的依賴資產中，取代不需要的付費資產。
- ↑ 關於類別時代標籤範圍：安全的玩法，已知有效。其他“未來十年”值應該在依賴它們之前進行測試。
- ↑ 許多容器在列表中使用虛擬/佔位符名稱。這些可以是描述性詞語，只要它們不包含空格字元。在短語構造的名稱中使用下劃線或句點可以保留可讀性，並顯著提高畫質晰度。例如，一個貨運車廂可能運載 45 種法定產品型別。這些將在依賴項容器中列出。使用 Coal、granite、crushed_limestone 等可以讓表的維護和更改變得更容易。Jes Sayin，從 1976 年起擔任程式設計師。
- ↑ 在第二個縮圖容器示例中，有一個第二個 512x512 大小的影像，一個額外的影像。DLS 會使用哪個是未知的。也可以包含更大的影像尺寸，透過電子郵件聊天，T:ANE 可能會支援一個更大的影像尺寸，這將在預覽操作或 DLS 列表中找到用途。N3V Games 通常不會發布此類資訊。
- ↑ 早期的做法可以追溯到 Trainz 1.x，使用關鍵字/標籤“thumb”以及引用執行時選單的 240x180 縮圖影像的路徑規範。art 資料夾包含一個具有 Alpha 遮罩的 512x512 tga（通常為 bmp 檔案，但格式正確的 tga 可以用作自 Alpha 遮罩）以及 64x128 選單圖示影像及其控制紋理 texture.txt 檔案。
- ↑ 在 2014-2015 年冬季與前任版本經理 James Moody 的私人電子郵件交流中，在關於這個主題的要點上，DLS 上傳驗證軟體可能已被更改，以便從那時起強制執行正確的縮圖容器。
- ↑ 關於類別時代-nn 與類別時代標籤值：TRS 會接受任何形式的類別時代資料；但 TS2009-SP0 及其更新版本從以前合法的關鍵字-值對中建立了錯誤，並試圖強迫內容建立者更改程式設計師有意破壞的所有資產。後來，DLS 上傳軟體強制執行了轉換，但這要好得多，因為第一個操作花費了很多人力小時來修復一些不必要的修復，而這些修復應該在驗證較舊的 trainz-build 資產時，透過軟體預過濾階段自動實現。這些操作實際上保證了較舊資產下載會出現錯誤。這是 N3V 程式設計師所做過的最愚蠢、最自負的事情之一，而 Auran 更具經驗的軟體人員永遠不會如此輕率地對待社群的寶貴時間。
- 此頁面主體取自 N3V TrainzOnline Wiki 的 KIND_TrainzBaseSpec。增強的資訊由 Yesterdayz-Trainz 使用者組成員新增。
- ↑ N3V 的 KIND_TrainzBaseSpec，作為沒有歷史資訊（標籤）的原始來源頁面，位於此處；accessdate=2014 年夏季
- ↑ a b "Trainz-build" 標籤 直連
- ↑ per fabartus，2014 年夏季；可能是在新增此示例的同一天。
- ↑ Christoph Bergman，N3V Games 首席程式設計師，又名“Windwalkr”，KIND TrainzBaseSpec 歷史 頁面。
|
此參考頁面改編自 TrainzOnline Wiki，根據 CC-BY-SA 3.0 許可證。與 同一主題的源頁面 相比，此頁面可能包含更多文字解釋、說明、歷史記錄和/或示例。 TrainzOnline Wiki 主要由程式設計師或精通 內容建立者 維護，可能包含有關當前 trainz-build 程式碼 標準的更新資訊，這些標準隨著軟體功能的新增而不斷變化。 |