Trainz/refs/TrainzBaseSpec
KIND TrainzBaseSpec 為所有 Trainz 資產型別的所有 config.txt ini 檔案 提供基本定義。TBS 提供了一些“標準標籤”，這些標籤對於任何和所有 Trainz 資產都是通用的（或者至少在法律上可以定義）[1]。
- 其中一些是強制性的，因為它們決定了資產的進一步處理以及 config.txt 檔案和其資料夾中的資產資料的解釋。
- 然而，大多數是可選的，並且在大多數子資產中可以省略使用標籤的定義行。
- None, Valid 和大部分對 defacto 父容器定義的所有內容都必要，config.txt 檔案是所有 Trainz 數字模型所必需的。KIND TrainzBaseSpec (TBS) 是一個根類，其他 Trainz 資源類都是從它派生的。
- 之所以說它們是派生的，是因為它們繼承了其中列出的引數定義的處理屬性（指令）和值，其中最關鍵的是 kind 標籤的值。這個列舉的詞語決定了資源的特定kind 宣告和要求，這些宣告和要求被新增到該資源配置檔案中 TBS 的定義中。其他關鍵的 TBS 定義資料也很重要，例如資源的名稱、Kuid 識別符號和版本、Trainz 構建值 (TBV) 以及其他具有廣泛可變的定義需求、適用性和範圍的資料，例如string-table、obsolete-table、kuid-table 和縮圖都是偶然的。字串值，甚至資源名稱和描述在實踐中通常完全沒有必要，並且可以完全省略。
- 當宣告一個 kind 時，該 kind 成為父類，除了 TBS 中列出的那些資料外，還需要並規定必須在該類中滿足的必要的成對資料。
- 某些引數可能在資源 kind 的情況下保持未定義，特別是對於較舊的 Trainz 構建標籤值的常見做法，對於這些標籤，內容管理器或內容建立者 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，那些帶有下劃線的 kind 是遺留 kind，早於 TS2009 版本中對 Trainz 資料模型 的更改（即從 2008 年後期開始），N3V 程式設計師只對這些更改施加了漸進的（增量的）更改。
目前可以在 N3V Trainz Wiki TrainzOnline 網站此處 的 內容建立者指南 部分找到基於這些遺留 kind 修復資源的詳細資訊，並附有具有啟發性的遺留 Kind 示例此處。強烈建議 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 | "'string-value'" |
| trainz-build | 'float', 1 位小數 |
| kuid | <Kuid 編碼值> |
| username | username "'string-value'" |
| username-XX | username-XX "'string-value'" |
| description | description "'string-value'" |
| description-XX | description-XX "'string-value'" |
| kuid-table (容器) { 依賴項列表 |
一個鍵值表，列出此資源依賴的所有資源。 |
| obsolete-table (容器) { } |
kuids 列出此資源替換（使其過時的）資源 通常沒有（為空）[註釋 5] |
| string-table (容器) { } |
資源中使用的字串和訊息的鍵值列表 通常為空，僅在路線和場景中較大。 |
| string-table (容器[s]) { 非英語 語言文字 } |
翻譯字串列表，匹配強制的英語 string-table |
| category-region tag 列舉 程式碼 | category-region "'string-array'" |
| category-class tag | category-class "'列舉 string-value'" |
| category-era tag | category-era "'約束字串陣列'" 十年 |
| category-keyword "'string-array'" 最大長度為 64 位元組 | category-keyword tag 自然語言搜尋關鍵字 (替換型別，區域) |
| custom-category-list "'string-array'" |
指令碼介面功能 |
| must-have-product-rights "'string-value'" |
DRM 字串陣列 |
| must-not-have-product-rights "'string-value'" |
DRM 字串陣列 |
| privileges (容器) { } |
更多 DRM |
| thumbnails (容器) { } |
縮圖容器 |
| script (檔名) | "'string-value'" |
| class (指令碼資源類) | "'string-value'", 必須與 script 規範類同步。 |
| script-include-table { } |
(列出庫指令碼的容器) |
| extensions (容器) { } |
資源也使用的正式指令碼擴充套件 |
| license "'string-value'" | 資源建立者的版權宣告 |
| author | "身份 'string-value'" |
| organisation | "第三方組身份 'string-value'" |
| contact-email | "電子郵件地址 'string-value'" |
| contact-website | "作者/組的網頁網址 'string-value'" |
| member-of-groups (容器) { } |
此資源所屬的 KIND Asset-group 資源列表。 |
支援的標籤
[edit | edit source]TrainzBaseSpec 在 config.txt 檔案 中支援以下標籤。 ∅:
kind tag
[edit | edit source]- 型別：字串。
- 欄位定義：此 config.txt 檔案 代表的資源型別。請參閱索引 種類 和列表：此處（上方）
kuid tag
[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 格式的更新和更新跟蹤修改版本，允許指定版本號。A
<kuid:xxx:yyy>等同於<kuid2:xxx:yyy:0>（零修訂或版本零，表示原始版本）。- 這允許資料項（Trainz 資源）攜帶資源的固有版本程式碼。這通常不會與CM Trainz-build 程式碼（標識軟體技術級別）匹配，但表示之前的版本歷史。
- 如果資料庫中存在兩個資源，那麼具有更高字尾程式碼的 KUID2 資源將覆蓋或替換較舊的資源。擁有早期版本並不必要，但 CM 會將缺失的修訂鏈列為缺失的依賴項，對於那些不喜歡 CM 中該功能被汙染的人來說這是一個軟體錯誤，或者程式設計師將其保留為“功能”，無論如何都會降低使用 CM 識別使用者缺少哪些內容的效用，並導致使用者花費時間手動找出哪些內容實際上是什麼。
trainz-build tag
[edit | edit source]- 主要覆蓋範圍：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 無服務包）到當前版本（v3.7 = TS12-SP1、v3.8 = Mac2、3.9=TANE-CE、4.0—4.3 及以後？）遞增 0.1。從 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 進軍蘋果電腦，打斷了基於 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 值。
- 型別： UTF-8 字串，資源的使用者名稱，必須指定。
- 欄位定義： 此資源的英文人眼可見的名稱。
在 TC1&2（v2.7）之後的 trainz-build 中，使用者名稱在編輯資源時也會成為作業系統資料夾名稱，並且資原始檔名會被忽略，而在 v2-6 配置檔案中它具有優先順序。根據 N3V games 的 TBS 標準，此欄位永遠不應該包含非英文文字，除非資源名稱是專有名詞（例如地名），並且沒有英文字地化變體。此值是每個人通常搜尋和記住的資料，因此建議保持清晰的名稱。
 |
|
- 型別： UTF-8 字串，使用者名稱標籤 的替代語言版本。
- 欄位定義：（其中XX 被替換為相應的 本地化程式碼，表示要使用的語言。）此資源的本地化人眼可見的名稱。此欄位類似於使用者名稱欄位，但表示非英文語言環境。一個資源中可能存在多個使用者名稱-XX 標籤，每個支援的語言環境一個。如果不存在適當的“使用者名稱-XX”標籤來在給定的終端使用者系統上表示此資源，則使用英文使用者名稱標籤。
- 型別： UTF-8 多行字串，提供資源的清晰語言描述。
- 欄位定義： 此資源的英文人眼可見的描述性摘要。
描述在內容管理器“資源詳細資訊”窗格中可見，用於闡明資源名稱、提供規格以及經常包含一些歷史資訊。
N3V 的 Chris Bergmann 已經宣告此欄位應該保持簡短（1-2 段）的描述資源的簡短說明，並透過info-url 頁面提供擴充套件的詳細資訊，但可以容忍相當長的文字塊。有些人使用塊的底部作為版本更改記錄。
此欄位必須由英文描述性文字組成，儘管文字可能引用非英文專有名詞，如其他地方所述。其他語言翻譯或源文字應放置在眾多可能的替代語言本地化標籤之一中（參見 description-xx 標籤）。
- 型別： UTF-8 多行字串，描述標籤.
- 欄位定義：（其中XX 被替換為相應的 本地化程式碼，表示要使用的語言。）此資源的本地化人眼可見的描述性摘要。此欄位類似於描述欄位，但表示非英文語言環境。一個資源中可能存在多個description-XX 標籤，每個支援的語言環境一個。如果不存在適當的“description-XX”標籤來在給定的終端使用者系統上表示此資源，則使用英文描述標籤。
- 型別： UTF-8 字串列表容器，字串表容器.
- 欄位定義： 英文字串的鍵值列表。每個鍵都是一個有意義的指令碼識別符號，對映到二進位制資料並被二進位制資料引用。每個值都是一個英文字串。英文字串可能包含或引用非英文專有名詞作為識別符號。由非英語母語人士創作的資源必須在需要時建立沒有後綴的字串表容器。軟體只連結到和引用字串表容器中沒有後綴的名稱和值，這將讓西班牙語、法語、德語、捷克語、荷蘭語……日語作者感到十分沮喪。換句話說，帶字尾的字串表僅僅是為了翻譯目的，這在用非英語編寫地圖時會導致問題——沒有 string-table-en 來提供反向翻譯的表格。同樣，username-en 和 description-en 也一樣。這三者的缺失表明了一種過時且傲慢和對世界動態缺乏敏感性的態度。
其他語言透過類似的字串表（例如 string-table-XX）來支援，其本地化程式碼字尾 (XX) 與描述和使用者名稱關鍵字/標籤的國際化字尾匹配，但這些語言鍵入的字串表容器在左側條目中始終具有相同的鍵值。
- 這些左側的鍵或標籤既用作'本地索引關鍵字'，又用作'語言之間的等效表'。
- 左側欄將始終包含內容創作者賦予“特殊”名稱的物件，例如可能被引用的訊號名稱、軌道標記和行業、連線點等等，並且將在駕駛員和測量員模組的“查詢公用設施”（CTRL+F ) 功能小程式中出現。
- 相反地，索引側也不會列出地點的預設名稱，例如在構建路線圖時，由隨機數自動索引的無數個連線點（即毫無意義的混亂。如果重要，路線構建 CC 會給它命名！）；但會自動包含可能臨時的資產，例如火車車的預設名稱。如果重新命名，這些名稱將取代其對應的預設名稱。
- 它的主要用途是針對那些旨在與指令碼引用介面並獲取可變屬性的物件，例如火車站或行業需要的或準備在行業發貨的產品數量，或者由互動式火車車（滾動行業到指令碼）和其他可配置資產運載，這些資產就像一個通用的廣告牌風格的標誌一樣簡單，只需進行一些高度調整和角度扭轉，就可以放置在庫存建築或行業的立面前面，以便在建築上放置不同的商業名稱。換句話說，這是一種可配置的場景。
- 總體而言，在路線圖或佈局中，這些左側欄名稱對應於地圖資產上的命名物件，這也是大多數字符串表出現的地方（從字面上看，由大型路線種類圖中的數千個條目填充）。
- 在某些資產中，該預設名稱被掛鉤到軟體指令碼中，因此字串表變得特別重要，而不是令人厭煩。（見下文）
- 在每種型別的資產中使用字串表型別始終是合法的，就像描述標籤、trainz-build 標籤和種類標籤一樣。與它們不同，它不必存在或定義，並且絕非強制性。封裝在字串表容器中的值只有在程式碼期望它們結合時才具有功能或效果。
- 在其他資產中，同樣以那個假設的可程式設計商業標誌為例，如果字串表要與軟體介面，則必須給它一個預設名稱。所有地圖可放置資產都可以命名或重新命名，但“特殊名稱”必須在指令碼和字串表索引值中匹配。大多數可配置資產定義了一個介面變數，用於替換預設名稱作為索引或查詢表，該表引用指令碼和資產的二進位制資料。其他變數也可能在可程式設計資產中定義。這些變數都可以透過指令碼引用，但正是索引值使它進入地圖或會話字串表，當需要駕駛員或會話建立者可變性時，這一切使它們協同工作。
- 相反，如果沒有系統軟體知道索引中命名專案的所在位置，則物件的指令碼可能不會有任何觸發、條件檢查或更新能力。這是 2000 年代Trainz 1.0中物件的特徵，而不是 2003 年釋出的TRS2004之後更現代的 Trainz 鐵路模擬器。（從那時起，我們已經走過了很長的路！)
- 有一些資產只能作為一組一起工作。在這種情況下，在地圖或會話層中對每個資產進行命名，使它們能夠一起運作。例如，考慮一個具有五條軌道的公路平交道，其中兩條軌道偏離連線點，並與貫通軌道形成所謂的“鑽石交叉”。如何設定訊號，以便任何鐵路交通都關閉公路道口，或者使用鑽石交叉禁止其他火車穿過正在穿越道口的火車。道路和鐵路訊號以及道岔和道口都必須協同工作。某些“ATLS 系統”資產及其指令碼透過字串表結合起來，可以使這個複雜的系統發揮作用。
- 有關更多資訊，請參見 string-table-XX。
string-table-XX 容器
[edit | edit source]- 型別： UTF-8 字串列表容器，本地化字串表，每個字尾對應於除英語之外的語言。
- 欄位定義：（其中XX被替換為適當的本地化程式碼，表示所代表的語言。）此欄位類似於字串表欄位，但表示非英語語言環境。
英語字串表（無後綴）是強制性的，其他本地化語言在資產作者的要求下是可選的。提交到 DLS 然後在與 Trainz 版本捆綁的路線中使用的許多資產通常會被翻譯，併為 description-XX 和字串表提供完整的本地化翻譯集。特別是，與版本捆綁的路線和會話將在每次零售版本釋出時接受專業翻譯成多種語言。
請注意，字串表的左側欄是相同的，因為它是一個對映的符號表，並且索引到二進位制資料（例如網格、會話或路線檔案）。只有使用名稱，即兩個元素中的右側或資料元素被本地化並由執行時本地化軟體替換。如果需要，這些名稱可以在英語字串表中手動編輯，以獲得更友好的名稱。索引或左側引用欄語法絕不能以任何方式更改，因此在資料欄中更改名稱時，請注意全域性 SAR 規範。
資產中可能存在多個string-table-XX標籤，每個支援的語言一個。每個標籤都應該包含一個字串列表，其鍵與字串表列表中的鍵相同，但值不同。如果不存在適當的“string-table-XX”標籤來表示給定終端使用者系統上的此資產，或者該列表中缺少適當的字串，則將引用英語字串表容器。
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 只有一個替換 kuid 插槽，這將建立一個需要自身舊版本的迴圈定義！）
- 類似地，某個資產不能被列為其自身的依賴項。[OTOH，這已被體驗過（即，在 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 新增到裝載和允許的產品隊列表條目中。（歡迎，但這是更改名稱的好理由！保持清晰幾乎是製作資產的整個戰鬥！）
obsolete-table 容器
[edit | edit source]- 型別： KUID 列表容器，與Kuid-table 容器的格式相同。
- 欄位定義：一個“佔位符鍵—鍵值”列表，其中包含由此資產廢棄的資產。嘗試載入此列表中的任何資產將導致載入此資產而不是該資產。
- 此外：兩個資產都標記第三個資產為已棄用是非法的，除非這兩個資產中的一個也標記另一個為已棄用。[note 6]
- 迴圈已棄用引用是非法的。
- 所有比此資產的KUID2版本編號低的版本都被認為是過時的，無需列入此列表。同時，一個具有更高Kuid2的新改進資產與其前身絕不應列出相同的前身（例如原始版本！）到“中間”的中間前身，因為這些值被用作替代項表條目，並且只有一個資產可以替換為早期版本。（陣列只儲存一個值，不能用兩個值替換一個！）
- 將此資產的更高編號的KUID2版本標記為過時是非法的，因為這會建立隱式的迴圈引用。
- 此列表中引用的資產必須與此資產具有相同的建立者，才能透過DLS上傳過程進行稽核和接受，此限制在您的本地版本中不適用，例如，它可用於將大型火車車組上所有舊的紙質車輪kuid替換為圖形更美觀且更新的車輪。
category-region 標籤
[edit | edit source]- 用途：在CM和Surveyor中過濾（搜尋條件）
- 型別：列舉字串或字串陣列。
- 欄位定義：由分號（';'）分隔的兩個字元類別區域標籤程式碼列表。字串中不應該存在其他字元（包括空格等）。此資產被認為與每個指定的區域相關 - 這對於火車車組種類和訊號種類資產最為相關，但可以為任何資產提供。
- 示例
- 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"（大多數第一世界國家）
category-class tag
[edit | edit source]- 用途：在CM和Surveyor中過濾（搜尋條件）；與KIND宣告一起確定CM軟體如何處理資產，以及Surveyor在何處列出資產。
- 型別：列舉字串。
- 欄位定義：一個單一的2-3個字元類別分類程式碼，它描述了此內容項。類別分類標籤用於提供超出資產種類隱含內容的額外人類子分類。每個Trainz資產的類別分類標籤有助於描述資產在遊戲中的“意圖”，而不是資產的內部結構。
|
|
請注意，許多類別分類程式碼僅與特定資產種類相關 - 類別分類程式碼不得應用於不適當種類的資產。
- 示例
| category-class "XBG" | 箱車 - 來自PRR 60' | |
| category-class "BR" | 鐵路（非功能性場景） - 可能是一棟建築 | |
| category-class "BIN" | 具有產品處理功能的工業資產 |
category-era tag
[edit | edit source]- 每個年代程式碼代表一個十年，由一個四位數的整陣列成，然後必須以's' 結尾
(例如 "1990s;2000s;2010s"),從而建立一個列舉軟體標記（值），該標記必須與一個指定的合法年代程式碼完全匹配。 - 字串中不應該存在其他字元（包括空格等），包括（尤其是在字串末尾）在結束雙引號字元之前。
- 允許的年份範圍是 1800-2010s[note 7]
- 此資產的唯一意義是對其他人來說，即該資產被認為在指定的年代範圍內是有效的和適當相關的，並且內容管理器將接受指定適用年份的搜尋過濾器。
- 示例
category-era "1920s;1930s;1940s;1950s"
縮圖容器
[edit | edit source]- 用途：在CM和Surveyor中過濾（搜尋條件）
- 型別：縮圖容器.
- 欄位定義：用於在整個遊戲環境（包括在遊戲中、在內容管理器中以及在下載站上）的二維預覽框、列表和圖示形式中表示此資產的縮圖。每個資料集都包含在一個子容器中（通常）使用佔位符引數作為鍵名或標籤。[note 8] 慣例使這些成為 0 索引整數，但該值可以是任何可以評估為字串的非空文字值。（參見下面的第二個示例）
- 一個實際的示例
- (來自資產修復編輯[3])
thumbnails {
0 {
width 240
height 180
image "$Screenshot (240)(kuid 68787 25222).jpg"
}
1 {
width 512
height 512
image "$Screenshot (512)(kuid 68787 25222).jpg"
}
}
另一個常見的大小是調車場和勘察員資產選擇 API 中使用的 128x64 '圖示'，它應該具有Alpha蒙版或非常淺的背景。許多較舊的資產沒有使用 jpg 檔案，而是列出了 _art 子資料夾中的 .tga 檔案（Targa 真彩色）（Trainz 1.0 - TC3 慣例：_art、_body 和 _shadow 是由早期 Trainz 資料模型要求命名的“資產檔名字尾”（過時的標籤-<值> 對）強制的三個子資料夾），如下所示[note 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 的早期版本中標記沒有縮圖容器的資產為錯誤。補丁後來將其變成了警告。[note 10] 這種做法在 TS12 的一個熱修補程式中被放棄，此前使用者社群對此提出了很多抱怨。
• 如果缺少縮圖容器的資產（即使具有過時的拇指標籤）後來在新構建的內建路線或會話中被選擇，該資產通常將作為一個沒有影像的專案進行分發 - 如果沒有被 texture.txt 或 config.txt 縮圖容器正確引用，它們將被剝離出來。[note 11]
軟體連結
[edit | edit source]
info-url 標籤
[edit | edit source]- 型別：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。
指令碼包含表容器 是 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 容器|自定義類別列表容器|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 資產組 文件。
該容器包含一個 KIND 資產組 KUID 的常規列表。此包含宣告，此後，特別是在搜尋操作中（包括指令碼介面和 TrainzUtil），此資產將被視為每個列出的資產組的成員。
如果未為給定的“成員組”容器指定任何條目，或者如果資產省略了“成員組”容器，則模擬器軟體可能會根據資產的 Config.txt 檔案指定一些預設資產組。模擬器不同版本之間的確切行為可能會發生變化，但是當前邏輯在 此處 描述。
- 以下標籤對於任何資產都不必強制要求，許多資產都將其留空。
- 從歷史上看，識別和許可標籤從 Trainz 0.9（Beta）開始。
- 型別: UTF-8 多行字串。（透過程式設計師法令棄用。）
- 欄位定義: 描述資產建立者希望如何使用此資產的許可證。最常見的是許可證宣告禁止在任何付費路線、依賴資產（例如轉向架、耦合器等火車部件）或重繪中使用受版權保護的資產，包括在任何付費運營的網站上分發資產。（這在理論上對於 DLS 也是正確的。FCT 費用用於更快的訪問和無限下載，而不是訪問資產。）
- DLS 上的大多數資產都是關於 知識共享署名-相同方式共享 3.0 未移植許可（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 及其下面的朋友。
|
|
- 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 tag'（或今天的 'username' 標籤）非英語語言翻譯的 ISO 兩字母后綴；'XX' 形式與 description-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 —在歷史上幾乎所有需要本地化的資產中都能找到。這些標籤已被 category-region 標籤中的 兩個字母列舉的 ISO 國家程式碼的 '字串陣列' 所取代。
- 使用字串陣列型別的 category-region 替換，標籤中不包含空格，兩個字元的國家程式碼之間用分號隔開，這些程式碼在參考標籤部分進行了列舉；這些程式碼以兩個大寫字母的形式給出，組成 列舉 程式碼，程式碼之間用 ';' 分隔符隔開，但在最後一個程式碼之前（末尾引號之前）沒有分隔符。
- 字串陣列中的任何 空格（包括末尾引號之前的空格）都會導致讀取錯誤和故障訊息。
- region —TBS V1.3–v2.8 的有效部分，作為內建過濾器和地圖資產自定義本地化識別符號（kuid）；現在，唯一合法的標籤用法是在 kind map（佈局）資產中。
- 作為以前的過濾器修飾符，此標籤在歷史上幾乎所有資產中都能找到，但它在車輛、景觀、樣條資產、軌道型別（包括隧道和橋樑）和具有某種程度本地化的路旁資產中尤其普遍。
- 地圖資產仍然保留關鍵字 Region，該關鍵字是在地圖配置中定義的，但其用途相反——作為 kind region kuid 引用。因此，Region 在 Maps 中是必需的，並且自 TS2012 以來，與標籤型別一樣，在大量資產中，它曾經作為 TRS 系列版本 Surveyor 工具視窗的 '分組資料' '快速過濾器' 出現，現在已不再合法。
- 在 TRS2009 之後，任何以文字字串形式出現的 region 標籤都已過時，因為在程式設計師看來，他們用 Pick List 替換了 Surveyor 工具中 '型別和區域' 字串值的 粗略過濾 組選擇器。這兩個標籤都有一些優點和缺點，並且都追溯到 Trainz 0.9 Beta 版本。
- 參見上面的 bendy，已棄用/過時的 TS2009 之前的傳統 kind track 資產模式控制標籤。
縮圖標籤是早期縮圖容器（上面也有簡要介紹）的單檢視實現。Trainz 早期的 N3V 程式設計版本會找到一個 .jpg 檔案，最好大小為 240x180 畫素，位於主資產根目錄、資產名稱_art 資料夾或資產名稱_body 資料夾中，並將其用於在 CMP 和 DLS 中顯示資產（如果已上傳）。自 v2.0（TRS2004-SP0）引入了縮圖容器後，該標籤在 TRS2006 期間已棄用。在較舊的已修復資產中，如果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 直到足夠低，反之亦然，較舊的 TBV 無法識別的較新的關鍵字可能會顯示不同的錯誤訊息。儘管如此，也不要害怕嘗試——即使失敗，也會產生知識和經驗，而且你無法破壞任何東西！如果是這樣，您可以確信，只提供一個值就是問題的解決方案。通常，一些現代需求只需要關鍵字對，因此在標籤後面新增空白行，或在容器的標籤後面新增一組空的花括號就可以滿足需求，而錯誤測試則有些過於嚴格。
- ↑ 注意：此列表在 N3V TrainzOnline Wiki 上已“維基化”，這意味著第一個字母在“KIND”一詞之後已大寫，而 config.txt 檔案中的實際資料標籤名稱全部為小寫文字。該維基還使用雙引號來表示一些術語，我們將在本文件中避免這種做法。
- ↑ “kind consist” 並不經常直接看到，它只存在於選單和內容管理器列表中。
- ↑ 必須謹慎使用過時表，它最常見於 Auran 編寫的資產中。該表將較舊的 KUID 替換為較新的 KUID，大多數內容建立者都適當地使用 kuid 的 Kuid2 形式來取代較舊的版本。相比之下，N3V 過度使用了過時表來更新新發布的內建資產，這會導致很多混淆，並且無法獲得預期看到的結果。（例如，TS10 和 TS12 中許多不錯的“翻轉樹”被速度樹取代，而速度樹並非路線建立者所需要或希望的。在跨安裝過程中，這也會導致缺少依賴項，直到找到包含過時表的資產。
• 此外，Assets.tdx 資料庫索引中每個 kuid 只支援一個過時條目，用 Kuid2 版本替換 kuid 可能會導致問題（即您將看到哪個？）。
• 過時表的一個絕佳用法是升級使用特定部件（尤其是轉向架）的一系列資產。新增混合的 kuid 以更現代的轉向架替換，可以極大地改善路線或會話的外觀，只需進行一次編輯（前提是轉向架等相容且尺寸合適！）。 - ↑ 最近將一個過時的資產匯入 TANE 的經驗表明，至少有五個備選的 kuid 替代了這個可憐的翻轉樹資產。似乎隨著速度樹的引入所帶來的混亂以及 TANE 的大修，它積極地尋求最合適的更新資產，現在 ContentManager 程序允許存在多個不同 kuid 的資產來替換同一個 kuid。作為一種良好的做法，只有在絕對必要時才使用過時表...例如，用您要上傳到 DLS 的依賴資產中不需要的付費資產來替代，或者在網站上自行釋出。
- ↑ 關於類別時代標籤範圍：已知有效的安全播放。其他“未來十年”的值應該在依賴它們之前進行測試。
- ↑ 許多容器在列表中使用虛擬/佔位符名稱。這些名稱可以是描述性詞語，只要它們不包含空格字元即可。在短語構造的名稱中使用下劃線或句點可以保留可讀性並顯著增強清晰度。例如，一輛貨運車廂可能裝載 45 種合法產品型別。這些將在依賴項容器中列出。使用 Coal、granite、crushed_limestone 等可以更容易地維護和更改表格。Jes Sayin' 作為程式設計師，自 1976 年以來一直從事程式設計
- ↑ 在第二個縮圖容器示例中，還有一個第二個大小為 512x512 的影像，一個額外的影像。DLS 將使用哪個影像尚不清楚。還可以包含更大的影像尺寸，透過電子郵件聊天，T:ANE 可能支援更大的影像尺寸，該尺寸將在預覽操作或 DLS 列表中使用。N3V Games 通常不釋出此類資訊。
- ↑ 早期的做法可以追溯到 Trainz 1.x，當時使用關鍵字/標籤“thumb”以及帶引號的 pathspec 引用指向執行時選單的 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 使用者組的成員添加了增強資訊。
腳註
[edit | edit source]- ↑ 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 程式碼 標準的更新資訊，這些標準隨著軟體功能的增加而不斷變化。 |