Trainz/refs/TrainzBaseSpec
KIND 層級結構簡介
[edit | edit source]KIND TrainzBaseSpec 為所有 Trainz 資源型別在所有 config.txt ini 檔案 中提供基礎定義。TBS 提供了一系列“標準標籤”，這些標籤對所有 Trainz 資源都適用（或至少可以在合法定義）。[1].
- 其中一些是強制性的，因為它們決定了資源的進一步處理以及對 config.txt 檔案及其資料夾中資源資料的解釋。
- 然而，大多數是可選的，並且在大多數子資源中可以省略使用該標籤的定義行。
父類
[edit | edit source]- 無，所有 Trainz 數字模型都需要的有效且大部分必要的 defacto 父容器定義的內容，即 config.txt 檔案。KIND TrainzBaseSpec (TBS) 是一個根類，其他 Trainz 資源類由此派生。
- 之所以說它們是派生，是因為它們繼承了處理屬性（指令）和其中列出的引數定義的值，其中最關鍵的是 kind 標籤的值。該列舉詞決定了資源的特定型別宣告和要求，這些要求被新增到該資源的配置檔案中的 TBS 定義中。其他重要的 TBS 定義資料具有明顯的意義和實用性，例如資源的名稱、Kuid 識別符號和版本、Trainz 構建值 (TBV) 以及其他具有廣泛可變定義需求、適用性和範圍的資料，例如string-table、obsolete-table、kuid-table 和縮圖，它們都是特定情況下的。即使是資源名稱和描述這樣的字串值，在實踐中大多數情況下都是完全沒有必要且完全可以省略的。
- 當聲明瞭一種型別時，該型別將成為父類，要求並規定必須在該類中滿足的必要資料對，除了 TBS 中列出的那些資料之外。
- 在某些情況下，對於該資源的型別，某些引數可能未定義，尤其是在較舊的 Trainz 構建標籤值的常見做法中，以及在 Content Manager 或Content Creator Plus (CCP) 實用程式將分配一個預設值，但在處理它時會列出一條警告訊息。TrainzOnline 維基、此處或較舊的 TC3 時代 內容建立者指南 (CCG) 中的許多標籤會提到一個預設值。
- 從 TRS2006 和 Trainz Classics (TC1&2) 開始的每個版本中的 Content Manager 模組都強制執行越來越多的預提交錯誤測試[note 1]，並且每個模組都越來越堅定地警告這樣一個標籤在預期該標籤時沒有被定義 - 資料對。
在 TANE 之後的版本中，許多相同的“昨天預設”定義行今天將更常生成錯誤，要求明確定義值，而這些值在過去的載入中是預設的。[note 2] 這種令人討厭的事情比過去的日子要好得多，在過去的日子裡，錯誤的資源定義有時會導致臭名昭著的“藍色畫面宕機”，或者更常會導致執行時軟體崩潰回桌面，從而導致編輯丟失，並可能需要重建資料庫。
子類
[edit | edit source]
所有 Trainz 定義的資料（內容）都有三個必需的元素：一個config.txt 檔案 來組織資料，一個身份，即kuid（僅使用者名稱對你毫無用處，然而，一個合法的資源可以在沒有名稱的情況下建立！），最後，一個合法定義的型別標籤。型別負責，是管絃樂隊的指揮、排長或 CEO 指揮——為之後處理的每件事設定要求。簡而言之，型別的價值，一小部分嚴格定義的會員專屬組——告訴 Trainz 軟體在虛擬世界中渲染和顯示什麼，以及如何（或在哪裡）找到使該資源的這些部分在該 config.txt 檔案中連結在一起的其他部分。
下面的每個子類都被認為具有TrainzBaseSpec 作為其資料的“父類”。[note 3] 下面列出的一些型別，那些帶下劃線的型別，是早於 TS2009 釋出的 Trainz 資料模型更改（即自 2008 年末以來）的遺留型別，N3V 程式設計人員只對它們進行逐步（增量）更改。
目前可以在 N3V Trainz 維基 TrainzOnline 網站此處 的 內容建立者指南 部分找到基於這些遺留型別的修復資源的詳細資訊，並提供 遺留型別的示例此處。強烈建議 Trainz 下載站 的任何使用者或任何考慮建立內容的人仔細閱讀 CCG。從瞭解較舊內容定義方式的背景歷史中獲得的見解，可以與 TrainzOnline 對相同資料型別的當前報道進行對比和比較，因為這種過去與現在的對比通常會為修復、修改和自定義資源提供寶貴的見解。更重要的是，CCG 中的寫作是專業製作的，而且更具 tautological 性——它通常會讓你瞭解如果更改這一點或那一點的擴充套件效果，而 Trainz 維基則沒有提供這些資訊。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 | "'字串值'" |
| 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 tag 列舉 程式碼 | category-region "'字串陣列'" |
| category-class tag | category-class "'列舉 字串值'" |
| category-era tag | category-era "'受限字串陣列'" 年代 |
| category-keyword "'字串陣列'" 最大長度為 64 位元組 | category-keyword tag 自然語言搜尋關鍵字 (替換型別，區域) |
| custom-category-list "'字串陣列'" |
指令碼介面功能 |
| must-have-product-rights "'字串值'" |
DRM 字串陣列 |
| must-not-have-product-rights "'字串值'" |
DRM 字串陣列 |
| privileges (容器) { } |
更多 DRM |
| thumbnails (容器) { } |
縮圖容器 |
| script (檔名) | "'字串值'" |
| class (指令碼資產類) | "'字串值'", 必須與 script 規範類同步。 |
| script-include-table { } |
(列出庫指令碼的容器) |
| extensions (容器) { } |
資產也使用的正式指令碼擴充套件 |
| license "'字串值'" | 資產創作者的版權宣告 |
| author | "身份 '字串值'" |
| organisation | "第三方組身份 '字串值'" |
| contact-email | "電子郵件地址 '字串值'" |
| contact-website | "作者/組的網頁地址 '字串值'" |
| member-of-groups (容器) { } |
此資產所屬的 KIND Asset-group 資產列表。 |
支援的標籤
[edit | edit source]TrainzBaseSpec 在 config.txt 檔案 中支援以下標籤。 ∅:
kind 標籤
[edit | edit source]- 型別: 字串。
- 欄位定義: 此 config.txt 檔案 所代表的資產型別。請參閱索引 Kinds 和列表：這裡（上面）
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 標籤，縮寫：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 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 值。
- 型別： UTF-8 字串，資產的使用者名稱，強制性規範。
- 欄位定義： 此資產的英語人眼可見名稱。
在 TC1&2 (v2.7) 之後的 trainz-build 中，使用者名稱在編輯資產時也會變成作業系統資料夾名稱，而資產檔名會被忽略，而在 v2-6 配置檔案中，資產檔名優先。根據 N3V games 的 TBS 標準，此欄位決不應該包含非英語文字，除非資產名稱是專有名詞（例如地名），且沒有英語本地化變體。此值是每個人通常搜尋和記住的，因此建議保留一個清晰的名稱。
 |
