Trainz/refs/TrainzBaseSpec
KIND TrainzBaseSpec 為所有 Trainz 資產型別在所有 config.txt ini 檔案 中提供基本定義。TBS 提供了一些“標準標籤”，這些標籤對所有 Trainz 資產（或至少可以合法定義）都是通用的[1]。
- 其中一些是強制性的，因為它們決定了資產的進一步處理，以及對 config.txt 檔案及其資料夾中資產資料的解釋。
- 但是，大多數是可選的，在大多數子資產中可以省略使用該標籤的定義行。
- 沒有，所有 Trainz 數字模型都需要 config.txt 檔案，因此對所有內容都有效且大部分都是必需的。KIND TrainzBaseSpec (TBS) 是一個根類，其他 Trainz 資產類都是從它派生的。
- 據說它們是派生的，因為它們繼承了引數中定義的處理屬性（指令）和值，其中最重要的是 kind 標籤的值。該列舉詞決定了資產的特定種類宣告和要求，這些宣告和要求被新增到該資產配置檔案中 TBS 的定義中。其他關鍵的 TBS 定義資料具有明顯的意義和效用，例如資產的名稱、Kuid 識別符號和版本、Trainz 構建值 (TBV)，以及其他具有廣泛可變定義需求、適用性和範圍的資料，例如string-table、obsolete-table、kuid-table和縮圖，每個資料都是偶然的。即使是資產名稱和描述，字串值在實踐中也常常完全沒有必要，可以完全省略。
- 當宣告一種種類時，該種類就成為父類，需要並規定必須在該類中滿足的必要資料對，除了 TBS 中列出的那些資料之外。
- 在特定資產的種類情況下，某些引數可能未定義，這在舊的 Trainz 構建標籤值中很常見，對於這些值，內容管理器或Content Creator Plus (CCP) 實用程式將分配預設值，但在處理時會顯示警告訊息。TrainzOnline 維基、此處或舊的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 軟體在虛擬世界中渲染和顯示什麼內容，以及如何在 (或在哪裡) 找到該配置檔案中連結在一起的資產的其他部分。
下面的所有子類都被視為以TrainzBaseSpec 作為其資料“父類”。[note 3] 下面列出的一些種類，那些帶下劃線的，是早於Trainz 資料模型 在TS2009 釋出版本（即從 2008 年後期開始）中發生變化的遺留種類，自那時以來，N3V 程式設計師僅施加了漸進的（增量的）更改。
目前可以在 N3V Trainz Wiki 的Content Creator's Guide 部分找到有關基於這些遺留種類的資產修復的詳細資訊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 標準定義
[edit source]這些標籤和容器是標準定義，幾乎可以在所有資源中找到。有些標籤是可選的，內容創作者可以根據自己的選擇來定義。標籤是關鍵字，並具有單一的分配的鍵值或容器，例如字串陣列或'{' ... '}'有界的封閉標籤值對或子容器。（在 Trainz 配置檔案中宣告的所有內容都是成對的，即使 '{' ... '}' 也被視為'鍵值'。
- 容器是'鍵' 和 '鍵值' 對的集合，並且 TBS 中的 '上層容器'（與縮圖容器中的子容器相反）通常以 '-table' 結尾。
| kind | "'字串值'" |
| trainz-build | '浮點數', 1 位小數的值 |
| kuid | <Kuid 編碼值> |
| username | username "'字串值'" |
| username-XX | username-XX "'字串值'" |
| description | description "'字串值'" |
| description-XX | description-XX "'字串值'" |
| kuid-table (容器) { 依賴項列表 |
一個鍵值表，列出此資源所依賴的所有資源。 |
| obsolete-table (容器) { } |
kuids 列出此資源替換的資源（使其過時） 通常為空（空）[note 5] |
| string-table (容器) { } |
字串和訊息的鍵值列表，用於資源中 通常為空，僅在路線和會話中很大。 |
| string-table (容器[s]) { 非英語 語言文字 } |
翻譯後的字串列表，匹配到強制性的英文 string-table |
| category-region tag 列舉 程式碼 | category-region "'字串陣列'" |
| category-class 標籤 | category-class "'列舉 字串值'" |
| category-era 標籤 | category-era "'約束字串陣列'" 年代 |
| category-keyword "'字串陣列'" 最大長度為 64 位元組 | category-keyword tag 自然語言搜尋關鍵字 (替換型別、區域) |
| 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 資源列表。 |
支援的標籤
[edit | edit source]TrainzBaseSpec 在 config.txt 檔案 中支援以下標籤。 ∅:
kind 標籤
[edit | edit source]- 型別: 字串。
- 欄位定義: 此 config.txt 檔案 所代表的資源型別。請參閱索引 Kinds 和列表: 這裡（上面）
kuid 標籤
[edit | edit source]- 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 標籤
[edit | edit source]- 主要內容: trainz-build tags，縮寫: TB & TBV (TB-value)∅
- 型別: 一個小數點浮點數，由 N3V [2] 列舉，以跟蹤和識別與演進的軟體技術水平相對應的資料型別。
- 範圍： 1.0–4.3 直接對應（'對映到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 構建標籤 值系列為 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）。
- 從 v2.0（TRS2004）開始，Trainz 構建標籤編號值已經透過 23 個步驟遞增，這些步驟是連續的，儘管不是單調的，因為 Trainz TS09-sp3—TS09-sp4 共享一些 Trainz-build[2] 值；也就是說，有一些共同的 TBV 在 TS2009 和 TS2010 的聯合開發時代和版本中重疊。
- 此外，N3V 進軍 Macintosh 電腦打斷了 Windows 版本 Trainz 版本的 TBV 3.4、3.5、3.6、3.7 和 3.8 在 Windows 和 Mac 作業系統之間的平滑遞增。
注意： 熱修復 不會更改版本號。
- 欄位定義： 此資產構建（並存檔）到的檔案格式版本，不一定與資產使用的技術級別有關，但對應於在 Content Creator Plus 中建立資產時分配的資產級別 - 與在 CM 標題欄中找到的一樣。
- 程式設計師建議此編號通常應設定為正在建立和測試資產的 Trainz 安裝的 Trainz 版本號。相比之下，Content Creator 社群試圖將該編號設定為儘可能低的數字，以便新資產在下載時擁有儘可能廣泛的受眾/使用者範圍。更好的內容建立者將在相應的版本上進行裸機安裝（無額外內容）測試，並驗證生成的 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 遊戲的 TBS 標準，此欄位絕不應該包含非英文文字，除非資產名稱是專有名詞（例如，地名）且沒有英文字地化變體。此值是每個人通常搜尋和記住的資料，因此建議使用清晰的名稱。
 |
|
使用者名稱-XX 標籤
[edit | edit source]- 型別： UTF-8 字串，使用者名稱標籤 的替代語言版本。
- 欄位定義：（其中XX 被替換為代表語言的適當 本地化程式碼。）此資產的本地化人類可見名稱。此欄位類似於使用者名稱欄位，但代表非英語語言環境。資產中可能存在多個使用者名稱-XX 標籤，每個支援的語言環境一個。如果不存在適當的 '使用者名稱-XX' 標籤來在給定終端使用者系統上代表此資產，則使用英文使用者名稱標籤。
描述標籤
[edit | edit source]- 型別： UTF-8 多行字串，提供資產的清晰語言描述。
- 欄位定義： 此資產的英文人類可見描述性摘要。
描述在 Content Manager 的“資產詳細資訊”窗格中可見，用於闡明資產名稱，提供規格，以及通常的歷史記錄。
N3V 的 Chris Bergmann 已經宣告此欄位應該保持簡短（1-2 段）描述資產，並透過info-url 頁面提供擴充套件的詳細資訊，但可以容忍相當長的文字塊。有些人使用塊的底部作為版本更改記錄。
此欄位必須由英文描述性文字組成，儘管該文字可能引用非英文專有名詞，如其他地方所述。其他語言翻譯或源文字應放置在眾多可能的替代語言本地化標籤之一中（參見 描述-xx 標籤）。
描述-XX 標籤
[edit | edit source]- 型別： UTF-8 多行字串，描述標籤。
- 欄位定義：（其中XX 被替換為代表語言的適當 本地化程式碼。）此資產的本地化人類可見描述性摘要。此欄位類似於描述欄位，但代表非英語語言環境。資產中可能存在多個描述-XX 標籤，每個支援的語言環境一個。如果不存在適當的 '描述-XX' 標籤來在給定終端使用者系統上代表此資產，則使用英文描述標籤。
字串表容器
[edit | edit source]- 型別： UTF-8 字串列表容器，字串表容器(s)。
- 欄位定義： 英文字串的鍵值列表。每個鍵都是一個有意義的指令碼識別符號，對映到二進位制資料並由其引用。每個值都是一個英文字串。英文字串可以包含或引用非英文專有名詞作為識別符號。由非英語母語人士創作的資產仍然需要建立沒有後綴的字串表容器，如果有需要的話。軟體只連結到沒有後綴的字串表容器中的名稱和值，並引用它們，這將使西班牙語、法語、德語、捷克語、荷蘭語……日語作者不勝其煩。換句話說，帶字尾的字串表僅用於翻譯目的，當地圖用非英語編寫時會產生問題 - 沒有 string-table-en 來提供反向翻譯的表格。同樣，username-en 和 description-en。所有三個缺乏都表明了一種過時的、輕率的傲慢和對世界動態的麻木不仁。
其他語言透過類似的字串表（例如 string-table-XX）支援，這些字串錶帶有與描述和使用者名稱關鍵字/標籤的國際化字尾匹配的本地化程式碼字尾 (XX)，但這些語言鍵入的字串表容器始終在左側條目中具有相同的鍵值。
- 這些左側的鍵或標籤既充當“本地索引關鍵字”， 也充當“語言之間的等效表”。
- 左側欄將始終包含內容建立者給出的具有“特殊”名稱的物件，例如訊號、軌道標記和行業、連線點等的名稱，這些名稱可能會被引用，並將出現在駕駛員和測量員模組的“查詢公用設施”( CTRL+F ) 功能小程式。
- 相反，索引側也不會 *列出預設的名稱*，例如在構建路線圖時，透過隨機數自動索引的無數連線點集合（即毫無意義的混亂。如果重要，路線構建 CC 將為其命名！）；但會自動包含潛在的臨時資產，例如火車車的預設名稱。如果重新命名，這些名稱將取代其相應的預設名稱。
- 它的主要用途是針對那些旨在與指令碼引用互動並獲取可變屬性的物件，例如火車站或行業所需的或準備運往行業的貨物數量，或者由互動式火車車（滾動行業到指令碼）和其他可配置資產攜帶，就像通用廣告牌風格的標誌一樣簡單，透過一點高度調整和角度扭轉，可以放置在庫存建築或行業的正面，以在建築物上放置不同的商業名稱。換句話說，這是一些可配置的場景。
- 總的來說，在 路線圖或佈局 中，這些左側名稱對應於地圖資產上的命名物件，這就是大多數字符串表出現的地方（從字面上看，填充了大型路線 種類地圖 中的數千個條目）。
- 在某些資產中，該預設名稱連線到軟體指令碼，因此字串表變得 *特別重要*，而不是 *枯燥無味*。（見下文）
- 在任何型別的資產中使用字串表型別始終是合法的，就像描述標籤和 trainz-build 和種類標籤一樣。與這些不同，它不必存在或定義，並且在任何情況下都不是強制性的。除非程式碼期望它們結合在一起，否則封裝在字串表容器中的值沒有功能或效果。
- 在其他資產中，再次以那個假設的可程式設計商業標誌為例，如果字串表要與軟體互動，則必須給它一個預設名稱。所有地圖可放置資產都可以命名或重新命名，但“特殊名稱”必須在指令碼和字串表索引值中匹配。大多數可配置資產定義一個介面變數，該變數用於替換預設名稱作為指令碼引用的索引或查詢表，以及資產的二進位制資料。其他變數也可能在可程式設計資產中定義。指令碼可能引用這些變數中的每一個，但正是索引值使其進入地圖或會話字串表，從而使一切在需要駕駛員或會話建立者可變性時協同工作。
- 相反，如果沒有系統軟體知道索引中命名項的位置，物件的指令碼可能沒有任何觸發、條件檢查或更新能力。這是 2000 年代 Trainz 1.0 中物件的特徵，而不是 2003 年 TRS2004 釋出以來的更現代的 Trainz 鐵路模擬器。（從那時起，我們已經走了很長一段路！）
- 有一些資產只能作為一個組一起工作。在這種情況下，在地圖或會話層中命名每一個可以使它們協同工作。例如，考慮一個有五條軌道的公路平交道，其中兩條軌道不在連線點上，形成了所謂的 '菱形交叉口' 與貫通軌道。如何設定訊號，以便任何鐵路交通都關閉公路閘門，或者，使用菱形交叉口禁止其他火車透過正在穿越交叉口的火車。道路和鐵路訊號以及道岔和閘門都必須協調工作。某些“ATLS 系統”資產及其指令碼透過字串表結合在一起可以使這個複雜的系統發揮作用。
- 有關更多資訊，請參閱字串表-XX。
字串表-XX 容器
[edit | edit source]- 型別：UTF-8 字串列表容器，即本地化的字串表，每個字尾對應於除英語以外的語言。
- 欄位定義：（其中 *XX* 被替換為表示的語言的適當 本地化程式碼。）此欄位類似於 *string-table* 欄位，但表示非英語語言環境。
英語字串表（無後綴）是強制性的，其他本地化語言是可選的，由資產作者決定。提交到 DLS 的許多資產，以及捆綁在 Trainz 版本中的路線，通常會進行翻譯，並具有描述-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 槽，這將建立一個迴圈定義，要求其自身的老版本！）
- 同樣，資產不能被列為其自身依賴項。[另一方面，這已經被體驗過（即在 TSxx CMs 中見證為成功提交的無錯誤資產），將地圖和會話在安裝之間進行移植，並使用 GSARS 更改 kuid，以便重疊不會覆蓋在目標安裝上使用相同 kuid 的資產，而不會看到錯誤訊息。] 它是否也發揮了作用，需要比我更勇敢或更愚蠢的人！--Fabartus, ed.
- 格式 (所有值都為 <kuid:aaaaa.bbbbb> 格式)
kuid-table {
0 Kuid-1
1 Kuid-2
3 Kuid-3
... kuid-ii
N-1 Kuid-N
}
|
|
- 利用這些虛擬引數的一個非常有用的方法是將複雜機車車輛資產中的產品 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 新增到貨物和允許的產品隊列表條目中。(不客氣，但這是更改名稱的一個很好的理由！保持井井有條几乎是製作資產的全部戰鬥！)
- 型別: KUID 列表容器，與 KUID 表容器 格式相同。
- 欄位定義: 一個“佔位符鍵-鍵-值”的資產列表，這些資產被此資產淘汰。任何嘗試載入此列表中的任何資產都將導致載入此資產而不是載入列表中的資產。
- 此外： 兩個資產同時將第三個資產標記為淘汰是非法的，除非兩個資產之一也標記另一個為淘汰。[注 6]
- 迴圈淘汰引用是非法的。
- 此資產的所有低編號 KUID2 版本都被隱式視為淘汰，不需要包含在此列表中。同時，具有更高 Kuid2 的更新改進資產及其前身永遠不應該將相同的前身（例如原始的！）列為“中間”中間前身，因為這些值被用作 替代條目表，並且只有一個資產可以被替換為早期版本。(陣列只儲存一個值，不能將兩個值替換為一個！)
- 將此資產的更高編號 KUID2 版本標記為淘汰是非法的，因為這會建立一個隱式迴圈引用。
- 此列表中引用的資產必須與此資產具有相同的建立者，才能使該資產透過 DLS 上傳流程的審查並被接受，此限制在你的本地版本中不適用，例如，它可以用來用一個更美觀更新的資產替換大型火車車組上的所有舊紙質輪子 KUID。
- 目的：在 CM 和 Surveyor 中過濾 (搜尋條件)
- 型別: 列舉字串或字串陣列。
- 欄位定義: 一個由分號 (;) 分隔的兩位 類別-區域標籤 程式碼列表。字串中不應存在其他字元（包括空格等）。此資產被認為與每個指定的區域相關 - 這對於 kind 火車車 和 kind 移動訊號 資產最相關，但可以為任何資產提供。
- 示例
- 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 字元 類別-類別 程式碼。類別-類別 標籤用於提供超出資產種類隱含內容的額外人類子分類。每個 Trainz 資產的類別-類別標籤有助於描述資產在遊戲中的“意圖”，而不是資產的內部結構。
|
|
請注意，許多類別-類別程式碼只與特定資產種類相關 - 類別-類別程式碼不得應用於不合適的種類資產。
- 示例
| category-class "XBG" | 貨車 - 來自 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“圖示”，它應該具有 AlphaMask 或非常淺的背景。許多較舊的資產沒有使用 jpg 檔案，而是將 .tga 檔案 (Targa True Color) 列在一個“_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 的一個修復程式中被放棄，因為使用者社群對此有很多抱怨。
• 如果缺乏縮圖容器的資源（即使使用過時的縮圖標籤）後來在一個新的內建路線或會話中被選中，該資源通常會被分發為一個沒有圖片的專案——如果 texture.txt 或 config.txt 縮圖容器沒有正確引用它們，它們會被剝離。[注 11]
- 型別：URL 字串。
- 欄位定義：指向資源的線上描述、資源說明（幫助）或 TrainzOnline Wiki 上其他幫助頁面的連結，旨在從嵌入式專用 N3V 瀏覽器中使用。該 URL 必須解析到 Trainz Online 安全區 內的網站。目前，嵌入式瀏覽器接受三個域名
auran.com
ts2009.com
ts2010.com
此外，建議使用自定義 Trainz 短 URL 格式，而不是直接連結到這些域名，以使 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。
The script-include-table 容器 是 KIND TrainzBaseSpec 派生的任何資源（簡而言之，所有資源）可用的頂級 config.txt 檔案 條目。此容器允許資源從父資源的指令碼檔案使用 N3V TrainzScript 的 Script_Include_Directive 直接 包含另一個資源的指令碼。
- 相關
擴充套件容器是自定義標籤或子容器的列表，它們具有特定的命名約定。
此容器是指令碼資源名稱及其 kuids 的簡單鍵值表，在編譯資源的指令碼檔案時，會搜尋這些指令碼資源的指令碼包含。鍵或標籤名稱當前未被使用（即是一個 佔位符引數）在搜尋中；值指示要包含的資源的 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 container|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 及以上
- 型別： Member-of-groups 容器 配對列表 佔位符引數 和 資產組 kuids。
- 欄位定義： 一個 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 Share Alike with Attribution (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 之後，不鼓勵使用“asset-name”，因此在 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]
casts-shadow 標籤
[edit | edit source]
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 及其以後版本中已過時，這些版本使用較短的 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 地圖（佈局）資產中。
- 作為以前的過濾器修飾符，該標籤在幾乎所有資產中都有歷史記錄，但它在滾動庫存、風景、樣條資產、軌道型別（包括隧道和橋樑）和具有某種程度本地化的路邊資產中尤為普遍。
- 地圖資產仍然保留了 Region 關鍵字，該關鍵字在 Map 配置檔案中定義，用法相反，是 kind region kuid 引用。因此，Region 在 Map 中是必需的，並且從 TS2012 開始，與標籤型別一樣，在大量曾經使用該標籤作為 TRS 版本 Surveyor 工具視窗的“分組資料”和“快速過濾器”的資產中，該標籤是非法的。
- TRS2009 之後，所有文字字串的區域標籤都已過時，因為在程式設計師的眼中，他們用 選擇列表 取代了 Surveyor 工具中“型別和區域”字串值的粗略過濾組選擇器。這兩個標籤都有一些優點和缺點，並且都追溯到 Trainz 0.9 Beta 版本。
縮圖標籤是 縮圖容器 早期的單檢視實現（上面也簡要記錄）。早期 Trainz 的預 N3V 程式設計師版本會在主資源根資料夾或資源名稱_art 或資源名稱_body 資料夾中查詢 .jpg 檔案（最好尺寸為 240x180 畫素），並將其用於在 CMP 和 DLS 中顯示資源（如果上傳）。自 v2.0（TRS2004-SP0）引入縮圖容器以來，該標籤在 TRS2006 期間已被棄用。在舊的已修復資源中，如果 TBV 保持在 v2.4 以下，只要縮圖位於 _art 子資料夾中並且資源名稱與使用者名稱匹配，縮圖通常仍然會在較新的 CM 中工作。
- 型別 — 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 檔案中實際的資料標籤名稱全部為小寫文字。該維基還對很多術語使用了雙引號，我們將在本文中避免這種做法。
- ↑ “編組型別”通常不會直接看到，它只存在於選單和內容管理器列表中。
- ↑ 必須謹慎使用過時表，它最常出現在 Auran 編寫的資源中。該表用更新的版本替換了舊的 KUID，大多數內容建立者正確地使用 KUID2 格式的 kuid 來取代舊版本。相比之下，N3V 過度使用過時表來更新新版本“升級”的內建資源，這會導致很多混淆，並且無法獲得人們期望看到的內容。（例如，許多不錯的 '翻轉樹' 在 TS10 和 TS12 中被速度樹取代，影響了許多路線，而建立者在這些路線中並不需要或想要速度樹。在不同的安裝中，這也會導致依賴關係缺失，直到找到包含過時表的資源。
• 此外，在 Assets.tdx 資料庫索引中，每個 KUID 僅支援一個過時條目，用 KUID2 版本替換 KUID 會導致問題（即，您會看到哪個？）。
• 過時表的一個很好的用途是使用特定部件升級一系列資源，尤其是轉向架。新增要由較新的良好轉向架替換的 KUID 組合，可以透過單次編輯顯著改善路線或會話的外觀（前提是轉向架相容且尺寸合適！）。 - ↑ 最近，將過時的資源引入 TANE 的經歷表明，有不下 5 個替代的 KUID 替換了那個可憐的 翻轉樹資源。似乎由於速度樹的引入和 TANE 的大修（它積極地追求最合適的更新資源）造成的混淆，內容管理器流程現在容忍多個不同 KUID 的資源替換相同的 KUID。作為良好的做法，僅在絕對必要時使用過時表……例如，用您要上傳到 DLS 或自行釋出到網站上的依賴資源中的不想要的付費資源來取代該資源。
- ↑ 關於類別時代標籤範圍：安全的選擇，已知有效。其他“未來十年”的值應在依賴於這些值之前進行測試。
- ↑ 許多容器在列表中使用虛擬/佔位符名稱。這些可以是描述性詞語，只要它們不包含空格字元即可。在短語構造的名稱中使用下劃線或句點可以保留可讀性並顯著提高畫質晰度。例如，一個貨運車廂可以承載 45 種合法產品型別。這些將在依賴項容器中列出。使用 Coal、granite、crushed_limestone 等可以更容易地維護和更改表格。Jes Sayin，從 76 年開始擔任程式設計師
- ↑ 在第二個縮圖容器示例中，還有一個第二個 512x512 大小的影像，即 extra。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 生成的資源時，自動在軟體預過濾器透過中實現。這些操作幾乎可以肯定，舊的資源下載將存在錯誤。這是 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 程式碼 標準的更新資訊，這些標準隨著軟體功能的新增而有所變化。 |