Trainz/refs/TrainzBaseSpec
(重定向自 Trainz/era code)
KIND TrainzBaseSpec 提供了所有 Trainz 資產型別在所有 config.txt ini 檔案 中的基礎定義。TBS 為許多“標準標籤”提供支援，這些標籤對（或至少，可以在合法的情況下定義）任何和所有 Trainz 資產[1] 都是通用的。
- 其中一些是強制性的，因為它們決定了資產的進一步處理以及對 config.txt 檔案及其資料夾中資產資料的解釋。
- 然而，大多數是可選的，並且在大多數子資產中，可以使用該標籤的定義行可以省略。
- 所有由實際父容器定義的內容（大部分必要）都沒有，有效並且大部分都必要， config.txt 檔案是所有 Trainz 數字模型所需的。KIND TrainzBaseSpec (TBS) 是一個根類，其他 Trainz 資源類從它派生。
- 之所以說它們是派生的，是因為它們繼承了其中列出的引數定義的處理屬性（指令）和值，其中最關鍵的是 kind 標籤的值。該列舉詞決定了資源的特定種類宣告和要求，這些宣告和要求將新增到這些資源配置檔案中的 TBS 的定義中。其他重要的 TBS 定義資料也具有明顯的意義和作用，例如資源的名稱、Kuid 識別符號和版本、Trainz 構建值 (TBV) 以及其他具有廣泛可變定義、適用性和範圍的屬性，例如字串表、過時表、kuid 表和縮圖影像都是偶然的。即使資源名稱和描述這樣的字串值，在實踐中也往往完全沒有必要，並且可以完全省略。
- 當宣告一個種類時，該種類將成為父類，除了 TBS 中列出的資料外，它還需要並規定必須在該類中滿足的必要的成對資料。
- 某些引數可能未在某個資源的種類案例中定義，尤其是在較早的歷史 Trainz 構建標籤值中，對於那些，內容管理器或內容建立者 Plus (CCP) 實用程式將分配一個預設值，但在處理它時列出警告訊息。TrainzOnline 維基、這裡或較早的TC3 時代 內容建立者指南 (CCG) 中的許多標籤將提到一個預設值。
- 從 TRS2006 和 Trainz Classics (TC1&2) 開始，每個版本的 Content Manager 模組都會越來越多地施加預先承諾的錯誤測試[註釋 1]，並且每個版本都越來越堅定地警告說，當它期望這樣的標籤-資料對時，這樣的標籤尚未定義。
在 TANE 之後版本中，許多以前預設定義的這些行，現在更經常地會產生錯誤，要求明確定義值，而以前在載入時這些值是預設的。 [註釋 2]與舊時代相比，這是一種更好的煩惱，在舊時代，錯誤的資源定義有時會導致臭名昭著的“藍色畫面宕機”，或者更常見的是將執行時軟體崩潰回桌面，導致編輯丟失，並且可能需要重建資料庫。
子類
[edit | edit source]
所有 Trainz 定義的資料（內容）都有三個必需的元素：一個 config.txt 檔案 來組織資料，一個身份，即 kuid（僅使用者名稱對你沒有用，但是，可以建立合法的資源而無需名稱！）最後，一個合法定義的種類標籤。種類負責，是管絃樂隊的指揮、排長或 CEO 指示——為之後處理的所有內容設定要求。簡而言之，種類的值，一個由少量嚴格定義的會員組成的群體——告訴 Trainz 軟體在虛擬世界中渲染和顯示什麼，以及如何（或在何處）找到將這些資源的一部分連結在一起的配置檔案中的其他部分。
下面的每個子類都被認為具有 TrainzBaseSpec 作為其資料的“父類”。 [註釋 3]下面列出的一些種類（那些帶下劃線的）是遺留種類，早於TS2009 釋出時對Trainz 資料模型 的更改（即自 2008 年後期以來），N3V 程式設計師僅對它實施了逐漸（增量）的更改。
目前可以在 N3V Trainz 維基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' 結尾。
| 型別 | "'字串值'" |
| 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 | "作者/組網站 URL '字串值'" |
| member-of-groups (容器) { } |
此資源所屬的 KIND 資源組 資源的列表。 |
支援的標籤
[edit | edit source]TrainzBaseSpec 在 config.txt 檔案 中支援以下標籤。 ∅:
kind 標籤
[edit | edit source]- 型別: 字串。
- 欄位定義: 此 config.txt 檔案 所代表的資源型別。請參見索引 型別 和列表：此處（上方）
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 標籤，縮寫: TB & TBV (TB-value)∅
- 型別: N3V 使用一個一位小數的浮點數 列舉[2] 來跟蹤和識別與演變軟體技術級別相對應的資料型別。
- 範圍: 1.0–4.3 直接對應（'對映onto3rd' Trainz 1.0—TANE-SP1+hf2；預計此值將隨每次主要軟體升級而遞增 0.1。
每個合法值必須與釋出的 Trainz 版本號 完全匹配，但以下情況除外
- 版本號為 V1.4 的 TBV 或版本值是 Auran 的 Paintshed 版本，這是一個重製工具，也適用於 Microsoft Trainz Simulator (MSTS)，並且也作為 TRS2004 輔助軟體模組的構建值出現；特別是它的 ContentManager.exe 實用程式。
- 1.7 和 2.0 之間的差距可能是外語版本，或者更可能是經過幾個小時的挖掘和研究後發現的，因為在構建了最初 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 SPs TBDL）。
- 從 v2.0 (TRS2004) 開始，Trainz-build 標籤值已經透過 23 個步驟遞增，這些步驟是連續的，儘管是非單調的，因為 Trainz TS09-sp3—TS09-sp4 共享一些 Trainz-build[2] 值；也就是說，在 TS2009 和 TS2010 的聯合開發時代和釋出中，有一些 TBV 是重疊的。
- 此外，N3V 進軍 Macintosh 電腦，打斷了基於 Windows 的 Trainz 版本 TBV 3.4、3.5、3.6、3.7 和 3.8 在 Windows 和 Mac 作業系統之間混合的平穩遞增。
注意： 熱修復 不會改變版本號。
- 欄位定義： 此資產構建（和存檔）到的檔案格式版本，不一定與資產使用的技術級別有任何關係，但對應於在 Content Creator Plus 中建立資產時分配的資產級別——與在 CM 標題欄中找到的一樣。
- 程式設計師建議這個數字通常應該設定為建立和測試資產的 Trainz 安裝的 Trainz 版本號。相比之下，內容建立者社群試圖將這個數字設定得儘可能低，以便在下載新資產時，儘可能擴大新資產的受眾/使用者範圍。 優秀的素材製作者會在對應版本的裸機安裝（沒有新增素材）上進行測試，並驗證生成的 cdp 檔案是否包含所有相關材料。
- 一些資產型別會根據它們的 trainz-build 版本標籤進行顯著不同的解析。注意：trainz-build 標籤 是強制性的。如果沒有指定，Trainz 將根據 config.txt_file 的內容嘗試猜測一箇舊版 Trainz 版本，這通常會將 TBV 解析為 1.3。
使用者名稱標籤
[edit | edit source]- 型別： UTF-8 字串，資產的 使用者名稱，強制規範。
- 欄位定義： 此資產的英文人機可讀名稱。
在 TC1 和 TC2（v2.7）之後的 trainz-builds 中，使用者名稱也成為在編輯資產時作業系統的資料夾名稱，並且資產檔名被忽略，而它在 v2-6 配置檔案中的優先順序更高。根據 N3V 遊戲的 TBS 標準，此欄位不應包含非英文文字，除非資產名稱是專有名詞（例如，地名）並且沒有英文字地化變體。此值是每個人通常搜尋和記住的資料，因此建議保持一個清晰的名稱。
 |