|
- 型別： UTF-8 字串，使用者名稱標籤 的備用語言版本。
- 欄位定義： （其中XX 被替換為適當的 本地化程式碼，用於表示要使用的語言。）此資產的本地化人眼可見名稱。此欄位類似於使用者名稱欄位，只是表示非英語語言環境。資產中可能存在多個username-XX 標籤，每個受支援的語言環境一個。如果在給定的終端使用者系統上沒有合適的“username-XX”標籤來表示此資產，則使用英語使用者名稱標籤。
- 型別： UTF-8 多行字串，提供資產的清晰語言描述。
- 欄位定義： 此資產的英語人眼可見的描述性摘要。
描述在 Content Manager 的“資產詳細資訊”窗格中可見，用於闡明資產名稱、提供規格以及通常的簡要歷史資訊。
N3V 的 Chris Bergmann 已經宣告，此欄位應保留為簡短的（1-2 段）描述資產的簡短說明，而擴充套件的詳細資訊應透過info-url 頁面提供，但允許相當長的文字塊。有些人使用塊的底部作為版本更改記錄。
此欄位必須由英語描述性文字組成，儘管文字可以引用非英語專有名詞，如其他地方所述。其他語言翻譯或源文字應放置在眾多可能的替代語言本地化標籤之一中（請參閱 description-xx 標籤）。
- 型別： UTF-8 多行字串，描述標籤.
- 欄位定義： （其中XX 被替換為適當的 本地化程式碼，用於表示要使用的語言。）此資產的本地化人眼可見的描述性摘要。此欄位類似於描述欄位，只是表示非英語語言環境。資產中可能存在多個description-XX 標籤，每個受支援的語言環境一個。如果在給定的終端使用者系統上沒有合適的“description-XX”標籤來表示此資產，則使用英語描述標籤。
- 型別： UTF-8 字串列表容器，字串表容器.
- 欄位定義： 英語字串的鍵值對列表。每個鍵都是一個有意義的指令碼識別符號，對映到二進位制資料並由其引用。每個值都是一個英語字串。一個英語字串可以包含或引用一個非英語專有名詞作為識別符號。非英語母語的素材創作者仍然必須建立沒有後綴的字串表容器（如果需要）。軟體只連結並引用沒有後綴的字串表容器中的名稱和值，這無疑會讓西班牙語、法語、德語、捷克語、荷蘭語...日語的素材創作者感到沮喪。換句話說，帶有後綴的字串表只是為了翻譯目的，這在用非英語編寫地圖時會產生問題——沒有字串表-en 可以提供一個用於反向翻譯的表。同樣，username-en 和 description-en。所有三個缺失都表明了一種陳舊而輕率的傲慢和對世界動態的漠不關心。
其他語言由類似的字串表（例如 string-table-XX）支援，這些字串錶帶有與國際化字尾（XX）匹配的本地化程式碼字尾，這些字尾與描述和使用者名稱關鍵字/標籤的國際化字尾匹配，但這些語言鍵入的字串表容器始終在左側條目中具有相同的鍵值。
- 這些左側鍵或標籤既用作“本地索引關鍵字”，也用作“語言之間的等效表”。
- 左側欄始終包含內容建立者賦予“特殊”名稱的物件，例如訊號、軌跡標記和行業、連線點等的名稱，這些名稱可能會被引用，並且會出現在駕駛員和測量員模組的“查詢公用設施”(CTRL+F ) 功能小程式中。
- 相反，索引側也不會列出預設的場所名稱，例如在構建路線圖時由隨機數自動索引的無數連線點集合（即毫無意義的混亂。如果重要，路線構建 CC 會為其命名！），但會自動包含潛在的臨時資產，例如火車車的預設名稱。如果重新命名，這些名稱將取代其對應的預設名稱。
- 它的主要用途是針對那些旨在與指令碼引用互動並採用可變屬性的物件，例如火車站或行業需要的或準備在行業出貨的產品數量，或者由互動式火車車（滾動行業到指令碼）和其他可配置資產（簡單如通用廣告牌風格的標誌）攜帶，這些標誌經過高度調整和角度扭轉，可以放置在庫存建築物或行業的立面前，以在建築物上放置不同的企業名稱。換句話說，一些可配置的場景。
- 總的來說，在路線地圖或佈局中，這些 LHS 名稱對應於地圖資產上的命名物件，並且這是大多數字符串表出現的地方（從字面上看，在大型路線kind 地圖中成千上萬的條目填充）。
- 在某些資產中，該預設名稱與軟體指令碼掛鉤，因此字串表變得特別重要，而不是索然無味。（見下文）
- 在每種型別的資產中使用字串表型別始終是合法的，就像描述標籤和 trainz-build 和 kind 標籤一樣。與它們不同的是，它不必存在或定義，並且絕不是強制性的。封裝在字串表容器中的值除非程式碼期望它們結合，否則不會有任何功能或效果。
- 在其他資產中，再以那個假設的可程式設計商業標誌為例，如果該字串表要與軟體互動，則必須為其賦予一個預設名稱。所有地圖可放置資產都可以命名或重新命名，但“特殊名稱”必須與指令碼和字串表索引值匹配。大多數可配置資產定義一個介面變數，用於替換預設名稱作為指令碼引用的索引或查詢表，以及資產的二進位制資料。其他變數也可能在可程式設計資產中定義。這些變數中的每一個都可以透過指令碼引用，但正是索引值使它進入地圖或會話字串表，當需要駕駛員或會話建立者可變性時，這一切才能協同工作。
- 相比之下，如果系統軟體不知道索引中命名的專案的地址，則該物件的指令碼可能沒有觸發、條件檢查或更新能力。這是 2000 年代Trainz 1.0中物件的特徵，而不是 2003 年TRS2004釋出以來的更現代 Trainz 鐵路模擬器。（從那時起，我們已經走了很長一段路！）
- 有些資產只能作為一個組一起工作。在這樣的資產中，在對映或會話層中命名每一個資產，使其能夠協同工作。例如，考慮一個有五條軌道的公路平交道，其中兩條軌道是支線，與主線形成所謂的“菱形交叉”。如何設定訊號，以便任何鐵路交通都關閉公路閘門，或者使用菱形交叉不允許其他火車經過正在穿越交叉的火車。道路和鐵路訊號、道岔和閘門必須協同工作。某些“ATLS 系統”資產及其指令碼透過字串表相結合，可以使這個複雜的系統正常工作。
- 有關更多資訊，請參見 string-table-XX。
string-table-XX 容器
[edit | edit source]- 型別： UTF-8 字串列表容器，本地化字串表，每個字尾對應於除英語以外的其他語言。
- 欄位定義：（其中XX被替換為適當的本地化程式碼，用於表示正在使用的語言。）此欄位類似於string-table欄位，只是表示非英語語言環境。
英語字串表（無後綴）是必需的，其他本地化語言是可選的，由資產作者決定。許多提交到 DLS 的資產以及隨後用於與 Trainz 版本捆綁在一起的路線，通常會進行翻譯並有一套完整的本地化翻譯，用於 description-XX 和字串表。特別是，與版本捆綁在一起的路線和會話會收到針對每個零售版本的專業翻譯，翻譯成多種語言。
請注意，字串表的左欄是相同的，因為它是一個對映的符號表，索引到二進位制資料，例如網格、會話或路線檔案。只有使用名稱，即兩個元素中的右側或資料元素，才是本地化的，並由執行時本地化軟體替換。如果需要，這些名稱可以手動編輯，以獲得更友好的名稱，即使在英語字串表中也是如此。索引或左側引用欄的語法不得以任何方式更改，因此在更改資料欄中的名稱時，請謹慎使用全域性 SAR 規範。
資產中可能存在多個string-table-XX標籤，每個支援的語言一個。每個標籤都應包含一個字串列表，這些字串列表與string-table列表中的鍵相同，但值不同。如果不存在適當的“string-table-XX”標籤來在給定的終端使用者系統上表示此資產，或者該列表中缺少適當的字串，則會改為引用英語string-table容器。
kuid-table 容器
[edit | edit source]kuid-table {
numberit_library <kuid2:75134:99003:7>
0 <kuid:-3:10164>
1 <kuid:-1:42004201>
2 <kuid2:50567:11155:1>
3 <kuid2:58422:50120:1>
4 <kuid:-3:10003>
5 <kuid2:30671:94407101:1>
6 <kuid2:87907:94407101:1>
7 <kuid2:87907:94407103:1>
8 <kuid2:87907:94407105:1>
9 <kuid2:30671:9870190:1>
10 <kuid2:30671:94407100:1>
11 <kuid2:87907:94407100:1>
12 <kuid2:87907:94407102:1>
13 <kuid2:87907:94407104:1>
14 <kuid:-3:10013>
15 <kuid2:60318:10008:1>
16 <kuid2:60318:10010:2>
17 <kuid2:189041:301:1>
18 <kuid2:50567:11121:1>
19 <kuid2:30671:9840820:1>
20 <kuid2:30671:9870899:1>
21 <kuid2:50567:12646:3>
22 <kuid2:124017:30000:2>
23 <kuid2:124017:30001:2>
24 <kuid2:124017:30002:2>
25 <kuid2:124017:30003:2>
lodi_icon <kuid2:124017:35000:1>
lodi_lib <kuid2:124017:40000:1>
26 <kuid2:30671:69006:1>
27 <kuid2:124017:35000:1>
28 <kuid2:30671:90810901:1>
29 <kuid2:30671:9081290:1>
30 <kuid2:60318:10009:1>
}
- 通常
- 只有具有子元件或替代選擇（貨物）的資產才會具有長度可觀的 kuid-table。大多數具有子元件的資產只有幾個。
- 其次，存在一個來自有時內部關鍵字是“自動定義”的這樣一個事實而產生的慣例，僅僅列出為沒有名稱的數字，作為佔位符引數，偽關鍵字可以是任何唯一的值（通常是零索引的順序整數。[notes 1]）它們可以根據使用者或作者的偏好被賦予名稱或不賦予名稱。
- 此表中的條目有兩個目的
首先：確保遊戲系統瞭解依賴關係，以便安裝和載入此資產將成功安裝和載入所有依賴關係，以及
其次：允許指令碼查詢相關的子資產。 - kuid-table 中只應包含一級依賴關係，子資產或具有自身依賴關係的部件資產將在該子資產的驗證和資料庫提交過程中處理。
- 迴圈依賴關係是非法的。
- 如果資產也被標記為此資產的已廢棄版本，則該資產不能被列為依賴關係。（Trainz 資產索引（歷史上是 assets.tdx 檔案）中的 kuid 中只有一個替換 kuid 槽位，這將建立一個迴圈定義，要求自身的一箇舊版本！）
- 同樣，一個資產不能被列為其自身的依賴關係。[另一方面，這種情況已經發生過（即，在 TSxx CM 中作為成功提交的無故障資產被見證），在安裝之間使用 GSARS 移植地圖和會話，以更改 kuid，以便重疊不會覆蓋已經在目標安裝中使用相同 kuid 的資產，而不會看到錯誤訊息。]它是否也起作用，需要比我更勇敢或更愚蠢的人！--Fabartus，ed.
- 格式(所有值都是 <kuid:aaaaa.bbbbb> 格式)
kuid-table {
0 Kuid-1
1 Kuid-2
3 Kuid-3
... kuid-ii
N-1 Kuid-N
}
|
|
- 一個非常有用的利用這些是虛擬引數的事實，就是將複雜滾動庫存資產中的產品 kuid 配對。一輛箱式貨車可能包含各種各樣的產品……獲得許可權，將你的作者 ID 分配給你自己的系列，並設定不同的裝載集，這可能是你第一份意義重大的內容創作！考慮一輛貨車，允許的產品容器，kuid 列表可以包含以下條目
... {
Animal_chickens <kuid:-25:230>
Animal_Horses <kuid:-25:236>
Animal_Cows <kuid:-25:239>
Animal_Piggies <kuid:-25:238>
Animal_Sheep_Flock <kuid:-25:240>
} ...
請注意將單詞連線在一起的下劃線……兩個符號，鍵和值！我們讓學生弄清楚將 kuid 新增到裝載和允許的產品隊列表條目中的位置。（歡迎你，但這正是更改名稱的一個好理由！保持事情清晰幾乎是製作資產的全部戰鬥！）
obsolete-table 容器
[edit | edit source]- 型別：KUID 列表容器，與 KUID 表格容器 格式相同。
- 欄位定義：一個 “佔位符鍵 - 鍵 - 值” 列表，列出被此資產淘汰的資產。嘗試載入此列表中的任何資產 將導致載入此資產而不是被淘汰的資產。
- 此外：兩個資產不能都將第三個資產標記為已淘汰，除非兩個資產之一也標記另一個資產為已淘汰。[註釋 6]
- 迴圈淘汰引用是非法的。
- 此資產的所有低編號 KUID2 版本都隱含地視為已淘汰，無需包含在此列表中。同時，較新的改進資產（具有更高的 Kuid2）及其前身 不應在該列表中同時列出同一個前身（例如原始前身！）到 “中間” 前身 - 因為這些值用作 替代條目表，並且只有一個資產可以替代早期版本。（陣列只儲存一個值，不能用兩個值代替一個！）
- 標記此資產的更高編號 KUID2 版本為已淘汰是非法的，因為這會產生一個隱式迴圈引用。
- 此列表中引用的資產必須與此資產具有相同的建立者，才能透過 DLS 上傳過程進行稽核和接受。此限制不適用於您的本地版本，例如，可以用來將大型火車車組上的所有舊紙輪 KUID 替換為更美觀、更新的 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 個字元的 類別 - 類別 程式碼，用於描述此內容項。類別 - 類別 標籤用於提供超出資產型別隱含的附加人類子類別。每個 Trainz 資產的類別 - 類別標籤有助於描述資產在遊戲中的“意圖”，而不是資產的內部結構。
|
|
請注意，許多類別 - 類別程式碼只與特定的資產型別相關 - 類別 - 類別程式碼不得應用於不適當型別的資產。
- 示例
| 類別 - 類別 “XBG” | 箱車 - 來自 PRR 60' | |
| 類別 - 類別 “BR” | 鐵路（非功能性場景） - 可能是一棟建築 | |
| 類別 - 類別 “BIN” | 具有產品處理功能的工業資產 |
- 每個年代程式碼代表一個十年，由一個四位數整陣列成，然後 必須以 ‘s’ 結尾
（例如 “1990s;2000s;2010s”），因此建立一個列舉軟體標記（值），該標記必須與指定合法 年代程式碼 完全匹配。 - 字串中不應包含其他字元（包括空格等），包括（尤其是在字串末尾）在終止雙引號字元之前的字元。
- 允許的年份範圍是 1800-2010s[註釋 7]
- 此資產的唯一意義是對其他人類，即此資產被認為在指定的年代範圍內有效且適當相關，並且 內容管理器 將接受指定適用年份的搜尋過濾器。
- 示例
category-era "1920s;1930s;1940s;1950s"
- 用途：在 CM 和 Surveyor 中進行篩選（搜尋條件）
- 型別：縮圖容器.
- 欄位定義：在整個遊戲環境（包括遊戲內、在 內容管理器 和 下載站 中）用於在二維預覽框、列表和圖示形式中代表此資產的縮圖。每個資料集都包含在一個子容器中（通常）使用 佔位符引數 作為鍵名或標籤。[註釋 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 True Color）（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 Online 安全區域 中的網站。目前，嵌入式瀏覽器接受三個域
auran.com
ts2009.com
ts2010.com
此外，建議使用自定義 Trainz 短連結 格式，而不是直接連結到這些域名，以使 URL 能夠適應未來可能的網站佈局變化。 '短連結' 是 Trainz 特定的 URL，透過允許內容建立者引用 N3V 網站上的特定頁面，而無需依賴於特定的網頁佈局，從而幫助保護內容。 短連結旨在用於遊戲內使用，例如資訊 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。
The script-include-table 容器 是任何從 KIND TrainzBaseSpec 派生的資產可用的頂級 config.txt 檔案 條目（簡而言之，所有資產）。 此容器允許資產直接 包含另一個資產的指令碼 來自父資產的指令碼檔案，使用 N3V TrainzScript's Script_Include_Directive.
- 相關
擴充套件容器是一個自定義標籤或子容器的列表，具有特定的命名約定。
此容器是指令碼化資產名稱及其 KUID 的簡單鍵值表，在編譯資產的指令碼檔案時，將搜尋這些資產的指令碼包含。 鍵或標籤名稱目前未使用（即為 佔位符引數）進行搜尋；值指示要包含的資產的 KUID。 能夠搜尋和識別鍵名稱是內容建立者請求的功能，因此建議使用指令碼檔名而不是數字虛擬標籤名稱作為最佳實踐，因為它比 KUID 引用傳遞更多資訊。
通常最好將此類引用限制為 KIND 庫 資產，但這並非強制性要求，任何資產都可以被引用。
script-include-table {
a-key <kuid:nnnn:nnnnn>
enginespec <kuid2:www:xxxxx:yy>
anim-doors <kuid:tttt:uuuuuu>
}
- 型別： 擴充套件容器。
- 欄位定義： 一組擴充套件屬性，為指令碼提供超出為該資產型別定義的 Config.txt 檔案 規範的附加資訊。 在建立新的擴充套件時，應注意遵守擴充套件命名指南，並在為現有擴充套件提供資料時遵守擴充套件建立者的指南。 Auran 保留根據擴充套件建立者的指南在稍後日期新增對 擴充套件容器 中特定條目的驗證的權利。
以下關鍵詞是比較新的發展，在較舊的資產中沒有類似物或存在。
- 型別： UTF-8 字串。
- 欄位定義： 以分號 (;) 分隔的自然語言關鍵詞列表。 字串中不應該存在其他字元（包括空格或不相關的標點符號）。 這些關鍵詞構成了資產關鍵詞搜尋的基礎。 資產的 使用者名稱 不需要在 category-keyword 列表中重複。
- 根據資產型別（KIND+category-class）自動提供各種 預設搜尋關鍵詞，因此不需要，可能也不應該重複。 Ø
- 標籤可能不存在，因為標籤後的空字串 ("") 或空白 - 這些條件會生成錯誤。
- 明顯的用法：公司，如 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 方法滿足的現有特定指令碼需求，否則應將此標記留空。
member-of-groups 容器
[edit | edit source]- 最小版本: V3.5 及以上
- 型別： Member-of-groups 容器 與 佔位符引數 和 asset-group KUID 的配對列表。
- 欄位定義： 此資產所屬的 KIND_Asset-group 資產列表。有關如何以及何時使用它的詳細資訊，請參閱 kind KIND Asset-group 文件。
該容器包含 KIND Asset-group KUID 的常規列表。此包含宣告，此後，特別是在搜尋操作（包括指令碼介面和 TrainzUtil）中，該資產將被視為每個列出的資產組的成員。
如果為給定的“member-of-groups”容器未指定任何條目，或者如果資產省略了“member-of-groups”容器，那麼模擬器軟體可能會根據資產的 Config.txt 檔案指定一些預設資產組。確切的行為可能會因模擬器的不同版本而異，但是當前邏輯在 這裡 描述。
可選的已棄用標記
[edit | edit source]- 以下標記對於任何資產都不是必需的，許多資產都將其留空。
- 從歷史上看，識別和許可標記始於 Trainz 0.9（Beta）。
許可證
[edit | edit source]- 型別： UTF-8 多行字串。（根據程式設計師的命令棄用。）
- 欄位定義： 描述資產建立者希望如何使用此資產的許可證。最常看到的是禁止在任何付費路線、依賴資產（例如轉向架、耦合器等火車部件）或重新制作中使用受版權保護的資產的許可證宣告，包括在任何收費運營的網站上分發該資產。（從理論上講，即使對於 DLS 也是如此。FCT 費用用於更快地訪問和無限下載，而不是用於訪問資產。）
- DLS 上的大多數資產都是 Creative Commons 署名-相同方式共享（CC-BY-SA）的措辭不佳的版本，類似於此和其他維基媒體維基專案。
- 許可證標記的含義不明確，N3V 不建議使用它，但它的存在早於 N3V 管理 6-7 年。
- 上傳到 下載站 或提供用於包含在遊戲中的內容可能受特定重新分發合同或許可協議的約束，該協議優先於該欄位中的任何文字。許可證欄位不提供本地化支援。許可證欄位的文字不會由 Auran 或 N3V 驗證或執行，並且可能對終端使用者具有法律約束力也可能不具有法律約束力。
- 另一方面，Planet Auran 的歷史表明，有人透過將他人內容用作自己的內容來侵犯版權，可能會導致從 Auran 網站快速禁止訪問，並永久阻止訪問下載站許可權等。此外，社群將嚴厲打擊其他使用者侵犯他人的版權，並回避違反者，並忽略任何允許留在 DLS 上的資產。
- 總之，嘗試和修改資產是 Trainzer 試圖克服陡峭的內容建立學習曲線的一種被接受甚至被認可的生活方式（每個人都希望有更多內容建立者！），但如果資產有依賴部分，特別是網格、指令碼、紋理，這些是智慧財產權——在上傳您的作品之前，請獲得使用屬於他人的這些部分的許可。
|
|
作者標記
[edit | edit source]- 型別： UTF-8 字串。（已棄用，轉而支援可更新的 Planet Auran 資料庫。）
- 欄位定義： 作者的姓名或標記。不建議使用此欄位，因為屬性可以透過程式設計方式確定。
組織標記
[edit | edit source]- 請注意英國拼寫，北美拼寫“organization”也適用！
- 型別： UTF-8 字串。（已棄用，轉而支援可更新的 Planet Auran 資料庫。）
- 欄位定義： 負責建立此資產的組織的名稱或標記。不建議使用此欄位，因為屬性可以透過程式設計方式確定。
contact-email 標記
[edit | edit source]- 型別： 字串，電子郵件地址。（已棄用，轉而支援可更新的 Planet Auran 資料庫。）
- 欄位定義： 此資產建立者的聯絡電子郵件地址。不建議使用此欄位，因為屬性可以透過程式設計方式確定，並且聯絡方式可以針對建立者的 Auran 帳戶 Planet Auran 帳戶 註冊，在那裡可以限制或更新它們。
contact-website 標記
[edit | edit source]- 型別： URL 字串。（已棄用，轉而支援可更新的 Planet Auran 資料庫。）
- 欄位定義： 此資產建立者的聯絡網站。不建議使用此欄位，因為屬性可以透過程式設計方式確定，並且 [聯絡方式] 可以針對建立者的 Auran 帳戶 Planet Auran 帳戶 註冊，在那裡可以限制或更新它們。
已過時的標記
[edit | edit source] |
|
- 在初始編譯之後，一些在資料模型的舊版本中發現的常見但現在已過時的標記已新增到下面，例如在許多橋樑資產中發現的 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 雙字母后綴；'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 字串陣列，將這些標籤組合到 config.txt 檔案中的一行[note 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 程式設計人員版本會在主資源根資料夾或資源名稱_art 或資源名稱_body 資料夾中找到一個 .jpg 檔案（最好尺寸為 240x180 畫素），並用它來在 CMP 和 DLS 中顯示資源（如果資源已上傳）。該標籤在 TRS2006 中被棄用，因為縮圖容器是在 v2.0（TRS2004-SP0）中引入的。在較舊的修復資產中，如果TBV 保持在 v2.4 以下，只要它在 _art 子資料夾中並且資源名稱與使用者名稱匹配，縮圖通常仍可以在較新的 CM 中工作。
- type — V1.3–v2.8 —一個以前的過濾器修飾符，歷史上在幾乎所有資源中都有，但在滾動庫存、風景、脊椎、軌道型別（包括隧道和橋樑）和路邊資產中尤其普遍。
- type 標籤與 'region 標籤' 一樣，在 Trainz 0.9—TC3 版本中用作 'Surveyor 組內過濾器' ，它與 region 結合在一起，提供了更小的資產選擇（工具組）。自從 TS2009 移除了這些本地可單擊過濾器的功能和使用，轉而使用一個新的、更繁瑣的過濾器。這些使工具選擇變得快速而簡單，而不是在工具選項卡之間切換時變得緩慢並暫停 - 如今的 TANE 前版本在工具選項卡之間來回切換時，往往會因重新載入整個選擇列表而不堪重負。
- type 和 region 預設為 'All'，提供與 TS09 及其後的版本中的工具相同的超級列表。
- ↑ 資源提交（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 的一個 obsolete 條目，用 Kuid2 版本替換 kuid 會導致問題（即您會看到哪個？）。
• obsolete-table 的一個很好的用法是使用特定部件（尤其是轉向架）升級一系列資源。新增要被較新的優質轉向架替換的 kuid 混合，可以透過一次編輯來顯著改善路線或場景的外觀（前提是轉向架例如相容且尺寸正確！）。 - ↑ 最近使用過時的資源匯入 TANE 的經驗表明，至少有五個備用 kuid 替換了那個可憐的 Flip-tree 資源。似乎由於 speedtrees 引入造成的混亂以及 TANE 的徹底改革（它積極地追求最合適的更新資源），現在 ContentManager 流程中允許使用多個不同 kuid 的資源來替換同一個 kuid。作為一個良好的實踐，僅在絕對必要時使用 obsolete-table ... 例如，在您想要上傳到 DLS 或在網站上自行釋出的依賴資源中，取代一個不希望使用的付費資源。
- ↑ 關於類別時代標籤範圍：安全玩法，已知有效。其他 '未來十年' 值應在依賴於此類值之前進行測試。
- ↑ 許多容器在列表中使用虛擬/佔位符名稱。這些可以是描述性詞語，只要它們不包含空格字元。在短語構造的名稱中使用下劃線或句點可以保持可讀性，並顯著增強清晰度。例如，一輛貨運火車車廂可能裝載 45 種合法產品型別。這些將在依賴關係容器中列出。使用 Coal、granite、crushed_limestone 等，可以更輕鬆地維護和更改表格。Jes Sayin'，自 '76 年起擔任程式設計師
- ↑ 在第二個縮圖容器示例中，還有一個 512x512 大小的影像，是一個額外的影像。DLS 將使用哪個影像尚不清楚。還可以包含更大的影像尺寸，並且透過電子郵件聊天，T:ANE 可能會支援在預覽操作或 DLS 列表中使用的大影像尺寸。N3V Games 通常不會透露此類資訊。
- ↑ 早期的做法可以追溯到 Trainz 1.x，使用關鍵字/標籤 'thumb' 和引號中的路徑規範引用來引用 240x180 的縮圖影像，用於執行時選單。art 資料夾包含一個帶有 alpha 遮罩的 512x512 tga（通常是 bmp 檔案，但正確格式的 tga 可以用作自 alpha 遮罩）以及 64x128 選單圖示影像及其控制的 texture.txt 檔案。
- ↑ 在 2014-2015 年冬季與前任版本經理 James Moody 的私人電子郵件對話中，就該主題而言，DLS 上傳驗證軟體可能已經更改，因為從那時起就開始強制執行正確的縮圖容器。
- ↑ 關於類別時代-nn 與類別時代標籤值：TRS 會接受類別時代資料的兩種形式；但 TS2009-SP0 及其後的版本從以前合法的關鍵字-值對中建立了錯誤，並試圖強制內容建立者更改程式設計師故意破壞的所有資源。後來，DLS 上傳軟體強制執行了轉換，但這要好得多，因為第一個操作導致許多人浪費了數小時的修復時間，而這些修復是不必要的，應該在驗證較舊的 trainz 構建資源時在軟體預過濾傳遞中自動執行。這些操作實際上保證了較舊的資源下載將存在錯誤。這是 N3V 程式設計師所做的最愚蠢、最傲慢的事情之一，而 Auran 更有經驗的軟體人員永遠不會以如此輕率的態度對待社群的寶貴時間。
- 此頁面主要內容取自 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 程式碼 標準的更新資訊，這些標準在軟體新增功能時會有一些變化趨勢。 |