Trainz/refs/TrainzBaseSpec
(重定向自 Trainz/TBS)
KIND TrainzBaseSpec 為所有 Trainz 資產型別在所有 config.txt ini 檔案 中提供基本定義。TBS 提供了一些“標準標籤”，這些標籤對於所有 Trainz 資產是通用的（或者至少，可以在法律上為所有 Trainz 資產定義）[1]。
- 其中一些是強制性的，因為它們決定了資產的進一步處理以及對 config.txt 檔案和其資料夾中資產資料的解釋。
- 然而大多數是可選的，並且在大多數子資產中可以省略使用該標籤的定義行。
- 沒有，對於由事實上的父容器（所有 Trainz 數字模型所需的 config.txt 檔案）定義的所有內容都是有效且大部分都是必要的。KIND TrainzBaseSpec (TBS) 是一個根類，其他 Trainz 資產類是從它派生的。
- 據說它們是派生的，因為它們繼承了引數中定義的處理屬性（指令）和值，其中最重要的是 kind 標籤的值。該列舉詞決定了資產的特定種類宣告和要求，這些宣告和要求會新增到該資產配置檔案中 TBS 的定義中。其他重要的 TBS 定義的資料具有明顯的意義和效用，例如資產的名稱、Kuid 識別符號和版本、Trainz 構建值（TBV）以及其他具有廣泛可變定義需求、適用性和範圍的資料，例如string-table、obsolete-table、kuid-table和縮圖，這些資料都是臨時的。即使是資產名稱和描述的字串值在實踐中通常都是完全不必要的，並且可以完全省略。
- 當宣告一種型別時，該型別成為父類，需要並規定必須在類中滿足的必要資料對，除了 TBS 中列出的資料之外。
- 某些引數可能在一個資產型別的案例中保持未定義，尤其是針對較舊的 Trainz 構建標籤值的常見做法，以及針對這些值，內容管理器或內容建立者 Plus（CCP）實用程式將分配一個預設值，但在處理它時會列出警告訊息。TrainzOnline 維基、此處或較舊的TC3 時代內容建立者指南（CCG）中提到的許多標籤都會提到一個預設值。
- 從 TRS2006 和 Trainz Classics（TC1&2）開始，每個版本的內容管理器模組都會施加越來越多的預先承諾錯誤測試[注 1]，並且每個版本都變得越來越堅定地警告這樣的標籤在期望這種標籤 - 資料對時沒有被定義。
在 TANE 之後版本中，許多這些“昨天預設”的定義行今天會更頻繁地生成錯誤，要求在過去載入時預設值的情況下明確定義值[注 2]。與過去時代相比，這是一種更可取的煩惱，在過去時代，錯誤的資產定義有時會導致臭名昭著的“藍色畫面宕機”，或者更常見的是，將執行時軟體崩潰回桌面，導致編輯丟失，並可能需要重建資料庫。
所有 Trainz 定義的資料（內容）都具有三個必需的元素：一個config.txt 檔案 用於組織資料，一個表示kuid 的身份（僅僅使用者名稱是沒用的，但是合法資產可以在沒有名稱的情況下建立！），最後一個是合法定義的型別標籤。型別負責，是管絃樂隊的指揮、排長或 CEO 發號施令——為處理之後的所有事物設定要求。簡而言之，型別的值——一個小型精選的、嚴格定義的成員專屬組——告訴 Trainz 軟體在我們的虛擬世界中要渲染和顯示什麼，以及如何（或在哪裡）找到將該配置檔案中資產的這些部分連結在一起所需的的其他部分。
以下所有子類都被認為是其“父類”資料的TrainzBaseSpec[注 3]。下面列出的少數型別，那些帶下劃線的型別，是先於Trainz 資料模型在TS2009（即從 2008 年後期開始）釋出時發生的更改的遺留型別，此後 N3V 程式設計師僅對這些型別進行了逐步（增量）更改。
目前可以在 N3V Trainz 維基的內容建立者指南部分中找到基於這些遺留型別修復資產的詳細資訊，此處為 TrainzOnline 網站，其中有啟發性的遺留型別的示例。強烈建議Trainz 下載站的使用者或任何想要建立內容的使用者閱讀 CCG。瞭解舊內容定義方式的背景歷史可以讓我們對同類型資料的當前 TrainzOnline 覆蓋範圍進行對比和比較，因為這種過去與現在的對比通常會提供寶貴的見解，幫助修復、更改和定製資產。更重要的是，CCG 中的寫作是由專業人員製作的，並且更加語義化——它通常會讓你瞭解如果改變了某項內容，會帶來哪些擴充套件的影響，而 Trainz 維基就沒有提供這些內容。TrainzOnline 上釋出的 CCG 是TC1&2/TC3 版本——這是自 1999 年Trainz問世以來，幾個印刷小冊子（追溯到 Trainz）的最後一個已釋出版本；TC3 CCG 包含 TRS2004/TRS2006 和UTC 資料模型中更改的 Enginespecs 機車資產，需要進行適當的更新。
TBS 標準定義
[編輯原始碼]這些標籤和容器是標準定義，幾乎可以在所有資源中找到。一些標籤是可選的，內容建立者可以根據自己的選擇來定義。標籤是關鍵字，具有單個分配的 *鍵-值* 或容器，例如 *字串陣列* 或 '{' ... '}' 繫結封閉的標籤-值對或子容器。（在 Trainz 配置檔案中宣告的所有內容都是成對的，即使 '{' ... '}' 也被視為 *一個 鍵-值*。）
- 容器是 *'鍵' 和 '鍵-值' 對的集合*，以及 *TBS 中的 '上層容器'（與縮圖容器中的子容器相反）通常以 '-table' 為字尾*。
| 型別 | "'字串值'" |
| trainz-build | '浮點數', 1 位小數 |
| kuid | <Kuid 編碼值> |
| 使用者名稱 | 使用者名稱 "'字串值'" |
| 使用者名稱-XX | 使用者名稱-XX "'字串值'" |
| 描述 | 描述 "'字串值'" |
| 描述-XX | 描述-XX "'字串值'" |
| kuid-table (容器) { 依賴項列表 |
一個鍵-值表，列出了此資源依賴的所有資源。 |
| obsolete-table (容器) { } |
kuid 列表，此資源替換了這些資源（使其過時） 通常為空（空）[註釋 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 格式的更新和更新跟蹤修改版本，它允許指定版本號。
<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 版本號完全匹配，以下情況除外
- 分配給 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 無 Service Pack）到當前版本（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 版本號。相反，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 多行字串，提供資產的清晰語言描述。
- 欄位定義： 此資產的英文人類可見描述性摘要。
描述在 Content Manager 的“資產詳細資訊”窗格中可見，用於闡明資產名稱，提供規格，以及通常的一些歷史資訊。
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 字串列表容器，字串表容器(s)。
- 欄位定義： 一個鍵值對的英文字串列表。每個鍵是一個有意義的指令碼識別符號，對映到二進位制資料並被其引用。每個值都是一個英文字串。英文字串可能包含或引用非英語專有名詞作為識別符號。非英語母語作者製作的資源，如果需要，仍然必須建立一個沒有後綴的字串表容器。軟體只連結並引用字串表容器中沒有後綴的名稱和值，這將讓西班牙語、法語、德語、捷克語、荷蘭語…日語作者感到很不舒服。換句話說，帶字尾的字串表僅僅是為了翻譯目的，當地圖用非英語編寫時，就會出現問題——沒有 string-table-en 來提供反向翻譯的表格。同樣，username-en 和 description-en 也是如此。這三者的缺失都體現了一種過時且傲慢的無視世界動態的態度。
其他語言由類似的字串表（例如 string-table-XX）支援，其本地化程式碼字尾 (XX) 與 description 和 username 關鍵字/標籤的國際化字尾相匹配，但這些語言鍵控的字串表容器始終在左側條目中具有相同的鍵值。
- 這些左側的鍵或標籤既充當"本地索引關鍵字"，也充當"語言之間的等價表"。
- 左側列始終包含內容建立者賦予“特殊”名稱的物件，例如訊號、軌道標記和行業、連線點等的名稱，這些名稱可能會被引用，並且會出現在 Driver 和 Surveyor 模組的“查詢工具”(CTRL+F ) 函式小程式中。
- 另一方面，索引側也不會列出預設的場所名稱，例如在構建路線圖時，由隨機數自動索引的無數連線點（即毫無意義的雜亂資訊。如果重要，路線構建 CC 會命名它！），但會自動包含可能臨時的資源，例如火車車的預設名稱。如果重新命名，這些名稱將取代其對應的預設名稱。
- 它的主要用途是那些旨在與指令碼引用互動並獲取可變屬性的物件，例如火車站、行業所需的或準備裝運的產品數量，或者由互動式火車車（滾動行業到指令碼）和其他可配置資源（像一個通用的廣告牌式標誌，透過一點高度調整和角度扭矩，可以放置在庫存建築或行業的正面，以在建築上放置不同的商業名稱）運送的貨物，換句話說，是有點可配置的場景。
- 總的來說，在路線圖或佈局中，這些左側名稱對應於地圖資源上的命名物件，這也是大多數字符串表出現的地方（從字面上看，在一個大型路線kind map中，有成千上萬的條目）。
- 在某些資源中，預設名稱連線到軟體指令碼中，因此字串表變得特別重要，而不是平淡無奇。（見下文）
- 在每種型別的資源中，使用字串表型別都是合法的，就像 description 標籤、trainz-build 和 kind 標籤一樣。與這些不同的是，它不需要存在或定義，並且絕不是強制性的。除非程式碼期望它們的結合，否則封裝在字串表容器中的值沒有任何功能或效果。
- 在其他資源中，再次以假設的可程式設計商業標誌為例，如果要與軟體互動，字串表必須有一個預設名稱。所有地圖可放置資源都可以命名或重新命名，但“特殊名稱”必須與指令碼和字串表索引值匹配。大多數可配置資源定義了一個介面變數，用於替換預設名稱作為指令碼和資源二進位制資料引用的索引或查詢表。其他變數也可能在可程式設計資源中定義。這些都可能被指令碼引用，但正是索引值使其進入了地圖或會話字串表，從而使一切在需要 Driver 或會話建立者可變性時協同工作。
- 相反，如果沒有系統軟體知道索引中命名專案的的位置，物件的指令碼可能不會觸發，不會進行條件檢查，也沒有被更新的能力。這是 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 中只有一個替換 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。
- 用途：CM 和 Surveyor 中的過濾器（搜尋條件）
- 型別：列舉字串或字串陣列。
- 欄位定義：一個由分號 (';') 分隔的雙字元category-region 標籤 程式碼列表。字串中不應包含其他字元（包括空格等）。此資產被認為與每個指定的區域相關—這與kind 貨車 和kind 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 字元category-class 程式碼，用於描述此內容項。category-class 標籤用於提供超出資產型別隱含內容的人工細分。每個 Trainz 資產的 category-class 標籤有助於描述資產在遊戲中的 '意圖'，而不是資產的內部結構。
|
|
請注意，許多 category-class 程式碼只與特定的資產型別相關—category-class 程式碼不應應用於不合適的資產型別。
- 示例
| category-class "XBG" | 箱車—來自 PRR 60' | |
| category-class "BR" | 鐵路（非功能性風景）—可能是一棟建築 | |
| category-class "BIN" | 具有產品處理功能的工業資產 |
- 每個時代程式碼代表一個十年，由一個四位數的整陣列成，然後必須是 's' 結尾
(例如 "1990s;2000s;2010s"),從而建立一個列舉軟體標記（值），它必須與指定的合法時代程式碼 之一完全匹配。 - 字串中不應包含其他字元（包括空格等），包括（尤其是在字串末尾）在終止雙引號字元之前。
- 允許的年份範圍是 1800-2010s[註釋 7]
- 此資產的唯一意義是對於其他人來說，即此資產被認為是在指定的時代範圍內有效且適當的相關，並且Content Manager 將接受指定適用年份的搜尋過濾器。
- 示例
category-era "1920s;1930s;1940s;1950s"
- 用途：CM 和 Surveyor 中的過濾器（搜尋條件）
- 型別：縮圖容器。
- 欄位定義：在整個遊戲環境（包括遊戲中、在Content Manager 中以及在Download Station 上）中用於在 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 '圖示'，它用於Railyard 和測繪師資產選擇 API 中，應該有一個Alphamask 或一個非常淺的背景。許多舊的沒有使用 jpg 檔案，而是列出了 .tga 檔案（Targa True Color）在一個 '_art' 子資料夾中（Trainz 1.0—TC3 約定：_art、_body 和 _shadow 是三個由早期 Trainz 資料模型要求命名的子資料夾，名為 'asset-filename_suffix'（過時的標籤—<值> 對），如下所示[註釋 9]
thumbnails
{
Icons
{
width 128
height 64
image "40ft_boxcar_art\40ft_boxcar_art_icon.texture"
}
CM
{
width 240
height 180
image "$screenshot PRR 40ft_boxcar (240).jpg"
}
DLS1
{
width 512
height 512
image "40ft_boxcar_art\40ft_boxcar_art_512.texture"
}
DLS2
{
width 512
height 512
image "$screenshot PRR 40ft_boxcar (512).jpg"
}
}
在 TS2009 和 TS2010 的早期版本中，沒有適當的縮圖容器的資產被標記為有缺陷。補丁後來將這些標記為警告。[註釋 10] 這種做法在 TS12 修補程式中被放棄，此前使用者社群對此提出了許多抱怨。
• 如果缺少縮圖容器的資產（即使有舊的縮圖標籤）後來在新的內建路線或會話中被選擇，該資產通常將作為沒有影像的專案進行分發——如果紋理 .txt 或 config.txt 縮圖容器未正確引用，它們將被剝離[注 11]。
- 型別： URL 字串。
- 欄位定義：指向資產線上描述、資產說明（幫助）或 TrainzOnline Wiki 上其他幫助頁面的連結，旨在從嵌入式專用 N3V 瀏覽器中使用。該 URL 必須解析到 Trainz Online 安全區域 內的站點。目前，嵌入式瀏覽器接受三個域
auran.com
ts2009.com
ts2010.com
此外，不直接連結到這些域，而是使用自定義的 Trainz 短 URL 格式，以防範將來可能發生的站點佈局更改。'短 URL' 是 Trainz 特定的 URL，有助於將來保護內容，允許內容建立者引用 N3V 網站上的某些頁面，而無需依賴於特定的 Web 佈局。短 URL 旨在用於遊戲內使用，例如 info-url 連結，並且僅在嵌入式 Web 瀏覽器中有效，在任何外部 Web 瀏覽器中均無效。在存在此標籤的情況下，遊戲內按鈕允許使用者檢視資產描述或幫助，而無需離開遊戲環境。
這在 Driver 中對於訪問路線圖、指南或會話說明或澄清可能非常有價值。
建議在任何情況下，對於提供類似功能但外觀略有不同的資產類別，都使用通用組頁面。這減少了建立、維護和本地化此類文件的時間成本。
- 型別： 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 的 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 個字元。除非存在只能透過 custom-category-list 方法實現的現有特定指令碼要求，否則應保留此標籤為空。
- 最小版本：V3.5 及更高版本
- 型別：Member-of-groups 容器，配對 佔位符引數 和 asset-group kuids 列表。
- 欄位定義：此資產所屬的KIND_Asset-group 資產列表。有關如何以及何時使用此功能的詳細資訊，請參閱kind KIND Asset-group 文件。
該容器包含 KIND Asset-group KUID 的常規列表。此包含是一個宣告，宣告此後，特別是在搜尋操作中（包括指令碼介面和 TrainzUtil），此資產將被視為每個列出的資產組的成員。
如果給定“member-of-groups”容器未指定任何條目，或者資產省略了“member-of-groups”容器，那麼模擬器軟體可能會根據資產的 Config.txt 檔案指定一些預設資產組。確切的行為可能會在模擬器軟體的不同版本之間發生變化，但是當前邏輯在此處進行了描述here。
- 以下標籤對於任何資產來說從來都不是強制性的，而且很多資產會將其保留為空。
- 從歷史角度來看，識別和許可標籤從 Trainz 0.9（測試版）開始。
- 型別：UTF-8 多行字串。（被程式設計師法令棄用。）
- 欄位定義：許可證，描述了資產建立者希望如何使用此資產。最常見的是許可證宣告，禁止在任何付費路線、依賴資產（例如轉向架、耦合器等火車部件）或重製皮膚中使用版權資產，包括在任何付費運營的網站上分發該資產。（理論上，即使對於 DLS 也是如此。FCT 費用是為了更快地訪問和無限下載，而不是為了訪問資產。）
- DLS 上的大多數資產都是對 Creative Commons Share Alike with Attribution (CC-BY-SA) 的措辭不當的版本，例如本維基和其他的 Wikimedia 維基專案。
- license 標籤的含義含糊不清，N3V 不建議使用它，但它的存在早於 N3V 的管理 6-7 年。
- 上傳到下載站 或用於包含到遊戲中的內容可能受到特定再發行合同或許可協議的約束，這些協議優先於此欄位中的任何文字。license 欄位不提供本地化支援。license 欄位的文字不會被 Auran 或 N3V 驗證或執行，並且可能對終端使用者具有法律約束力，也可能沒有。
- 另一方面，Planet Auran 的歷史表明，有人透過將他人內容用作自己的內容來侵犯版權，可能會導致其從 Auran 網站迅速被禁止，並失去下載站許可權等，從而永久封禁。此外，社群將對違反他人版權的其他使用者採取強硬措施，並回避違反者，並忽略任何允許保留在 DLS 上的資產。
- 總之，嘗試和更改資產是Trainzer 嘗試攀登陡峭的內容建立學習曲線的一種公認甚至被允許的生活方式（每個人都希望有更多內容建立者！），但如果資產有依賴部件，尤其是網格、指令碼、紋理，這些是智慧財產權——在你上傳作品之前，請獲得使用這些屬於其他人的部件的許可。
|
|
- 型別：UTF-8 字串。（已棄用，取而代之的是可更新的Planet Auran 資料庫。）
- 欄位定義：作者的姓名或標誌。不建議使用此欄位，因為歸屬可以透過程式設計方式確定。
- 注意英國拼寫，“organization” 的北美拼寫也適用！
- 型別： UTF-8 字串。（已過時，建議使用可更新的 Planet Auran 資料庫。）
- 欄位定義： 負責建立此資產的組織的名稱或標識。不建議使用此欄位，因為歸屬可以透過程式確定。
- 型別： 字串，電子郵件地址。（已過時，建議使用可更新的 Planet Auran 資料庫。）
- 欄位定義： 此資產建立者的聯絡電子郵件地址。不建議使用此欄位，因為歸屬可以透過程式確定，並且聯絡資訊可以註冊到建立者的 Auran 賬戶 Planet Auran 賬戶，在那裡可以對其進行限制或更新。
- 型別： URL 字串。（已過時，建議使用可更新的 Planet Auran 資料庫。）
- 欄位定義： 此資產建立者的聯絡網站。不建議使用此欄位，因為歸屬可以透過程式確定，並且 [聯絡資訊] 可以註冊到建立者的 Auran 賬戶 Planet Auran 賬戶，在那裡可以對其進行限制或更新。
|
|
- 在最初的編譯之後，在舊版本的資料模型中發現的一些常見但現在已過時的標籤已新增在下面，例如在許多橋樑資產中發現的 bendy 及其朋友。
|
|
- asset-name、name 和 name-XX - V1.3–v2.8 - 在幾乎所有 v1.3-v2.0 資產中都有歷史記錄。雖然“asset-name”一直保留著，沒有引起任何抱怨，直到 v2.8，但在 v2.5 之後不鼓勵使用；因此，在 v1.5 之後，資產的 config.txt 檔案中唯一需要的、想要的或被認可的名稱是 username-XX 變體。
Asset-name 是 Trainz 1.x--TRS2004 Trainz 時代資產的主要資料夾名稱，並且通常是 CM 開啟檔案以供編輯時開啟的資料夾的名稱；在當今這樣的早期資料模型資產中，通常會發現 asset-name 也用於早期 Trainz 時代的 data 子資料夾系統，在火車車廂資產中，其子資料夾名稱為“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 雙字母后綴；“XX”形式與 description-XX 一樣，是“本地化”對其他語言的使用者友好值的支援部分。
- 在最古老的 Trainz 時代 (v1.0-v2.4) 資產中，將 name 和 name-XX 替換為 username 和 username-XX，或者如果存在 username，則直接刪除。
- 如果資產的 trainz-build 版本為 v2.7 或更高，則 name-XX 會導致錯誤。有趣的是，即使在 TS12 這樣晚的版本中，name-XX 標籤仍然顯示在 Surveyor 工具的搜尋列表中，如果不存在，則會出現 TrainzBaseSpec。
|
|
- 已被 category-era 標籤 取代
- 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 字串陣列是在 TBV 2.0 引入的，將這些日期合併到一個 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)；現在唯一合法的標籤使用是在 地圖型別 (佈局) 資產中。
- 作為以前的篩選器修飾符，該標籤在歷史上幾乎所有資產中都有出現，但在滾動庫存、場景、樣條線資產、軌道型別 (包括隧道和橋樑) 和具有某種程度的本地化的軌道旁資產中尤為普遍。
- 地圖資產仍然保留著關鍵字 Region，該關鍵字在 Map 配置中定義，但使用方式相反，即作為 區域型別 kuid 引用。因此，Region 在地圖中是必需的，而且自從 TS2012 以來，與標籤型別一樣，它在大量的資產中是非法的，而這些資產曾經將它作為 TRS 系列版本 Surveyor 工具視窗中的 '分組資料' '快速篩選器'。
- 在 TRS2009 之後，任何將 region 標籤設定為文字字串的操作都已過時，因為在程式設計師看來，他們用 選擇列表 替換了 Surveyor 工具中 '型別和區域' 字串值的 粗略篩選 組選擇器。這兩個標籤都有一些優點和缺點，並且都可以追溯到 Trainz 0.9 Beta 版本。
thumbnail 標籤是 縮圖容器 的早期單檢視實現 (如上所述，也有簡要說明)。Trainz 的早期 N3V 之前的程式設計師版本會找到一個 .jpg 檔案，最好大小為 240x180 畫素，該檔案位於主資產根資料夾或 asset-name_art 或 asset-name_body 資料夾中，並使用它在 CMP 和 DLS 中顯示該資產 (如果上傳的話)。該標籤在 TRS2006 期間被棄用，因為縮圖容器在 v2.0 (TRS2004-SP0) 中引入。在較舊的已修復的資產中，如果 TBV 保持在 v2.4 以下，縮圖通常仍然可以在較新的 CM 中工作，前提是它位於 _art 子資料夾中，並且資產名稱與使用者名稱匹配。
- type — V1.3–v2.8 — 一個以前的篩選器修飾符，在歷史上幾乎所有資產中都有出現，但在滾動庫存、場景、樣條線、軌道型別 (包括隧道和橋樑) 和軌道旁資產中尤為普遍。
- 與 'region 標籤' 一樣，type 標籤在 Trainz 0.9—TC3 版本中 用作 'Surveyor 中的組篩選器'，它與 region 相結合，可以提供更小的資產選擇 (工具組)。自從 TS2009 移除這些本地可點選篩選器，取而代之的是一個新的、更繁瑣的篩選器。這使得工具選擇變得快捷和簡單，而不是在工具選項卡之間切換時變得緩慢和暫停 — 如今的 TANE 之前的版本在工具選項卡之間來回切換時，往往會被重新載入整個選擇列表所淹沒。
- type 和 region 都預設為 'All'，與 TS09 及其以後版本中的工具提供相同的超長列表。
- ↑ 資產 提交 (TANE 中的提交) 是將內容整合到資料庫中並將其在 DB 索引中交叉引用的過程和程式，以便在執行時模組中訪問它。
- ↑ 驗證資產的一種方法是，除了這些值之外，將 TBV 降低到 2.5-3.7 範圍，看看這些訊息是否消失。您可能需要多次降低 TBV 直到足夠低，反之亦然，在較舊的 TBV 中無法識別的較新關鍵字可能會給出不同的錯誤訊息。不要害怕嘗試，即使失敗，也會產生知識和經驗，而且您不會破壞任何東西！如果這樣，您可以確信，僅僅提供一個值就是解決問題的方案。通常，一些現代需求只需要關鍵字對，因此在標籤後面新增一個空行，或者在標籤後面新增一個空的括號集 (表示容器) 就可以滿足需求，而錯誤測試則過於嚴格。
- ↑ 注意: 此列表在 N3V TrainzOnline Wiki 上被 '維基化'，這意味著在 'KIND' 這個詞後面第一個字母被大寫，而 config.txt 檔案中的實際資料標籤名稱是 全部小寫 文字。該維基還使用雙引號來表示相當多的術語，我們將在本文中避免使用這種做法。
- ↑ 'kind consist' 並不經常直接出現，它只存在於選單和內容管理器列表中。
- ↑ Obsolete-table 必須謹慎使用，最常出現在 Auran 製作的資產中。該表格將舊的 kuid 替換為新的 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 或在網站上自行釋出的依賴資產中替換一個不需要的付費資產。
- ↑ 關於類別時代標籤範圍：已知有效的安全做法。其他“未來十年”值應在依賴之前進行測試。
- ↑ 許多容器在列表中使用虛擬/佔位符名稱。這些可以是描述性詞語，只要它們不包含空格。在短語構建的名稱中使用下劃線或句點可以保持可讀性並顯著提高畫質晰度。例如，一輛貨運車廂可以承載 45 種合法產品型別。這些將在依賴項容器中列出。使用 Coal、granite、crushed_limestone 等可以更輕鬆地維護和更改表格。Jes Sayin'，自 1976 年起擔任程式設計師
- ↑ 在第二個縮圖容器示例中，有一個第二個 512x512 大小的影像，即額外的影像。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 上傳驗證軟體可能已被更改，以強制執行適當的縮圖容器。
- ↑ 關於類別時代-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 程式碼 標準的更新資訊，這些標準隨著軟體功能的新增而不斷變化。 |