|
使用者名稱-XX 標籤
[edit | edit source]- 型別： UTF-8 字串，使用者名稱標籤 的備用語言版本。
- 欄位定義： （其中 XX 被替換為表示的語言的適當的 本地化程式碼。）此資產的本地化人機可讀名稱。此欄位類似於 使用者名稱 欄位，只是表示非英文語言環境。資產中可能存在多個 username-XX 標籤，每個支援的語言環境一個。如果適當的 'username-XX' 標籤不存在，則在給定的終端使用者系統上代表此資產，則使用英文 使用者名稱 標籤。
描述標籤
[edit | edit source]- 型別： UTF-8 多行字串，提供資產的清晰語言描述。
- 欄位定義： 此資產的英文人機可讀描述性摘要。
描述在內容管理器“資產詳細資訊”窗格中可見，用於闡明資產名稱，提供規格，以及通常的歷史資訊。
N3V 的 Chris Bergmann 已經說過，此欄位應該保持簡短（1-2 段），描述資產並透過 info-url 頁面提供擴充套件詳細資訊，但允許相當長的文字塊。有些人使用塊的底部作為版本更改記錄。
此欄位必須包含英文描述性文字，儘管文字可以參考非英文專有名詞，如其他地方所述。其他語言翻譯或源文字應該放置在許多可能的備用語言本地化標籤中的一個（參見 description-xx 標籤）。
description-XX 標籤
[edit | edit source]- 型別： UTF-8 多行字串，描述標籤。
- 欄位定義： （其中 XX 被替換為表示的語言的適當的 本地化程式碼。）此資產的本地化人機可讀描述性摘要。此欄位類似於 描述 欄位，只是表示非英文語言環境。資產中可能存在多個 description-XX 標籤，每個支援的語言環境一個。如果適當的 'description-XX' 標籤不存在，則在給定的終端使用者系統上代表此資產，則使用英文 描述 標籤。
字串表容器
[edit | edit source]- 型別： UTF-8 字串列表容器，字串表容器。
- 欄位定義： 一個英文字串的鍵值列表。每個鍵都是一個有意義的指令碼識別符號，對映到二進位制資料並由二進位制資料引用。每個值都是一個英文字串。英文字串可以包含或引用非英文專有名詞作為識別符號。 非母語為英語的作者必須仍然建立一個沒有後綴的字串表容器，如果需要的話。軟體只連結到並引用字串表容器中沒有後綴的名稱和值，這會讓西班牙語、法語、德語、捷克語、荷蘭語……日語作者感到非常厭煩。換句話說，帶字尾的字串表僅用於翻譯目的，這會在地圖以非英語編寫時產生問題——沒有 string-table-en 來提供用於反向翻譯的表。同樣，username-en 和 description-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 版本捆綁的路線中使用的許多資產通常會被翻譯，並且擁有描述-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，編輯。
- 格式 (所有值都是 <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>
} ...
注意連線單詞的下劃線...兩個符號，鍵和值！我們將找出如何將 kuids 新增到負載和允許的產品隊列表條目中，讓學生來處理。（不用謝，但這確實是一個更改名稱的好理由！保持清晰是製作資產的關鍵！）。
- 型別： KUID 列表容器，與 Kuid-table 容器 格式相同。
- 欄位定義： 被此資產標記為過時的資產的“佔位符鍵-鍵-值”列表。嘗試載入此列表中的任何資產將導致載入此資產而不是其他資產。
- 此外：兩個資產都標記第三個資產為過時是非法的，除非兩個資產中的一個也標記另一個資產為過時。[注 6]
- 迴圈過時引用是非法的。
- 此資產的所有低編號 KUID2 版本都被隱式地視為過時，不需要包含在此列表中。同時，一個更新改進的資產（具有更高的 Kuid2）和它之前的其中一個不應該將同一個之前版本（比如原始版本！）列入到“中間”之前的版本中——因為這些值用作替代條目表，而且只有一個資產可以替代之前的版本。（陣列只儲存一個值，並且不能將兩個值替代一個！）
- 將此資產的更高編號 KUID2 版本標記為過時是非法的，因為這會建立隱式迴圈引用。
- 此列表中引用的資產必須與此資產具有相同的建立者，以便資產透過 DLS 上傳流程進行稽核和接受，此限制不適用於本地版本，例如，它可用於將一大組火車車的舊紙質車輪 kuids 替換為更圖形化且更新的車輪。
- 目的：在 CM 和 Surveyor 中進行過濾（搜尋條件）
- 型別： 列舉字串或字串陣列。
- 欄位定義： 由分號 (;) 分隔的兩個字元的 類別區域標籤 程式碼列表。字串中不應該存在其他字元（包括空格等）。此資產被認為與每個指定的區域相關——這對於 火車車型別 和 mosignal 型別 資產非常重要，但可以為任何資產提供。
- 示例
- 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 個字元的 類別類 程式碼，描述此內容項。類別類 標籤用於在資產 KIND 隱式提供的基礎上提供額外的使用者子分類。每個 Trainz 資產的類別類標籤有助於描述資產在遊戲中的“意圖”，而不是資產的內部結構。
|
|
請注意，許多類別類程式碼只與特定資產 KIND 相關——類別類程式碼不得應用於不合適的 KIND 的資產。
- 示例
| 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"
}
}
另一個常見尺寸是 128x64 的“圖示”，用於 鐵路場 和測量員資產選擇 API，它應該有一個 Alpha 遮罩 或一個非常淺的背景。許多較舊的資產沒有使用 jpg 檔案，而是列出了 .tga 檔案（Targa 真彩色）在一個“_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 的一個熱修復程式中被取消，此前使用者社群對此提出了很多抱怨。
• 如果缺少縮圖容器的資源（即使有舊的縮圖標籤）後來在新構建的內建路線或會話中被選中，該資源通常將被分發為沒有影像的專案——如果沒有被 texture.txt 或 config.txt 縮圖容器正確引用，它們會被剝離出來[註釋 11]。
- 型別： URL 字串。
- 欄位定義：指向資源線上描述、資源說明（幫助）或 TrainzOnline wiki 上其他幫助頁面的連結，用於在嵌入式專用 N3V 瀏覽器中使用。該 URL 必須解析到 Trainz 線上安全區 中的網站。目前，嵌入式瀏覽器接受三個域名
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。
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 字串。
- 欄位定義： 一組用分號 (;) 分隔的自然語言關鍵詞。字串中不應該存在其他字元（包括空格或不相關的標點符號）。這些關鍵詞構成了資產關鍵詞搜尋的基礎。資產的 使用者名稱 不需要在 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 容器
- 型別： ASCII 字串陣列容器。
- 欄位定義： 一組用分號 (;) 分隔的自定義類別識別符號。每個 自定義類別識別符號 應該是一個簡短的（例如，3-6 個字元）字母數字標記。字串中不應該存在其他字元（包括空格）。
- 這些自定義類別用於使指令碼能夠快速定位特定類別的資產。強烈建議謹慎引入新的自定義類別識別符號。
- custom-category-list 標記值總共不能超過 64 個字元。除非存在僅能透過自定義類別列表方法實現的現有特定指令碼要求，否則此標記應保留為空白。
- 最小版本： V3.5 及更高版本
- 型別： Member-of-groups 容器 配對的 佔位符引數 和 資產組 KUID 列表。
- 欄位定義： 一組 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 上的大多數資產都是像這樣以及其他維基媒體維基專案一樣，對被稱為 知識共享署名-相同方式共享 (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 標籤”（或今天的“username 標籤”）的非英語語言翻譯的 ISO 兩字母后綴；與 description-XX 類似，“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 標籤 取代
- 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 國家程式碼的“string-array” 在 category-region 標籤中取代。
- 用 string-array 型別 category-region 替換，在兩個字元的國家程式碼之間沒有空格和分號，這些程式碼在引用的標籤部分中列舉；這些程式碼以兩個大寫的字母的形式給出，包含 列舉 程式碼，然後是程式碼之間的“;” 分隔符，但最後一個分隔符除外，該分隔符位於末尾引號之前。
- 字串陣列中的任何 空格 都會導致讀取錯誤和故障訊息，包括結尾引號之前的空格。
- region — TBS V1.3–v2.8 中的有效部分，作為內建過濾器和地圖資產自定義本地化識別符號 (kuid)；現在唯一的合法標籤用途是在 地圖資產 (佈局) 中。
- 作為以前的過濾器修飾符，該標籤在歷史上幾乎所有資產中都有發現，但它在滾動庫存、場景、樣條線資產、軌道型別（包括隧道和橋樑）以及具有某種程度本地化的路邊資產中尤其普遍。
- 地圖資產仍然保留了關鍵字 Region，該關鍵字在 Map 配置中定義，具有相反的用途——成為 區域型別 kuid 引用。因此，Region 在 Maps 中是必需的，並且自 TS2012 以來，與標籤型別一樣，它在大量曾經作為 TRS 系列版本 Surveyor 工具的“分組資料” “快速過濾器” 的資產中是非法的。
- 任何將 region 標籤對映到文字字串的操作在 TRS2009 之後都已過時，因為在程式設計師的心目中，他們用 選擇列表 替換了 Surveyor 工具中“型別和區域” 字串值的粗略過濾組選擇器。這兩個標籤都有一些優點和缺點，並且這兩個標籤都追溯到 Trainz 0.9 Beta 版本。
shadows 標籤
[edit | edit source]
thumbnail 標籤
[edit | edit source]thumbnail 標籤是 縮圖容器 的早期單檢視實現（在上面也有簡要說明）。Trainz 的早期預 N3V 程式設計師版本將找到一個 .jpg 檔案，最好大小為 240x180 畫素，位於主資產根資料夾或 asset-name_art 或 asset-name_body 資料夾中，並使用它在 CMP 和 DLS 中顯示資產（如果上傳）。該標籤在 TRS2006 期間被棄用，因為縮圖容器是在 v2.0（TRS2004-SP0）中引入的。在較舊的已修復資產中，如果 TBV 保持在 v2.4 以下，那麼縮圖通常仍然可以在較新的 CM 中工作，前提是它位於 _art 子資料夾中，並且資產名稱與使用者名稱匹配。
type 標籤
[edit | edit source]- type — V1.3–v2.8 — 以前的過濾器修飾符，在歷史上幾乎所有資產中都有發現，但它在滾動庫存、場景、樣條線、軌道型別（包括隧道和橋樑）以及路邊資產中尤其普遍。
- type 標籤與“region 標籤” 一樣，在 Trainz 0.9—TC3 版本中作為“Surveyor 中的組過濾器” 使用，與 region 相結合，提供更小的資產選擇（工具組）。自 TS2009 以來，這些本地可點選的過濾器被刪除，取而代之的是一個新的、更繁瑣的過濾器。這些使工具選擇變得快捷簡單，而不是在工具選項卡之間切換時變得緩慢和暫停——如今的預 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，大多數內容建立者正確地使用 Kuid2 形式的 kuid 來取代較舊的版本。相比之下，N3V 在新發布的“升級”內建資產中過度使用了 obsolete-table，這會導致很多混亂，並且無法獲得預期看到的內容。（例如，許多漂亮的 '翻轉樹' 在 TS10 和 TS12 中被 Speedtrees 取代，這影響了許多路線，其中建立者並不想要也不需要 Speedtrees。在跨安裝過程中，這也導致依賴項丟失，直到找到包含 obsolete-table 的資產。
• 此外，Assets.tdx 資料庫索引中僅支援每個 kuid 的一個 obsolete 條目，用 Kuid2 版本來廢棄 kuid 會導致問題（即，您會看到哪個？）
• obsolete-table 的一個極佳用途是使用特定部件（尤其是轉向架）來升級一系列資產。新增混合的 kuid 以用較新的好的轉向架替換它們，可以顯著提高路線或會話的外觀，只需一次編輯即可（前提是轉向架（例如）相容且尺寸合適！）。 - ↑ 最近將過時資產匯入 TANE 的經驗表明，有五個以上的備用 kuid 廢棄了那個可憐的 翻轉樹資產。由於 Speedtrees 的引入導致的混亂，以及 TANE 在積極尋求最合適的更新資產方面的改進，現在 ContentManager 程序中允許存在多個不同 kuid 的資產，這些資產廢棄了相同的 kuid。作為一個良好的做法，只有在絕對必要時才使用 obsolete-table... 例如，用您要上傳到 DLS 或在網站上自行釋出的依賴資產中，用較新的資產替換不需要的付費資產。
- ↑ 關於 category 時代的標籤範圍：安全起見，已知有效。其他“未來十年”值應在依賴於此類值之前進行測試。
- ↑ 許多容器在列表中使用虛擬/佔位符名稱。這些可以是描述性詞語，只要它們不包含空格字元。在短語構造的名稱中使用下劃線或句點可以保留可讀性，並顯著提高畫質晰度。例如，一輛貨運車廂可能運載 45 種合法產品型別。這些將在依賴項容器中列出。使用 Coal、granite、crushed_limestone 等使得表更容易維護和更改。Jes 說，作為一名程式設計師，自 '76 年以來就是如此。
- ↑ 在第二個縮圖容器示例中，還有一個 512x512 大小的影像，即 extra。DLS 將使用哪個影像未知。還可以包含更大的影像尺寸，並且透過電子郵件聊天，T:ANE 可能支援一個較大的影像尺寸，這將在預覽操作或 DLS 列表中找到用處。N3V Games 通常不釋出此類資訊。
- ↑ 早期 Trainz 1.x 的做法是使用關鍵字/標籤 "thumb"，並在引號中引用路徑規範，指向執行時選單的 240x180 縮圖影像。藝術資料夾包含一個 512x512 的 tga 檔案，具有 Alpha 遮罩（通常為 bmp 檔案，但格式正確的 tga 檔案可以用作自 Alpha 遮罩），以及 64x128 的選單圖示影像及其控制紋理檔案 texture.txt。
- ↑ 在 2014 年至 2015 年冬季與前版本經理 James Moody 進行的私人電子郵件對話中，關於此主題的重點是 DLS 上傳稽核軟體很可能已被修改，以強制執行適當的縮圖容器。
- ↑ 關於 category-era-nn 與 category-era 標籤值的說明： TRS 可以接受兩種形式的 category-era 資料；但 TS2009-SP0 及更高版本從以前合法的關鍵字-值對建立了錯誤，並試圖強迫內容建立者更改程式設計師故意破壞的所有資產。 後來 DLS 上傳軟體強制執行了轉換，但這要好得多，因為第一個操作會讓很多人為修復浪費許多時間，而這些修復是不必要的，應該在稽核舊的 trainz-build 資產時，在軟體預過濾階段自動實施。 這些操作實際上保證了舊資產下載會存在錯誤。 這是 N3V 程式設計師所做的最愚蠢、最傲慢的事情之一，而 Auran 更經驗豐富的軟體人員絕不會如此輕率地對待社群的時間成本。
參考資料
[edit | edit source]- 本頁面的主要內容取自 N3V TrainzOnline Wiki 的 KIND_TrainzBaseSpec。 昨日 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 程式碼 標準的更新資訊，這些標準會隨著軟體功能的新增而有所變化。 |