Trainz/refs/TrainzBaseSpec
(從 Trainz/TrainzBaseSpec 重定向)
KIND TrainzBaseSpec 為所有 Trainz 資源型別在所有 config.txt ini 檔案 中提供基本定義。TBS 為許多“標準標籤”提供，這些標籤是所有 Trainz 資源共有的（或者至少可以合法地定義）[1]。
- 其中一些是強制性的，因為它們決定了資源的進一步處理，以及對 config.txt 檔案及其資料夾中資源資料的解釋。
- 但是，大多數是可選的，大多數子資源中可能省略使用該標籤的定義行。
- 無。有效且大多數對所有由事實上的父容器定義的內容都是必要的，即所有 Trainz 數字模型所需的 config.txt 檔案。KIND TrainzBaseSpec (TBS) 是一個根類，其他 Trainz 資源類從中派生。
- 之所以說它們是派生的，是因為它們繼承了其中列出的引數定義的處理屬性（指令）和值，其中關鍵的是 kind 標籤的值。該列舉詞決定了資源的特定kind 宣告和要求，這些宣告和要求被新增到這些資源的配置檔案中 TBS 的定義中。其他重要的 TBS 定義資料具有明顯的意義和實用性，例如資源的名稱、Kuid 識別符號和版本、Trainz 構建值 (TBV) 以及其他具有廣泛可變的定義、適用性和範圍的需求，例如 _string-table_、_obsolete-table_、_kuid-table_ 和縮圖影像都是偶然的。字串值，即使是資源名稱和描述，在實踐中通常完全不必要且可以完全省略。
- 當宣告一個 kind 時，該 kind 成為父類，要求並規定必須在該類中滿足的必要資料對，除了 TBS 中列出的那些之外。
- 某些引數可以在資源 kind 的情況下保持未定義，尤其是在使用較舊的歷史 Trainz 構建標籤值的常見做法中，對於那些，Content Manager 或 Content Creator Plus (CCP) 實用程式將分配一個預設值，但在處理它時會列出警告訊息。TrainzOnline 維基、這裡或較舊的 TC3 時代 Content Creator's Guide (CCG 將提到一個預設值。
- 從 TRS2006 和 Trainz Classics (TC1&2) 開始，每個版本的 Content Manager 模組都會施加越來越多的預先承諾錯誤測試[註釋 1]，並且每個模組都變得越來越堅決地警告這樣的標籤在它期望這樣的標籤 - 資料對時沒有被定義。
許多這些在 TANE 之後版本中“昨天預設”的定義行，今天反而更經常地會生成一個錯誤，要求一個明確的值定義，而這些值在過去載入時是預設的。[註釋 2] 與過去的時代相比，這是一個更令人討厭的事情，那時一個錯誤的資源定義有時會導致臭名昭著的“藍色畫面宕機”，或者更常見的是，將執行時軟體崩潰回桌面，導致編輯丟失，並可能需要重建資料庫。
所有 Trainz 定義的資料（內容）都有三個必備元素：一個 config.txt 檔案 來組織資料，一個標識，意味著一個 kuid（只有使用者名稱對你毫無用處，然而一個合法的資源可以不帶名稱地建立！）最後，一個合法定義的 kind 標籤。kind 負責，是樂隊的指揮，是排長或 CEO 指示——為在之後處理的所有內容設定要求。簡而言之，kinds 的值，一個很小的、精心定義的、成員只有少數的群體——告訴 Trainz 軟體應該在我們的虛擬世界中渲染和顯示什麼，以及如何（或在哪裡）找到其他部分，這些部分需要使資源的這些部分在該 config.txt 檔案中連結在一起。
下面的每個子類都被認為具有 TrainzBaseSpec 作為其資料“父類”。[註釋 3] 下面列出的幾個 kind，那些帶下劃線的，是過時的 kind，早於 TS2009 版本中 Trainz 資料模型 的更改（即從 2008 年後期開始），N3V 程式設計師僅對其施加了逐漸（增量）的更改。
當前可以在 N3V Trainz Wiki TrainzOnline 站點此處 的 Content Creator's Guide 部分中找到有關基於這些過時 kind 修復資源的詳細資訊，其中包含 過時 Kinds 的示例此處。強烈建議 Trainz Download Station 的所有使用者或任何考慮建立內容的使用者仔細閱讀 CCG。通過了解舊內容是如何定義的，然後與 TrainzOnline 對相同資料型別的當前覆蓋進行對比，可以獲得寶貴的見解，因為這種過去與現在的對比通常可以為修復、更改和自定義資源提供寶貴的見解。更重要的是，CCG 在 TrainzOnline 上釋出的是 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 (容器) { } |
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 | "作者/組的網頁地址 '字串值'" |
| 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，直接對應（*對映到3rd*）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 進軍 Mac 電腦，打斷了基於 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-builds 中，當編輯資產時，使用者名稱也成為作業系統資料夾名稱，並且資產檔名被忽略，而在 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-XX 標籤，每個支援的區域設定一個。如果適當的“description-XX”標籤不存在於給定終端使用者系統上以表示此資產，則改為使用英文description 標籤。
string-table 容器
[edit | edit source]- 型別：UTF-8 字串列表容器，字串表容器。
- 欄位定義：英文字串的鍵值列表。每個鍵都是一個有意義的指令碼識別符號，對映到二進位制資料並被其引用。每個值都是一個英文字串。英文字串可以包含或引用非英文專有名詞作為識別符號。非英語母語的作者在需要時仍然必須建立一個無後綴的字串表容器。軟體只連結到並引用字串表容器中沒有後綴的名稱和值，這必然會讓西班牙語、法語、德語、捷克語、荷蘭語……日語作者無休止地感到困擾。換句話說，帶字尾的字串表完全是為了翻譯目的而存在的，當地圖用非英語編寫時就會產生問題——沒有字串表-en 來提供反向翻譯的表。同樣，使用者名稱-en 和描述-en。所有三種缺失都表明了一種過時和輕率的傲慢和對世界動態的漠不關心。
其他語言透過類似的字串表（例如 string-table-XX）支援，這些字串錶帶有與國際化字尾（XX）匹配的本地化程式碼字尾，用於描述和使用者名稱關鍵字/標籤，但這些語言鍵的字串表容器將始終在左側條目中具有相同的鍵值。
- 這些左側的鍵或標籤既充當“本地索引關鍵字”，又充當“語言之間的等效表”。
- 左側欄始終包含內容建立者賦予的“特殊”名稱的物件，例如訊號、軌道標記和行業、連線點等的名稱，這些名稱可能會被引用，並會出現在駕駛員和測量員模組的“查詢公用設施”（CTRL+F ) 功能小程式。
- 相反，索引側也不會*列出預設的名稱*，例如在構建路線圖時由隨機數自動索引的無數連線點（即毫無意義的雜亂無章。如果重要，路線構建 CC 會命名它！），但會自動包含可能臨時的資產，例如火車車的預設名稱。如果重新命名，這些名稱將取代其對應的預設名稱。
- 它的主要用途是那些旨在與指令碼引用進行互動並承擔可變屬性的物件，例如火車站或行業需要或準備運送到行業的貨物數量，或由互動式火車車（滾動行業到指令碼）和其他可配置資產（如簡單通用的廣告牌風格標誌）攜帶，透過一些高度調整和角度扭轉，可以放置在庫存建築或行業的正面，以便在建築物上放置不同的商業名稱。換句話說，一些可配置的場景。
- 總體而言，在路線地圖或佈局中，這些 LHS 名稱對應於地圖資產上的命名物件，這就是大多數字符串表出現的地方（從字面上看，由大型路線kind 地圖中的數千個條目填充）。
- 在某些資產中，該預設名稱與軟體指令碼掛鉤，因此字串表變得*特別重要*，而不是*無趣*。（見下文）
- 在每種型別的資產中，使用字串表型別始終是合法的，就像描述標籤和 trainz-build 和 kind 標籤一樣。與這些標籤不同，它不需要存在或定義，並且在任何情況下都不是強制性的。除非程式碼期望它們的結合，否則封裝在字串表容器內的值沒有任何功能或效果。
- 在其他資產中，再次以那個假設的可程式設計商業標誌為例，如果字串表要與軟體進行互動，則需要為其指定一個預設名稱。所有地圖可放置資產都可以命名或重新命名，但“特殊名稱”必須在指令碼和字串表索引值中匹配。大多數可配置資產定義一個介面變數，用於替換預設名稱作為索引或查詢表，該表由指令碼和資產的二進位制資料引用。其他變數也可能在可程式設計資產中定義。這些變數中的每一個都可能被指令碼引用，但正是索引值使它進入地圖或會話字串表，從而使所有內容在駕駛員或會話建立者需要可變性時協同工作。
- 相反，如果沒有系統軟體知道索引中命名的專案的地址，則物件的指令碼可能不會觸發、條件檢查或更新能力。這是 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 更改 kuid，以便重疊不會覆蓋已經在目標安裝中使用相同 kuid 的資產，而不會看到錯誤訊息。] 至於它是否也起作用，需要一個比我更勇敢或更愚蠢的人！--Fabartus，編輯。
- 格式(所有值都是 <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 新增到裝載和允許的產品隊列表條目，留給學生。（歡迎你，但這是更改名稱的充分理由！保持事情井井有條几乎是製作資產的全部戰鬥！）
obsolete-table 容器
[edit | edit source]- 型別： KUID 列表容器，與KUID 表格容器格式相同。
- 欄位定義： 一個“佔位符鍵 - 鍵 - 值”的資產列表，這些資產被此資產標記為已過時。任何嘗試載入此列表中的任何資產都將導致載入此資產。
- 此外：兩個資產都標記第三個資產為過時是非法的，除非這兩個資產中的一個也標記另一個為過時。[註釋 6]
- 迴圈過時引用是非法的。
- 此資產的所有低編號 KUID2 版本都隱含為過時，無需包含在此列表中。同時，較新的改進型資產（具有更高的 KUID2）及其前身絕不應將同一個前身（例如原始！）列入“中間”前身列表中 - 因為這些值用作替換表項，並且只有一個資產可以替換較早的版本。（陣列只儲存一個值，不能用兩個替換一個！）
- 將此資產的更高編號 KUID2 版本標記為過時是非法的，因為這會建立一個隱式迴圈引用。
- 此列表中引用的資產必須與此資產具有相同的建立者，才能透過 DLS 上傳過程進行稽核和接受，此限制不適用於本地版本，在本地版本中，它可能用於用一個圖形更美觀和更新的資產替換一大組火車車的舊紙質車輪 KUID。
類別 - 地區標籤
[edit | edit source]- 用途：CM 和 Surveyor 中的過濾器（搜尋條件）
- 型別： 列舉字串或字串陣列。
- 欄位定義： 一個由分號（';'）分隔的雙字元類別 - 地區標籤程式碼列表。字串中不應該存在其他字元（包括空格等）。此資產被認為與每個指定的區域相關 - 這對於火車車型別和訊號型別資產最相關，但可以為任何資產提供。
- 示例
- 類別 - 地區 "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"（大多數第一世界國家）
category-class 標籤
[edit | edit source]- 用途：CM 和 Surveyor 中的過濾器（搜尋條件）；確定 KIND 宣告如何處理資產，以及 Surveyor 在哪裡列出資產。
- 型別： 列舉字串。
- 欄位定義： 一個描述此內容項的單個 2-3 個字元的類別 - 類別程式碼。類別 - 類別標籤用於提供超出資產型別隱含資訊的額外人工子分類。每個 Trainz 資產的類別 - 類別標籤有助於描述資產在遊戲中的“意圖”，而不是資產的內部結構。
|
|
請注意，許多類別 - 類別程式碼僅與特定資產型別相關 - 類別 - 類別程式碼不得應用於不合適的型別的資產。
- 示例
| 類別 - 類別 "XBG" | 箱車 - 來自 PRR 60' | |
| 類別 - 類別 "BR" | 鐵路（風景非功能性） - 可能是一棟建築 | |
| 類別 - 類別 "BIN" | 具有產品處理功能的工業資產 |
category-era 標籤
[edit | edit source]- 每個時代程式碼代表一個十年，由一個四位數整陣列成，然後必須以 's' 結尾
（例如“1990s;2000s;2010s”），因此建立一個列舉的軟體令牌（值），該令牌必須與一個指定的合法時代程式碼完全匹配。 - 字串中不應該存在其他字元（包括空格等），包括（尤其是在字串末尾）在結束的雙引號字元之前。
- 允許的年份範圍是 1800-2010s[註釋 7]
- 此資產的唯一含義是對其他人類而言，即此資產被認為在指定的時代範圍內有效且相關，並且內容管理器將接受指定適用年份的搜尋過濾器。
- 示例
category-era "1920s;1930s;1940s;1950s"
縮圖容器
[edit | edit source]- 用途：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 True Color）列在一個 '_art' 子資料夾中（Trainz 1.0 - TC3 約定：'_art'、'_body' 和 '_shadow' 是早期 Trainz 資料模型需求指定的三個子資料夾，名為“資產檔名字尾”（過時的標籤 -<值> 對），它看起來像下面這樣[註釋 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 連結，它們只會在嵌入式 Web 瀏覽器中起作用，而不會在任何外部 Web 瀏覽器中起作用。在存在此標籤的情況下，遊戲內按鈕將允許使用者檢視資產描述或幫助，而無需離開遊戲環境。
這在駕駛員中可能非常有用，可以訪問路線地圖、指南或會話說明或說明。
建議在所有情況下使用通用組頁面來表示資產類別，只要這些資產提供類似的功能但外觀略有不同。這減少了建立、維護和本地化此類文件的時間成本。
- 型別： 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's 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|custom-category-list container
- 型別: ASCII 字串陣列容器。
- 欄位定義: 一個自定義類別識別符號列表，用分號 (;) 分隔。每個 自定義類別識別符號 應該是一個簡短的（例如 3-6 個字元）字母數字標記。字串中不應包含其他字元（包括空格）。
- 這些自定義類別用於使指令碼能夠快速定位特定型別的資產。強烈建議謹慎引入新的自定義類別識別符號。
- custom-category-list 標籤值總共不超過 64 個字元。除非存在現有的特定指令碼需求，只能透過 custom-category-list 方法來滿足，否則應將此標籤留空。
- 最低版本: V3.5 及更高版本
- 型別: 成員-of-組容器 配對的 佔位符引數 和 資產組 KUID 列表。
- 欄位定義: 一個 KIND_Asset-group 資產列表，此資產屬於這些資產。有關如何以及何時使用此列表的詳細資訊，請參閱 kind KIND Asset-group 文件。
該容器包含 KIND Asset-group KUID 的常規列表。此包含是一個宣告，表明此後，特別是在搜尋操作（包括指令碼介面和 TrainzUtil）中，此資產將被視為每個列出的資產組的成員。
如果為給定的 "member-of-groups" 容器未指定任何條目，或者如果資產省略了 "member-of-groups" 容器，則模擬器軟體可能會根據資產的 Config.txt 檔案指定一些預設資產組。確切的行為可能會在不同版本的模擬器之間發生變化，但是當前的邏輯在 此處 描述。
- 以下標籤對於任何資產都不是強制性的，許多資產將其留空。
- 從歷史上看，識別和許可標籤從 Trainz 0.9（測試版）開始。
- 型別: UTF-8 多行字串。（被程式設計師法令廢棄。）
- 欄位定義: 一個許可，描述了資產建立者希望如何使用此資產。最常見的是許可宣告禁止在任何付費路線、依賴資產（例如轉向架、耦合器等火車部件）或重製中使用受版權保護的資產，包括在任何付費運營的網站上分發資產。（從理論上講，即使對於 DLS 也是如此。FCT 費用是為了更快地訪問和無限下載，而不是為了訪問資產。）
- DLS 上的大多數資產都是 知識共享署名-相同方式共享（CC-BY-SA）的措辭不好的版本，就像這個和其他維基媒體維基專案一樣。
- license 標籤的含義不明確，N3V 不建議使用它，但它的存在早於 N3V 的管理 6-7 年。
- 上傳到 下載站 或提供用於包含在遊戲中的內容，可能受特定再分發合同或許可協議的約束，該協議將取代此欄位中的任何文字。許可欄位不提供本地化支援。許可欄位的文字不會由 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 及其下面的朋友。
|
|
- 資源名稱、名稱和名稱-XX — V1.3–v2.8 — 歷史上在幾乎所有 v1.3-v2.0 資源中發現。儘管“資源名稱”在 v2.8 中被保留而沒有引起抱怨，但在 v2.5 後被棄用；因此，在 v1.5 之後，資源的 config.txt 檔案中唯一需要的、想要的或被認可的名稱是使用者名稱-XX 變體。
資源名稱是 Trainz 1.x--TRS2004 Trainz 時代的資源的主要資料夾名稱，而且通常是 CM 在開啟檔案以進行編輯時開啟的資料夾的名稱；在這樣的早期資料模型資源中，通常會發現資源名稱也被用於那個早期 Trainz 時代的 資料子資料夾系統，在火車車廂資源中，子資料夾名稱為“資源名稱_art'”、“資源名稱_body'”、“資源名稱_shadow'”。在修復此類資源時，通常可以使用從資原始檔複製並貼上下來的樣板中的SAR 替換該值。此替換通常會正確定義和連結資源的子資料夾（用於車身、陰影和藝術作品），因為早期方案中的檔名基於資源名稱標籤。
- 'name' 和 'name-XX' 是早期資料模型中較長的 使用者名稱 和 使用者名稱-XX 標籤的早期形式，XX 代表英語“名稱標籤”（或今天的“使用者名稱”標籤）的非英語語言翻譯的 ISO 兩字母后綴；'XX' 形式與 description-XX 一樣，是“本地化”支援其他語言的使用者友好值的組成部分。
- 在最古老的 Trainz 時代（v1.0-v2.4）資源中用使用者名稱和使用者名稱-XX 替換 name 和 name-XX，或者如果存在使用者名稱，則直接刪除。
- 如果資源具有 trainz-build v2.7 及更高版本，則 name-XX 會導致錯誤。有趣的是，即使在 TS12 這樣晚的版本中，name-XX 標籤也會在 Surveyor 工具的搜尋列表中顯示為資源名稱，如果不存在，則會顯示 TrainzBaseSpec。
|
|
- 被 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 上[注 12]。儘管在 Surveyor 中無法直接訪問，但在 TR06 和 CMP 之後，可以定義一個過濾器來選擇一個日期範圍，並將該過濾器與區域和型別一起使用，以便在 Surveyor 中驗證在 Surveyor 的放置和選擇工具中列出的資源。在 TS09 及之後版本中被棄用，TS09 使用較短的 category-era 標籤 字串陣列 放在一行中，而不是使用多個帶有 “-nn” 字尾的標籤-值對。
- 字串陣列中的空格將導致錯誤；所有值必須以“s”結尾，並且必須包含四位數字，例如 1880s;1950s;2010s（這對於進出時尚的某些型別的女士服裝可能是完全合適的！）。定義一個範圍目前還不可行，但使用者社群已經提出了請求。
- 用字串陣列型別的 category-era 標籤 替換，標籤之間沒有空格，用分號隔開；這些標籤以完整的四位數年代數字後跟“s”（小寫字母 s）字尾給出。
- 被 category-region 標籤 取代
- 型別 category-region-nn — V1.3–v2.8 — 歷史上在幾乎所有符合區域標準的資源中發現。這些已經被category-region 標籤中兩個字母的列舉 ISO 國家程式碼的“字串陣列” 取代。
- 用字串陣列型別的 category-region 替換，標籤之間沒有空格，用分號隔開，兩個字元的國家程式碼在引用的標籤部分中列舉；這些標籤以兩個大寫字母的形式給出，構成 列舉 程式碼，程式碼之間用分號隔開，但在最後一個程式碼之前除外。
- 字串陣列中的任何 空格（包括結尾引號前的空格）都將導致讀取錯誤和故障訊息。
- region — TBS V1.3–v2.8 中作為內建過濾器和地圖資源自定義本地化識別符號（kuid）的有效部分；現在，唯一合法的標籤用法是在kind 地圖（佈局）資源中。
- 作為以前的過濾器修飾符，該標籤在歷史上幾乎所有資產中都能找到，但它在滾動庫存、場景、樣條資產、軌道型別（包括隧道和橋樑）以及具有某種本地化的路邊資產中尤為普遍。
- 地圖資產仍然保留著“區域”關鍵字，該關鍵字在 Map 配置檔案中定義，但用途相反——成為 kind region kuid 引用。因此，區域在 地圖 中 是必需的，並且自從 TS2012 以來，與標籤型別一樣，在大量曾經作為 TRS 系列版本 Surveyor 工具視窗的“分組資料” “快速過濾器”出現的資產中是違法的。
- TRS2009 之後，任何區域標籤到文字字串都已過時，因為在程式設計師的心目中，他們用 Pick List 替換了 Surveyor 工具中“型別和區域”字串值的粗略過濾組選擇器。這兩個標籤都有一些優點和缺點，並且都追溯到 Trainz 0.9 Beta 版本。
陰影標籤
[edit | edit source]- 見上面的彎道，已棄用/過時的 TS2009 之前的遺留 kind track 資產模式控制標籤。
縮圖標籤
[edit | edit source]縮圖標籤是 縮圖容器 的早期單檢視實現（上面也有簡要說明）。Trainz 早期的 N3V 程式設計師版本會在主資產根資料夾或資產名稱_art 或資產名稱_body 資料夾中找到一個 .jpg 檔案，最好大小為 240x180 畫素，並用它在 CMP 和 DLS 中顯示資產（如果它已上傳）。自 TRS2006 以來，該標籤已棄用，因為縮圖容器是在 v2.0（TRS2004-SP0）中引入的。在舊的修復資產中，如果 TBV 保持在 v2.4 以下，則拇指通常仍將在較新的 CM 中工作，前提是它位於 _art 子資料夾中，並且資產名稱與使用者名稱匹配。
型別標籤
[edit | edit source]- type — V1.3–v2.8 — 以前的過濾器修飾符，在歷史上幾乎所有資產中都能找到，但它在滾動庫存、場景、樣條線、軌道型別（包括隧道和橋樑）以及路邊資產中尤為普遍。
- 型別標籤與“區域標籤”一樣，在 Trainz 0.9 - TC3 版本中用作“Surveyor 內組過濾器”，它與區域相結合，提供了較小的資產選擇（工具組）。自從 TS2009 以來，它移除了這些本地可點選過濾器的功能和使用，轉而採用一種新的、更繁瑣的過濾器。這些使工具選擇變得快速簡單，而不是在工具選項卡之間切換時變得緩慢和暫停——如今的 TANE 之前的版本在工具選項卡之間來回切換時，經常會被重新載入整個選擇列表所淹沒。
- 型別和區域都預設為“全部”，提供與 TS09 及之後版本工具相同的超級列表。
註釋
[edit | edit source]- ↑ 資產 提交（TANE 的提交）是將內容納入資料庫並將其在 DB 索引中交叉引用以使其能夠在執行時模組中訪問的過程和步驟。
- ↑ 驗證資產的一種方法是，除了這些值之外，其他方法都是可以的，方法是將 TBV 降至 2.5-3.7 範圍，看看這些訊息是否消失。您可能需要多次降低它，直到足夠低，反之亦然，在較舊的 TBV 中無法識別的較新關鍵字可能會顯示不同的錯誤訊息。不過，不要失敗嘗試——即使在這樣的情況下失敗也會產生知識和經驗，而且你不會破壞任何東西！如果是這樣，您可以確信，僅提供一個值就是解決問題的方法。通常，一些現代需求僅僅需要關鍵字對，因此在標籤後面加一個空行或在標籤後面加一對空花括號來表示容器，就可以滿足這些需求，而錯誤測試則過於嚴格。
- ↑ 注意：此列表在 N3V TrainzOnline Wiki 上是“維基化”的，這意味著在“KIND”一詞之後的首字母已大寫，而 config.txt 檔案中的實際資料標籤名稱是全部小寫文字。該維基還使用了很多術語中的雙引號，我們將免除您在此體驗這種做法。
- ↑ “kind consist”並不經常直接看到，它似乎只存在於選單和內容管理器列表中。
- ↑ 過時表必須謹慎使用，並且最常出現在 Auran 編寫的資產中。該表用較新的版本替換了較舊的版本，大多數內容建立者正確地使用 kuid 的 Kuid2 形式來取代較舊的版本。相比之下，N3V 過度使用過時表來升級新發布的“升級”內建資產，這會導致很多混亂，並且無法獲得預期的結果。（例如，許多不錯的 'Flip-trees' 在 TS10 和 TS12 中被 Speedtrees 取代，影響了許多 Speedtrees 未被建立者需要或希望的路線。在安裝過程中，這也導致依賴項缺失，直到找到包含過時表的資產。
• 此外，資產庫.tdx 資料庫儲存索引中僅支援每個 kuid 的一個過時條目，並且用 Kuid2 版本替換 kuid 可能會導致問題（即您會看到哪個？）。
• 過時表的一個很好的用途是使用特定部件升級一系列資產，尤其是轉向架。新增一系列 kuids 以新的優質轉向架替換，可以顯著改善路線或會話的外觀，只需進行一次編輯即可（前提是例如轉向架相容且尺寸合適！）。 - ↑ 最近使用過時資產匯入 TANE 的經驗表明，有不止五個備用 kuids 替換了那個可憐的 Flip-tree 資產。似乎隨著 Speedtrees 引入引起的混亂，以及 TANE 的大修以及其對最新適當資產的積極追求，現在 ContentManager 程序中可以容忍多個不同 kuids 的資產替換相同的 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 更具經驗的軟體人員絕不會如此輕率地對待社群的時間成本。
參考文獻
[edit | edit source]- 本頁面的主體內容取自 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 程式碼 標準的更新資訊，這些標準隨著軟體功能的新增而有所變化。 |