Trainz/refs/TrainzBaseSpec
(重定向自 Trainz/references/TBS)
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 Creator Plus (CCP) 實用程式將分配預設值，但在處理它時會列出警告訊息。TrainzOnline wiki、此處或較早的TC3 時代內容創作者指南 (CCG 將提到一個預設值。
- 從 TRS2006 和 Trainz Classics (TC1&2) 開始，每個版本的 Content Manager 模組都會對預提交錯誤測試進行越來越嚴格的限制[note 1]，並且每個版本都變得越來越堅定地警告這種標籤在期望這種標籤資料對時沒有被定義。
許多這些在 TANE 之後的版本中“昨天預設”的定義行，現在更常會導致錯誤，要求在過去載入中預設值的情況下明確定義值。[note 2]與舊時代相比，這是一個更可取的煩惱，在舊時代，錯誤的資產定義有時會導致臭名昭著的“藍色畫面宕機”或更常見的是，將執行時軟體崩潰回桌面，導致編輯丟失，並可能需要重建資料庫。
子類
[edit | edit source]
所有 Trainz 定義的資料（內容）都有三個必需元素：一個config.txt 檔案 用於組織資料，一個身份，意思是kuid（僅使用者名稱對您沒有用處，但可以建立合法的資產，而無需名稱！），最後，一個合法定義的 kind 標籤。kind 負責，是管絃樂隊的指揮，是排長或 CEO 給出指示——設定在之後處理的所有內容的要求。簡而言之，kind 的值，一個緊密定義的成員限定的小組——告訴 Trainz 軟體在虛擬世界中要渲染和顯示什麼，以及如何（或在哪裡）找到在該 config.txt 檔案中將資產的這些部分連結在一起所需的其他部分。
以下每個子類都被認為具有TrainzBaseSpec 作為其資料“父類”。[note 3]下面列出的少數 kind，那些帶下劃線的，是早於Trainz 資料模型在TS2009 釋出（即自 2008 年後期以來）更改的舊 kind，N3V 程式設計師自那時起只施加了逐漸（增量）的更改。
目前可以在 N3V Trainz Wiki 的內容創作者指南 部分找到基於這些舊 kind 修復資產的詳細資訊TrainzOnline 站點此處，其中包含具有啟發性的舊 kind 示例此處。強烈建議Trainz 下載站 的任何使用者或任何考慮建立內容的人仔細閱讀 CCG。通過了解舊內容定義方式的歷史背景而獲得的見解，可以與 TrainzOnline 對相同資料型別的當前覆蓋範圍進行對比和比較，因為這種過去與現在的對比通常會為修復、更改和自定義資產提供寶貴的見解。更重要的是，CCG 中的寫作是專業製作的，並且更具同義性——它通常會讓你瞭解如果改變這一點或那一點的擴充套件效果，而 Trainz Wiki 卻沒有提供。TrainzOnline 上的 CCG 是TC1&2/TC3 版本——幾個小冊子的最後出版版本，這些小冊子可以追溯到 1999 年的Trainz；TC3 CCG 包含 TRS2004/TRS2006 和UTC 資料模型中需要正確更新的更改後的 Enginespecs 機車資產。
TBS 標準定義
[編輯原始碼]這些標籤和容器是標準定義，幾乎所有資產中都可能找到。 一些標籤是可選的，可能不會被內容創作者定義，因為這是他們的選擇。 標籤是關鍵詞，並分配了一個唯一的鍵值或容器，例如字串陣列或'{' ... '}'有界封閉的標籤-值對或子容器。（Trainz 配置檔案中宣告的所有內容都是成對的，即使 '{' ... '}' 也被認為是一個'鍵值'.
- 容器是'鍵' 和 '鍵值' 對的集合以及 TBS 中的 '上層容器'（與縮圖容器中的子容器相反）通常以 '-table' 為字尾。
| kind | "'字串值'" |
| trainz-build | 'float', 1 位小數 |
| kuid | <Kuid 編碼值> |
| username | username "'字串值'" |
| username-XX | username-XX "'字串值'" |
| description | description "'字串值'" |
| description-XX | description-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 格式的更新和更新跟蹤修改版本，允許指定版本號。 A
<kuid:xxx:yyy>等同於<kuid2:xxx:yyy:0>（零修訂或版本零，表示原始版本）- 這允許資料項（Trainz 資產）攜帶資產的固有版本程式碼。 這通常不會與識別軟體技術級別的 CM Trainz-build 程式碼 相匹配，但表明以前的版本歷史。
- 在資料庫中同時存在兩種資產的情況下，具有更高字尾程式碼的資產將在 KUID2 中覆蓋或替換較舊的資產。 不一定需要早期版本，但 CM 會將缺失的修訂鏈列為缺失的依賴項，對於那些討厭 CM 中該功能被汙染或程式設計師按原樣保留該功能的使用者來說，這是一個軟體錯誤，無論如何都會降低使用 CM 來識別使用者缺少的內容的實用性，並導致使用者花費時間手動找出真正是什麼。
- 主要覆蓋範圍：trainz-build 標籤，縮寫：TB & TBV (TB-值)∅
- 型別： 一個小數點浮點數，由 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 的程式設計師團隊看來，TRS2004 版本是第二個 Trainz 產品，無論前臺如何炒作營銷名稱（比如 Trainz UTC，是終極的任何東西…… 真的嗎？拜託！真的嗎？！）。
Trainz 版本和相應的 Trainz-build 標籤 值的系列是 Trainz 1.0=v1.0，Trainz 1+SP1 ⇒ V1.1，Trainz 1.0+SP2 ⇒ V1.2，Trainz 1+SP3 ⇒ V1.3，等等（但跳過 1.4 & 1.7–1.9），所以 TRS2004-SP0 = v2.0 然後增加，每個從 2.0 (TRS2004 無服務包) 到現在的版本增加 0.1 (v3.7 = TS12-SP1，v3.8 = Mac2，3.9=TANE-CE，4.0—4.3，之後呢？從 2016 年 3 月開始，4.3 及以上版本是 TANE SP，TBDL)。
- 從 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 版本，通常解析為 1.3 作為 TBV。
- 型別： UTF-8 字串，資源的使用者名稱，必須指定。
- 欄位定義： 此資源的英文人機可讀名稱。
在 TC1&2 (v2.7) 之後的 trainz-builds 中，使用者名稱在編輯資源時也變成了作業系統資料夾名稱，並且資原始檔名被忽略，而以前它在 v2-6 配置檔案中的優先順序更高。根據 N3V 遊戲的 TBS 標準，此欄位絕不包含非英文文字，除非資源名稱是專有名詞（例如地名），沒有英文字地化變體。該值是每個人通常搜尋和記住的資料，因此建議使用清晰的名稱。
 |
|
- 型別： UTF-8 字串，使用者名稱標籤 的替代語言版本。
- 欄位定義： （其中XX 被替換為適當的 本地化程式碼，用於表示語言。）此資源的本地化人機可讀名稱。此欄位類似於使用者名稱欄位，但表示非英文語言環境。資源中可能存在多個使用者名稱-XX 標籤，每個支援的語言環境一個。如果在給定的終端使用者系統上沒有合適的 '使用者名稱-XX' 標籤來表示此資源，則改為使用英文的使用者名稱標籤。
- 型別： UTF-8 多行字串，提供資源的清晰語言描述。
- 欄位定義： 此資源的英文人機可讀描述摘要。
該描述在 Content Manager 的 '資源詳細資訊' 窗格中可見，用於澄清資源名稱、提供規格，以及通常的一些歷史資訊。
N3V 的 Chris Bergmann 已經說過，該欄位應該保持簡短（1-2 段），描述資源，並透過info-url 頁面提供擴充套件的詳細資訊，但可以容忍相當長的文字塊。有些人將該塊的底部用作版本更改記錄。
此欄位必須由英文描述性文字組成，儘管該文字可以引用非英文專有名詞，如其他地方所解釋的那樣。其他語言翻譯或源文字應放在多個可能的替代語言本地化標籤之一中（參見 description-xx 標籤）。
- 型別： UTF-8 多行字串，描述標籤。
- 欄位定義： （其中XX 被替換為適當的 本地化程式碼，用於表示語言。）此資源的本地化人機可讀描述摘要。此欄位類似於描述欄位，但表示非英文語言環境。資源中可能存在多個description-XX 標籤，每個支援的語言環境一個。如果在給定的終端使用者系統上沒有合適的 'description-XX' 標籤來表示此資源，則改為使用英文的描述標籤。
- 型別： UTF-8 字串列表容器，字串表容器。
- 欄位定義： 一個英文字串的鍵值列表。每個鍵都是一個有意義的指令碼識別符號，對映到二進位制資料並由二進位制資料引用。每個值都是一個英文字串。英文字串可以包含或引用非英文專有名詞作為識別符號。非英語母語編寫的資源必須在需要時仍然建立一個沒有後綴的字串表容器。軟體只連結到和引用沒有後綴的字串表容器中的名稱和值，這會讓西班牙語、法語、德語、捷克語、荷蘭語……日語作者感到非常困擾。換句話說，帶字尾的字串表只是為了翻譯目的，當地圖用非英語編寫時就會產生問題——沒有字串表-en 來提供反向翻譯的表。同樣，使用者名稱-en 和描述-en。所有三個缺乏的東西都證明了過時的和傲慢無禮的傲慢，以及對世界動態的漠不關心。
其他語言透過類似的字串表（例如 string-table-XX）支援，這些字串錶帶有與國際化字尾匹配的本地化程式碼字尾 (XX)，這些字尾用於描述和使用者名稱關鍵字/標籤，但這些語言鍵字串表容器的左側條目始終具有相同的鍵值。
- 這些左側鍵或標籤既充當“本地索引關鍵字”，也充當語言之間的“等效表”。
- 左側列始終包含內容建立者賦予“特殊”名稱的物件，例如訊號、軌道標誌和行業、連線點等的名稱，這些物件可能會被引用，並且會出現在駕駛員和測量員模組的“查詢工具” (CTRL+F ) 功能小程式中。
- 反過來，索引側也不會列出預設的名稱，例如大量連線點的名稱，這些連線點在構建路線圖時由隨機數自動索引（即毫無意義的混亂。如果重要，路線構建 CC 會命名它！）；但會自動包含潛在的臨時資產，例如火車車的預設名稱。如果重新命名，這些名稱將取代其相應的預設名稱。
- 它的主要用途是用於那些旨在與指令碼引用互動並獲取可變屬性的物件，例如火車站或行業需要的或準備在行業中裝運的產品數量，或由互動式火車車（滾動行業到指令碼）和其他可配置資產運送，這些資產簡單如通用廣告牌式標牌，透過調整高度和角度扭轉，可以放置在庫存建築或行業的正面，在建築物上放置不同的商業名稱。換句話說，這是一種可配置的風景。
- 總體而言，在路線圖或佈局中，這些 LHS 名稱對應於地圖資產上命名的物件，這也是大多數字符串表出現的地方（從字面上看，在大型路線kind map中，數千個條目填充了這些表）。
- 在某些資產中，該預設名稱被連線到軟體指令碼，因此字串表變得特別重要，而不是平淡無奇。（見下文）
- 在每種型別的資產中使用字串表型別始終是合法的，就像描述標籤和 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 和 string-table。特別是，與釋出捆綁在一起的路線和會話會收到專業的翻譯，涵蓋多個語言，並且每個零售版本都會進行翻譯。
請注意，字串表的左側列是相同的，因為它是一個對映符號表，並且索引到二進位制資料中，例如網格、會話或路線檔案。只有使用名稱，即兩個元素中的右側或資料元素才是本地化的，並且由執行時本地化軟體替換。如果需要，這些名稱可以手動編輯，以獲得更友好的名稱，即使在英語字串表中也是如此。索引或左側引用列語法在任何方面都不允許更改，因此在更改資料列中的名稱時，請謹慎使用全域性 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 列表容器，與obsolete-table 容器（下文）格式相同。一個虛擬引數+ 一個（依賴項）kuid
- 欄位定義：定義依賴於該資產的資產列表的鍵值。
- 通常
- 只有具有子元件或具有備選選擇（貨物）的資產才會有長度可觀的 kuid-table。大多數具有子元件的資產只有幾個。
- 其次，由於有時內部關鍵字是“自動定義”的，僅僅作為沒有名稱的數字列出，作為佔位符引數，假關鍵字可以是任何唯一值（通常是零索引的連續整數。[註釋 1]）它們可以被命名，也可以不被命名，由使用者或作者決定。
- 此表中的條目有兩個用途
首先：確保遊戲系統瞭解依賴項，以便安裝和載入此資產將成功安裝和載入任何依賴項，以及
其次：允許指令碼定位相關的子資產。 - 只能在 kuid-table 中包含第一級依賴項——具有自身依賴項的子資產或部分資產將在該子資產的驗證和資料庫提交中處理。
- 迴圈依賴項是非法的。
- 如果一個資產被標記為該資產的過時版本，則不能將其列為依賴項。（Trainz 資產索引（歷史上是 assets.tdx 檔案）中的 kuid 只有一個替換 kuid 槽，這將建立一個迴圈定義，要求它自己的舊版本！）
- 同樣，一個資產不能被列為它自己的依賴項。[另一方面，這在 TSxx CMs 中被體驗過（即，被證明是成功提交的無故障資產），將地圖和會話從安裝中移植到安裝中，使用 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 新增到裝載和允許的產品隊列表條目中留給學生去思考。（您應該感到高興，但這確實是一個更改名稱的充分理由！保持事物清晰幾乎是製作資產的全部戰役！）
- 型別: KUID 列表容器，與 KUID 表容器 格式相同。
- 欄位定義: 一個“佔位符鍵 - 鍵 - 值”資產列表，這些資產被此資產取代。任何嘗試載入此列表中的任何資產都會導致此資產被載入。
- 此外：兩個資產都不能標記第三個資產為過時，除非兩個資產之一也標記另一個資產為過時。[注 6]
- 迴圈過時引用是非法的。
- 此資產的所有低編號 KUID2 版本都被認為是過時的，不需要包含在此列表中。同時，具有更高 Kuid2 的更新改進資產及其其中一個前身不應將同一前身（例如原始版本！）列入到“中間”中間前身中，因為這些值用作 替代條目表，並且只有一個資產可以替代早期版本。（陣列只儲存一個值，不能將兩個值替換成一個！）
- 將此資產的更高編號 KUID2 版本標記為過時是非法的，因為這會導致隱式迴圈引用。
- 此列表中引用的資產必須與此資產具有相同的建立者，才能透過 DLS 上傳過程驗證和接受此資產，此限制不適用於您的本地版本，例如，它可能用於將大型火車車廂組中的所有舊紙輪 KUID 替換為一個更美觀、更新的 KUID。
- 用途：在 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"（大多數第一世界國家）
- 用途：在 CM 和 Surveyor 中篩選（搜尋條件）；根據 KIND 聲明確定 CM 軟體如何處理資產，以及 Surveyor 在哪裡列出資產。
- 型別: 列舉字串。
- 欄位定義: 一個單一的 2-3 字元 類別-類別 程式碼，用於描述此內容項。類別-類別 標籤用於提供超出資產 KIND 隱含內容的額外人類子分類。每個 Trainz 資產的類別-類別標籤有助於描述資產在遊戲中的“意圖”，而不是資產的內部結構。
|
|
請注意，許多類別-類別程式碼僅與特定資產 KIND 相關 - 類別-類別程式碼不得應用於不合適的 KIND 資產。
- 示例
| 類別-類別 "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"
}
}
另一個常見的大小是 調車場 和 Surveyor 資產選擇 API 中使用的 128x64“圖示”，它應該具有 Alpha 遮罩 或非常淺的背景。許多較舊的資產沒有使用 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 線上安全區 內的網站。目前，嵌入式瀏覽器接受三個域
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。
script-include-table 容器 是任何從 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 個字元）字母數字標記。字串中不應出現其他字元（包括空格）。
- 這些自定義類別用於使指令碼能夠快速定位特定類別的資產。強烈建議謹慎引入新的自定義類別識別符號。
- 自定義類別列表 標記值最多可以包含 64 個字元。除非存在只能透過自定義類別列表方法滿足的現有特定指令碼要求，否則應將此標記保留為空白。
- 最小版本： V3.5 及更高版本
- 型別： 成員組容器 配對的 佔位符引數 和 資產組 KUID 列表。
- 欄位定義： KIND_資產組 資產列表，此資產屬於這些資產。有關如何以及何時使用此功能的詳細資訊，請參閱 kind KIND 資產組 文件。
容器包含 KIND 資產組 KUID 的常規列表。此包含是一個宣告，表明此後，特別是在搜尋操作（包括指令碼介面和 TrainzUtil）中，此資產將被視為每個列出的資產組的成員。
如果在給定的“成員組”容器中未指定任何條目，或者如果資產省略了“成員組”容器，則模擬器軟體可能會根據資產的 Config.txt 檔案指定一些預設資產組。確切的行為可能在模擬器的不同版本之間有所不同，但是當前邏輯在 這裡 描述。
- 以下標記對於任何資產都不是強制性的，許多資產將它們留空。
- 從歷史上看，識別和許可標記從 Trainz 0.9（Beta）開始。
- 型別： UTF-8 多行字串。（由程式設計師法令廢棄。）
- 欄位定義： 一份許可證，描述資產建立者希望如何使用此資產。最常看到的是許可證宣告，禁止在任何付費路線、依賴資產（例如火車部件，如轉向架、聯軸器等）或重製中使用受版權保護的資產，包括在任何付費運營的網站上分發資產。（從理論上講，即使對於 DLS 也是如此。FCT 費用用於更快的訪問和無限下載，而不是用於訪問資產。）
- DLS 上的大多數資產都是 Creative Commons 署名-相同方式共享（CC-BY-SA）的措辭不當的版本，類似於此和其他維基百科維基專案。
- 許可證 標記的含義不明確，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 及其朋友。
|
|
- 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 標籤。
- 範圍： 在 v2.9 標準之前，在 軌道或橋樑資產 中發現，當時樣條物件經歷了重大的更改，以統一資料模型定義，在混合中刪除了一些先前的 KIND，而支援所有樣條物件統一在 kind track 下。
- 參見上面的 bendy，已棄用/過時的預 TS2009 遺留 kind track 標籤。
- 'name' 和 'name-XX' 是早期資料模型形式的更長的 username 和 username-XX 標籤，XX 代表英語“name 標籤”（或今天的“username”標籤）的非英語語言翻譯的 ISO 兩字母后綴；與 description-XX 一樣，“XX”形式是“本地化”支援其他語言的友好值的組成部分。
- 在最古老的 Trainz 時代（v1.0-v2.4）資產中用 username 和 username-XX 替換 name 和 name-XX，或者如果存在 username，只需刪除。
- 如果資產的 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 —歷史上幾乎所有值得本地化的資源中都有發現。這些已被兩個字母的列舉式 ISO 國家程式碼的“字串陣列”在category-region 標籤中取代。
- 用字串陣列型別 category-region 替換，在引用的標籤部分中，兩個字元國家程式碼之間沒有空格和分號；這些程式碼以完整的兩個大寫字母形式給出，包括列舉 程式碼，程式碼之間用“;”分隔符分隔，但在最後一個程式碼之前沒有分隔符，緊跟著結尾引號。
- 字串陣列中的任何空格都會導致讀取錯誤和錯誤訊息，包括結尾引號前的空格。
- region — TBS V1.3–v2.8 中的有效部分，作為內建過濾器和地圖資源自定義本地化識別符號（kuid）；現在唯一的合法標籤用途是在kind map（佈局）資源中。
- 作為以前的過濾器修飾符，該標籤在歷史上幾乎所有資源中都有發現，但它在滾動庫存、風景、樣條線資源、軌道型別（包括隧道和橋樑）以及具有一定程度本地化的路邊資源中尤其普遍。
- 地圖資源仍然保留關鍵字 Region，該關鍵字在 Map 配置中定義，但用途相反——成為kind region kuid 引用。因此，Region 在 Maps 中是必需的，並且自TS2012 以來，與標籤型別一樣，在曾經作為 TRS 系列版本 Surveyor 工具視窗的“分組資料”'快速過濾器'出現的眾多資源中是非法的。
- 在 TRS2009 之後，任何將 region 標籤對映到文字字串的操作都已過時，因為在程式設計師的思維中，他們用Pick List 替換了 Surveyor 工具中的“型別和區域”字串值的粗略過濾分組選擇器。這兩個標籤都有一些優點和缺點，並且都追溯到 Trainz 0.9 Beta 版本。
shadows 標籤
[edit | edit source]- 參見上面的 bendy，已過時/廢棄的 pre-TS2009 遺留kind track 資源模式控制標籤。
thumbnail 標籤
[edit | edit source]thumbnail 標籤是thumbnails container 的早期單檢視實現（在上面也簡要記錄過）。Trainz 的早期 pre-N3V 程式設計師版本會找到一個 .jpg 檔案，最好是大小為 240x180 畫素，位於主資源根資料夾、資源名稱_art 資料夾或資源名稱_body 資料夾中，並使用它在 CMP 和 DLS 中顯示資源，如果它被上傳。該標籤在 TRS2006 期間被棄用，因為 thumbnails container 是隨 v2.0（TRS2004-SP0）引入的。在TBV 保持在 v2.4 以下的舊修復資源中，縮圖通常仍會在較新的 CM 中正常工作，前提是它位於 _art 子資料夾中，並且資源名稱與使用者名稱匹配。
type 標籤
[edit | edit source]- type — V1.3–v2.8 —以前的過濾器修飾符，歷史上幾乎所有資源中都有發現，但它在滾動庫存、風景、樣條線、軌道型別（包括隧道和橋樑）以及路邊資源中尤其普遍。
- 與“region 標籤”類似，type 標籤在 Trainz 0.9—TC3 版本中作為“Surveyor 中的組過濾器”使用，它與 region 相結合，提供了更小的資源選擇（工具組）。自TS2009 以來，移除了這些本地可點選過濾器的功能和用途，取而代之的是一個新的、更繁瑣的過濾器。這些讓工具選擇變得快速簡單，而不是在工具選項卡之間切換時變得緩慢並暫停——如今的 pre-TANE 版本在工具選項卡之間來回切換時，通常會因重新載入整個選擇列表而顯得不堪重負。
- type 和 region 都預設設定為“All”，提供了與 TS09 及之後的版本中工具相同的超級列表。
註釋
[edit | edit source]- ↑ 資源提交（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 的依賴資源中取代不需要的付費資源，或者在網站上自行釋出。
- ↑ 關於 category 時代的標籤範圍：安全操作，已知有效。其他“未來十年”值應在依賴它們之前進行測試。
- ↑ 許多容器在列表中使用虛擬/佔位符名稱。這些可以是描述性詞語，只要它們不包含空格字元。在短語構造的名稱中使用下劃線或句點可以保持可讀性，並顯著增強清晰度。例如，貨運火車車廂可能裝載 45 種合法產品型別。這些將在依賴項容器中列出。使用 Coal、granite、crushed_limestone 等使維護和更改表格變得更容易。Jes Sayin 作為程式設計師自 '76 年起
- ↑ 在第二個 thumbnails container 示例中，還有一個 512x512 大小的影像，一個額外的影像。DLS 使用哪一個是未知的。還可以包含更大的影像尺寸，透過電子郵件聊天，T:ANE 可能支援一個大影像尺寸，它將在預覽操作或 DLS 列表中使用。N3V Games 通常不會發布此類資訊。
- ↑ 早期的做法可以追溯到 Trainz 1.x，使用關鍵字/標籤“thumb”和引號中的 pathspec 引用指向執行時選單的 240x180 縮圖影像。art 資料夾包含一個 512x512 的 tga 檔案，帶有 alpha 遮罩（通常為 bmp 檔案，但格式正確的 tga 檔案可以用作自 alpha 遮罩），以及 64x128 的選單圖示影像及其控制的 texture.txt 檔案。
- ↑ 在2014-2015年冬季與前版本經理James Moody進行的一次私人電子郵件交流中，關於這個主題，DLS上傳稽核軟體可能已經修改，以強制執行正確的縮圖容器。
- ↑ 關於類別時代-nn 與類別時代標籤值： TRS 將接受任一形式的類別時代資料；但是 TS2009-SP0 及更高版本從以前合法的關鍵字-值對中建立了錯誤，並試圖強制內容建立者更改程式設計師故意破壞的所有資源。後來 DLS 上傳軟體強制執行了轉換，但這更可接受，因為第一個操作會導致許多人花費數小時來修復，這些修復是不必要的，應該在稽核舊火車建造資源時透過軟體預篩選過程自動執行。這些操作實際上保證了舊資源的下載會存在錯誤。這是 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 程式碼 標準的更新資訊，這些標準隨著軟體功能的新增而有所改變。 |