Trainz/refs/TrainzBaseSpec
KIND TrainzBaseSpec 為所有 Trainz 資產型別在所有 config.txt ini 檔案 中提供基本定義。TBS 提供了一些“標準標籤”，這些標籤對於任何和所有 Trainz 資產都是通用的（或至少，可以合法地定義）[1]。
- 其中一些是強制性的，因為它們決定了資產的進一步處理以及 config.txt 檔案和其資料夾中資產資料的解釋。
- 但是，大多數是可選的，大多數子資產可以省略使用該標記的定義行。
父類
[edit | edit source]- 無。有效且對於所有由事實上的父容器定義的內容（即所有 Trainz 數字模型所需的 config.txt 檔案）來說，大多數都是必要的。KIND TrainzBaseSpec (TBS) 是一個根類，其他 Trainz 資產類由此派生。
- 之所以說它們是派生的，是因為它們繼承了其中列出的引數定義的處理屬性（指令）和值，其中最關鍵的是 kind 標記的值。該列舉詞決定了資產的具體種類宣告和要求，這些要求會新增到該資產配置檔案中 TBS 的定義中。其他關鍵的 TBS 定義資料也很重要且實用，例如資產名稱、Kuid 識別符號和版本、Trainz 構建值 (TBV) 以及其他具有廣泛可變定義需求、適用性和範圍的資料，例如string-table、obsolete-table、kuid-table 和縮圖影像都是偶然的。字串值，甚至是資產名稱和描述，在實踐中通常是完全不必要的，可以完全省略。
- 當宣告一種種類時，該種類將成為父類，需要並規定必須在該類中滿足的必要資料對，除了 TBS 中列出的那些資料之外。
- 某些引數可以在資產類別的具體情況下保持未定義，尤其是對於較舊的歷史 Trainz 構建標記值來說，對於這些值，內容管理器或內容建立者 Plus (CCP) 實用程式將分配一個預設值，但在處理它時會列出警告訊息。TrainzOnline wiki、此處或較舊的 TC3 時代內容建立者指南 (CCG 將提到一個預設值。
- 從 TRS2006 和 Trainz Classics (TC1&2) 開始的每個版本的內容管理器模組都會越來越多地實施預先承諾的錯誤測試[note 1]，並且每個模組在警告此類標記未定義時變得越來越堅決，因為它期望此類標記 - 資料對。
在 TANE 後期釋出的版本中，許多這些“昨天預設”的定義行如今將更頻繁地生成故障，要求明確定義值，而過去在載入時預設使用了這些值。[note 2] 與舊時代相比，這是一種比較好的煩惱，因為在舊時代，錯誤的資產定義有時會導致臭名昭著的“藍色畫面宕機”或更常見的情況，使執行時軟體崩潰回桌面，導致編輯丟失，並且可能需要重建資料庫。
子類
[edit | edit source]
所有 Trainz 定義的資料（內容）都有三個必需的元素：一個config.txt 檔案 用於組織資料，一個標識，即一個kuid（僅使用者名稱無用，但可以建立合法的資產，即使沒有名稱！），最後，一個合法定義的種類標記。種類負責，是樂隊的指揮、排長或執行長下達指示——為在之後處理的所有內容設定要求。簡而言之，種類值（一個小型、精選的嚴格定義的成員專屬組）告訴 Trainz 軟體在建立的虛擬世界中要渲染和顯示什麼以及如何（或在何處）找到與該 config.txt 檔案中連結在一起的資產部分的其他部分。
下面的每個子類都被認為具有TrainzBaseSpec 作為其資料的“父類”。[note 3] 下面列出的幾種種類（帶下劃線的那些）是遺留種類，早於 TS2009 釋出中對 Trainz 資料模型 的更改（即自 2008 年後期以來），N3V 程式設計師只對這些種類進行了逐漸的（增量的）更改。
目前可以在 N3V Trainz Wiki 的 內容建立者指南 部分找到有關修復基於這些遺留種類的資產的詳細資訊TrainzOnline 網站在此處，以及具有啟發意義的 遺留種類的示例在此處。強烈建議 Trainz 下載站 的任何使用者或任何考慮建立內容的使用者閱讀 CCG。瞭解如何定義舊內容的背景歷史可以與 TrainzOnline 對同一資料型別的當前覆蓋範圍進行對比和比較，因為這種過去的對比往往能為修復、更改和自定義資產提供寶貴的見解。更重要的是，CCG 中的文字是專業製作的，並且更具自明性——它通常會讓你瞭解如果更改了這個或那個，會產生哪些擴充套件影響，而 Trainz Wiki 卻無法提供這些見解。TrainzOnline 上釋出的 CCG 是 TC1&2/TC3 版本——這是從 1999 年的 Trainz 開始的幾本印刷手冊的最後一個出版版本；TC3 CCG 包含需要正確更新的 TRS2004/TRS2006 和 UTC 資料模型中更改的 Enginespecs 機車資產。
TBS 標準定義
[編輯原始碼]這些標籤和容器是標準定義，幾乎可以在所有資產中找到。一些標籤是可選的，內容建立者可以根據自己的選擇來定義它們。標籤是關鍵字，並具有單個分配的鍵值或容器，例如字串陣列或'{' ... '}' 繫結封閉的標籤值對或子容器。（Trainz 配置檔案中的所有宣告都是成對的，即使 '{' ... '}' 也被認為是一個鍵值。
- 容器是'鍵' 和 '鍵值' 對的集合以及 TBS 中的 '上層容器'（與縮圖容器內的子容器相反）通常以 '-table' 為字尾。
| 種類 | "'字串值'" |
| trainz-build | '浮點數', 1 位小數 |
| kuid | <Kuid 編碼值> |
| 使用者名稱 | 使用者名稱 "'字串值'" |
| 使用者名稱-XX | 使用者名稱-XX "'字串值'" |
| 描述 | 描述 "'字串值'" |
| 描述-XX | 描述-XX "'字串值'" |
| kuid 表 (容器) { 依賴項列表 |
一個鍵值表，列出此資產所依賴的所有資產。 |
| 過時表 (容器) { } |
kuids 列出此資產替換（使過時）的資產 通常沒有（為空）[註釋 5] |
| 字串表 (容器) { } |
資產中使用的字串和訊息的鍵值列表 通常為空，僅在路線和場景中較大。 |
| 字串表 (容器[s]) { 非英語 語言文字 } |
翻譯字串列表 匹配到 強制性的英語 字串表 |
| 類別-地區標籤 列舉 程式碼 | 類別-地區 "'字串陣列'" |
| 類別-類別標籤 | 類別-類別 "'列舉 字串值'" |
| 類別-年代標籤 | 類別-年代 "'約束字串陣列'" 十年 |
| 類別-關鍵字 "'字串陣列'" 最長 64 位元組 | 類別-關鍵字標籤 自然語言搜尋關鍵字 (替換型別、地區) |
| 自定義類別列表 "'字串陣列'" |
指令碼介面功能 |
| 必須擁有產品權利 "'字串值'" |
DRM 字串陣列 |
| 不得擁有產品權利 "'字串值'" |
DRM 字串陣列 |
| 特權 (容器) { } |
更多 DRM |
| 縮圖 (容器) { } |
縮圖容器 |
| 指令碼 (檔名) | "'字串值'" |
| 類 (指令碼資產類) | "'字串值'", 必須與 指令碼 規範類同步。 |
| 指令碼包含表 { } |
(列出庫指令碼的容器) |
| 擴充套件 (容器) { } |
資產也使用的正式指令碼擴充套件 |
| 許可證 "'字串值'" | 資產建立者的版權宣告 |
| 作者 | "身份 '字串值'" |
| 組織 | "第三方組身份 '字串值'" |
| 聯絡電子郵件 | "電子郵件地址 '字串值'" |
| 聯絡網站 | "作者/組的網頁地址 '字串值'" |
| 所屬組 (容器) { } |
此資產所屬的 KIND 資產組 資產列表。 |
TrainzBaseSpec 在 config.txt 檔案 中支援以下標籤。 ∅:
- 型別: 字串。
- 欄位定義: 此 config.txt 檔案 所代表的資產型別。請參閱索引 種類 和列表: 此處（上方）
- KUID
- 'Koolthingz Unique IDentifier'. Trainz 系統軟體為資產分配的唯一資料庫參考編號，在 KUID2 形式中也擴充套件到跟蹤多個版本。Trainz 可升級性的核心和靈魂，以及資產的模組化設計，因為每個資產都有自己的唯一 kuid 程式碼，所以可以從另一個資產中指定元件（轉向架）或整個火車車廂，並選擇性地在新的資產中替換任何一個（重新蒙皮或修改卡車）。
- 基本 KUID 格式: '<kuid:wwwwww:xxxxxx>'，其中 wwwwww 是作者的 '唯一 Trainz 標識'，xxxxxx 代表作者分配的 模型標識程式碼。
 |
|
- 大多數 Trainz 資產在它們的 kuid 表 中指定依賴項列表，即軟體套件的各個部分組裝的其他元件資產，以構成 kuid 表容器 中可渲染和可使用的資產。
- 在許多資產的核心內部，特定的標籤可以由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，是終極任何東西…… 真的嗎？來吧，夥計！真的嗎？！）。
- 從 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 版本，這通常解析為 1.3 作為 TBV。
- 型別： UTF-8 字串，資產的使用者名稱，強制性規範。
- 欄位定義： 此資產的英文人眼可見名稱。
在 TC1 和 TC2（v2.7）之後的 trainz-build 中，使用者名稱在編輯資產時也成為作業系統資料夾名稱，而資產檔名被忽略，而它在 v2-6 配置檔案中占主導地位。根據 N3V games 的 TBS 標準，此欄位絕不應包含非英文文字，除非資產名稱是專有名詞（例如地名）並且沒有英文字地化變體。此值是每個人通常搜尋和記住的資料，因此建議保持一個清晰的名稱。
 |
|
- 型別： UTF-8 字串，使用者名稱標籤 的替代語言版本。
- 欄位定義： （其中XX 被替換為所代表語言的適當 本地化程式碼。）此資產的本地化人眼可見名稱。此欄位類似於使用者名稱欄位，但代表非英語語言環境。一個資產中可能存在多個使用者名稱-XX 標籤，每個支援的語言環境一個。如果在給定終端使用者系統上不存在合適的 '使用者名稱-XX' 標籤來代表此資產，則使用英文使用者名稱標籤代替。
- 型別： UTF-8 多行字串，提供資產的清晰語言描述。
- 欄位定義： 此資產的英文人眼可見描述性摘要。
描述在 Content Manager 的“資產詳細資訊”窗格中可見，用於闡明資產名稱，提供規格，以及通常的一些歷史資訊。
N3V 的 Chris Bergmann 已經表示，此欄位應保持簡短（1-2 段），描述資產，並且應透過info-url 頁面提供擴充套件的詳細資訊，但可以容忍相當長的文字塊。有些人使用文字塊的底部作為版本更改記錄。
此欄位必須由英文描述性文字組成，儘管文字可能引用非英文專有名詞，如其他地方所述。其他語言翻譯或源文字應放在許多可能的替代語言本地化標籤之一中（請參閱 description-xx 標籤）。
- 型別： UTF-8 多行字串，描述標籤。
- 欄位定義： （其中XX 被替換為所代表語言的適當 本地化程式碼。）此資產的本地化人眼可見描述性摘要。此欄位類似於描述欄位，但代表非英語語言環境。一個資產中可能存在多個description-XX 標籤，每個支援的語言環境一個。如果在給定終端使用者系統上不存在合適的 'description-XX' 標籤來代表此資產，則使用英文描述標籤代替。
- 型別： UTF-8 字串列表容器，字串表容器(s)。
- 欄位定義： 一個英文字串的鍵值列表。每個鍵都是一個有意義的指令碼識別符號，對映到二進位制資料並被二進位制資料引用。每個值都是一個英文字串。一個英文字串可能包含或引用一個非英文專有名詞作為識別符號。由非英語母語作者創作的資產仍然必須建立一個沒有後綴的字串表容器（如果需要）。軟體只連結並引用字串表容器中沒有後綴的名稱和值，這將使西班牙語、法語、德語、捷克語、荷蘭語……日語作者感到非常困擾。換句話說，帶字尾的字串表僅用於翻譯目的，這在用非英語編寫地圖時會導致問題——沒有 string-table-en 來提供用於反向翻譯的表。同樣，username-en 和 description-en。所有三種缺失都表明了一種老式的和輕率的傲慢和對世界動態的漠不關心。
其他語言透過類似的字串表 (例如 string-table-XX) 支援，這些字串錶帶有與 description 和 username 關鍵字/標籤的國際化字尾匹配的本地化程式碼字尾 (XX)，但這些語言鍵控字串表容器將始終在左側條目中具有相同的鍵值。
- 這些左側鍵或標籤既用作'本地索引關鍵字'，又用作語言之間的'等價表'。
- 左側欄將始終包含內容創作者給予“特殊”名稱的物件，例如訊號、軌跡標記和行業、連線點等的名稱，這些名稱可能會被引用，並且會出現在“驅動程式和測量員”模組的“查詢公用事業”（CTRL+F ) 功能小程式中。
- 相反地，索引側也不會列出預設名稱，例如，在構建路線圖時，由隨機數自動索引的無數連線點集合（即毫無意義的雜亂。如果重要，路線構建 CC 將對其命名！）；但會自動包含潛在的臨時資產，例如火車車的預設名稱。如果重新命名，這些名稱將取代其相應的預設名稱。
- 它的主要用途是針對那些旨在與指令碼引用互動並採用可變屬性的物件，例如火車站或行業需要的或準備在行業中運輸的產品數量，或者由互動式火車車（滾動行業到指令碼）和其他可配置資產攜帶，簡單如通用廣告牌樣式標誌，透過一些高度調整和角度扭矩，可以放置在股票建築或行業的正面，在建築上放置不同的商業名稱。換句話說，一些可配置的場景。
- 總的來說，在路線圖或佈局中，這些 LHS 名稱對應於地圖資產上的命名物件，這就是大多數字符串表出現的地方（從字面上看，由大型路線kind map中的數千個條目填充）。
- 在某些資產中，該預設名稱與軟體指令碼掛鉤，因此字串表變得特別重要，而不是索然無味。（見下文）
- 在每種型別的資產中，使用字串表型別始終是合法的，就像描述標籤和 trainz-build 和 kind 標籤一樣。與這些不同，它不必存在或定義，並且絕非強制性。封裝在字串表容器中的值，除非程式碼期望它們結合，否則沒有功能或效果。
- 在其他資產中，再次以假設的可程式設計商業標誌為例，如果字串表要與軟體互動，就需要賦予其預設名稱。所有地圖可放置資產都可以命名或重新命名，但“特殊名稱”必須與指令碼和字串表索引值匹配。大多數可配置資產定義一個介面變數，用於替換預設名稱作為指令碼引用的索引或查詢表，以及資產的二進位制資料。其他變數也可能在可程式設計資產中定義。這些變數中的每一個都可能被指令碼引用，但正是索引值使其進入地圖或會話字串表，從而使所有內容在需要驅動程式或會話建立者可變性時協同工作。
- 相反，如果沒有系統軟體知道索引中命名的專案的地址，物件的指令碼可能不會有觸發、條件檢查或更新的能力。這是 2000 年代Trainz 1.0中物件的特徵，而不是自 2003 年TRS2004釋出以來的更現代的 Trainz 鐵路模擬器。（從那時起，我們已經走了很長一段路！）
- 有些資產只能作為一個組一起工作。在這種情況下，在地圖或會話層中為每個資產命名，使其能夠一起工作。例如，考慮一個具有五條軌道的公路平交道，其中兩條軌道不在連線點上，並與透過軌道形成所謂的“菱形交叉口”。如何設定訊號，以便任何鐵路交通都會關閉公路大門，或者使用菱形交叉口會禁止其他火車透過正在穿越交叉口的火車。道路和鐵路訊號以及道岔和大門都必須協同工作。某些“ATLS 系統”資產及其指令碼與字串表結合，可以使這個複雜的系統發揮作用。
- 有關更多資訊，請參見 string-table-XX。
string-table-XX 容器
[edit | edit source]- 型別： UTF-8 字串列表容器，本地化字串表，每個字尾對應於除英語以外的其他語言。
- 欄位定義：（其中XX被替換為適當的本地化程式碼，用於表示該語言。）此欄位類似於string-table欄位，不同之處在於表示非英語語言環境。
英語字串表（無後綴）是強制性的，其他本地化語言在資產作者的決定下是可選的。許多提交到 DLS 然後在與 Trainz 版本捆綁的路線中使用的資產通常會被翻譯，並具有完整的本地化翻譯集，用於 description-XX 和 string-table。特別是，與某個版本捆綁的路線和會話在每次零售版本中都會被專業地翻譯成多種語言。
請注意，字串表的左側欄是相同的，因為它是一個對映符號表，並索引到二進位制資料中，例如網格、會話或路線檔案。只有使用名稱，即兩個元素中的右側或資料元素，才是本地化的，並由執行時本地化軟體替換。如果需要，這些名稱可以手動編輯以獲得更友好的名稱，即使是在英語字串表中也是如此。索引或左側引用列語法絕不能更改，因此在資料列中更改名稱時，請注意全域性 SAR 規範。
資產中可能存在多個string-table-XX標籤，每個支援的語言一個。每個標籤都應該包含一個字串列表，該列表與string-table列表中的鍵相同，但值不同。如果不存在適當的“string-table-XX”標籤來表示給定終端使用者系統上的此資產，或者該列表中缺少適當的字串，則會引用英語string-table容器。
kuid-table 容器
[edit | edit source]kuid-table {
numberit_library <kuid2:75134:99003:7>
0 <kuid:-3:10164>
1 <kuid:-1:42004201>
2 <kuid2:50567:11155:1>
3 <kuid2:58422:50120:1>
4 <kuid:-3:10003>
5 <kuid2:30671:94407101:1>
6 <kuid2:87907:94407101:1>
7 <kuid2:87907:94407103:1>
8 <kuid2:87907:94407105:1>
9 <kuid2:30671:9870190:1>
10 <kuid2:30671:94407100:1>
11 <kuid2:87907:94407100:1>
12 <kuid2:87907:94407102:1>
13 <kuid2:87907:94407104:1>
14 <kuid:-3:10013>
15 <kuid2:60318:10008:1>
16 <kuid2:60318:10010:2>
17 <kuid2:189041:301:1>
18 <kuid2:50567:11121:1>
19 <kuid2:30671:9840820:1>
20 <kuid2:30671:9870899:1>
21 <kuid2:50567:12646:3>
22 <kuid2:124017:30000:2>
23 <kuid2:124017:30001:2>
24 <kuid2:124017:30002:2>
25 <kuid2:124017:30003:2>
lodi_icon <kuid2:124017:35000:1>
lodi_lib <kuid2:124017:40000:1>
26 <kuid2:30671:69006:1>
27 <kuid2:124017:35000:1>
28 <kuid2:30671:90810901:1>
29 <kuid2:30671:9081290:1>
30 <kuid2:60318:10009:1>
}
- 通常
- 只有具有子元件或具有替代選擇（貨物）的資產才會具有長度可觀的 kuid-table。大多數具有子元件的資產只有幾個。
- 其次，由於內部關鍵字有時是“自動定義”的，因此只列出一個沒有名稱的數字，作為佔位符引數，偽關鍵字可以是任何唯一值（通常是零索引順序整數。[notes 1]）。使用者或作者可以根據喜好為其命名或不命名。
- 此表中的條目有兩個用途
首先：確保遊戲系統知道該依賴項，以便安裝和載入此資產會成功安裝和載入所有依賴項，以及
其次：允許指令碼定位相關的子資產。 - kuid-table 中只應包含第一級依賴項——具有自身依賴關係的子資產或部分資產將在該子資產的驗證和資料庫提交中處理。
- 迴圈依賴是非法的。
- 如果資產也被標記為該資產的過時版本，則不能將其列為依賴項。（在 Trainz 資產索引中，kuid 中只有一個替換 kuid 槽（歷史上為 assets.tdx 檔案），這將建立一個迴圈定義，要求該資產的較舊版本！）
- 同樣，資產也不能被列為自身的依賴項。[OTOH，這在將地圖和會話移植到安裝中並使用 GSARS 更改 kuid 以避免重疊，而不會覆蓋已在目標安裝中使用相同 kuid 的資產，並且不會出現錯誤訊息時，已被體驗到（即，作為 TSxx CM 中成功無故障提交的資產而被見證）。] 是否也需要這樣做，則需要比我更勇敢或更愚蠢的人！ --Fabartus，編輯。
- 格式 (所有值均為 <kuid:aaaaa.bbbbb> 格式)
kuid-table {
0 Kuid-1
1 Kuid-2
3 Kuid-3
... kuid-ii
N-1 Kuid-N
}
|
|
- 一個非常有用的利用這些是虛擬引數的事實是將複雜滾動庫存資產中產品的 kuids 配對。一輛貨車可能包含各種各樣的產品... 獲得授權將你的作者 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 中過濾（搜尋標準）
- 型別： 列舉字串或字串陣列。
- 欄位定義： 一個由分號（';'）分隔的兩個字元 category-region 標籤 程式碼列表。字串中不應存在其他字元（包括空格等）。此資產被認為與指定的每個區域相關——這與 kind traincar 和 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 "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 的“圖示”，用於 Railyard 和測繪員資產選擇 API，它應該有一個 Alphamask 或一個非常淺色的背景。許多舊的沒有使用 jpg 檔案，而是在一個“_art”子資料夾中列出 .tga 檔案（Targa 真彩色）（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 熱修復程式中被放棄，因為使用者社群中出現了許多抱怨。
• 如果缺少縮圖容器的資產（即使使用了過時的 thumb 標籤）後來在新的內建路線或會話中被選中，該資產通常會作為沒有影像的專案進行分發 - 如果紋理.txt 或 config.txt 縮圖容器沒有正確引用，它們會被剝離出來[註釋 11]。
- 型別：URL 字串。
- 欄位定義：指向資產的線上描述、資產說明（幫助）或 TrainzOnline wiki 上其他幫助頁面的連結，旨在從嵌入式專用 N3V 瀏覽器中使用。URL 必須解析到 Trainz 線上安全區 中的某個網站。當前，嵌入式瀏覽器接受三個域名
auran.com
ts2009.com
ts2010.com
此外，不建議直接連結到這些域名，而是使用自定義 Trainz 短 URL 格式，以防範將來網站佈局可能發生的更改。'短 URL' 是 Trainz 特定的 URL，它們透過允許內容建立者引用 N3V 網站上的某些頁面（不依賴於特定的網頁佈局）來幫助保護內容的未來。短 URL 旨在用於遊戲內用途，例如 info-url 連結，並且僅在嵌入式網頁瀏覽器中有效，而不在任何外部網頁瀏覽器中有效。如果此標籤存在，遊戲內按鈕將提供給使用者，允許他們檢視資產描述或幫助，而無需離開遊戲環境。
這對於駕駛員來說非常有價值，可以訪問路線地圖、指南或會話說明或說明。
建議在任何情況下都使用通用組頁面來處理整個類別的資產，只要這些資產提供類似的功能，但外觀略有不同。這減少了建立、維護和本地化此類文件的時間開銷。
- 型別：ASCII 字串。
- 欄位定義：必需的產品許可權列表，用分號 (;) 分隔。如果本地安裝沒有必需的產品許可權，則某些遊戲系統可能無法載入資產。
- 型別：ASCII 字串。
- 欄位定義：衝突的產品許可權列表，用分號 (;) 分隔。如果本地安裝具有其中一個列出的產品許可權，則某些遊戲系統可能無法載入資產。
- 型別：許可權容器 是某些作者使用的 DRM、版權保護實施，也可以稱為許可權 DRM 容器。DRM 表示數字版權管理，這就是它實現的內容。如果定義了，某些引數甚至會阻止檢視 config.txt 檔案 以獲取資產。
- 欄位定義：由資產建立者設定的一組許可權，用於控制如何操作此資產。
privileges {
is-payware-content 0
permit-listing 1
permit-edit 1
permit-commit 1
}
上面的容器使用預設值設定，這意味著
- 0) 這不是付費軟體，因此其他欄位具有相關性 [當付費軟體編輯和提交為零時，但列出可能是允許的]；
允許
- 1) 檢視 config.txt 檔案 的資產，
- 2) 編輯資產，包括檢視其主資料夾中元件檔案的內容，
- 3) 重新儲存對資產的任何更改（將重新驗證的資產提交（提交）到資料庫）。
- 型別：字串檔名。
- 欄位定義：指示此資產的主指令碼檔案的檔案路徑（如果有）。此檔案路徑應始終以“.gs”副檔名結尾 - 執行時將嘗試新增或替換“.gs”副檔名，如果檔案路徑具有其他副檔名。
- 型別: 字串。
- 欄位定義：指示要載入為此資產的主類（如果有）的指令碼類名稱。此類從此資產的主指令碼檔案載入。
- 型別：kuid 引數和對應名稱的列表作為鍵。
- 欄位定義：指令碼資產的鍵值表，在編譯此資產的指令碼檔案時搜尋指令碼包含。鍵（一個變數，因此不是標籤）當前未使用，但必須是唯一的；值指示要包含的資產的 KUID。
script-include-table 容器 是任何從 KIND TrainzBaseSpec 派生的資產（簡而言之，所有資產）都可以使用的頂級 config.txt 檔案 條目。此容器允許資產使用 N3V TrainzScript 的 Script_Include_Directive，直接從父資產的指令碼檔案包含另一個資產的指令碼。
- 相關
擴充套件容器是帶有特定命名約定的自定義標籤或子容器的列表。
此容器是指令碼資產名稱及其 kuid 的簡單鍵值表，在編譯資產的指令碼檔案時搜尋指令碼包含。鍵或標籤名稱當前未使用（即為 佔位符引數）進行搜尋；值指示要包含的資產的 KUID。能夠搜尋和識別鍵名是內容建立者要求的功能，因此建議使用指令碼檔名而不是數字虛擬標籤名作為最佳實踐，因為它比 kuid 引用傳遞更多資訊。
通常最好將此類引用限制為 KIND 庫 資產，但這並非強制性，任何資產都可以被引用。
script-include-table {
a-key <kuid:nnnn:nnnnn>
enginespec <kuid2:www:xxxxx:yy>
anim-doors <kuid:tttt:uuuuuu>
}
- 型別：擴充套件容器。
- 欄位定義：一組擴充套件屬性，它們為指令碼提供了超出Config.txt 檔案為這種資產型別定義的規格的額外資訊。在建立新的擴充套件時，應注意遵守擴充套件命名指南，並在為現有擴充套件提供資料時遵守擴充套件建立者的指南。Auran 保留根據擴充套件建立者的指南，在日後為擴充套件容器中特定條目新增驗證的權利。
以下關鍵字是比較新的發展，在較舊的資產中沒有類似物或存在。
- 型別：UTF-8 字串。
- 欄位定義：用分號 (;) 分隔的自然語言關鍵字列表。字串中不應出現其他字元（包括空格或不相關的標點符號）。這些關鍵字構成了資產關鍵字搜尋的基礎。資產的使用者名稱不需要在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 標籤|custom-category-list 字串|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 檔案指定一些預設資產組。確切的行為可能會在模擬器的不同版本之間發生變化，但是當前的邏輯在此處進行了描述。
- 以下標籤對任何資產來說都不是強制性的，而且許多資產將其留空。
- 歷史上，標識和許可標籤始於 Trainz 0.9（Beta）。
- 型別：UTF-8 多行字串。（已由程式設計師法令棄用。）
- 欄位定義：描述資產建立者希望如何使用此資產的許可證。最常見的是許可證宣告禁止在任何付費路線、依賴資產（例如轉向架、聯軸器等火車部件）或重製版中使用受版權保護的資產，包括在任何收費網站上分發該資產。（理論上，即使對於 DLS 也是正確的。FCT 費用是為了更快地訪問和無限次下載，而不是為了訪問這些資產。）
- DLS 上的大多數資產都是對所謂的知識共享署名-相同方式共享 3.0 未移植許可（CC-BY-SA）的措辭不當的版本，就像這個和其他的維基百科維基專案一樣。
- 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) 資源中，用 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 國家程式碼的 'string-array'* 所取代。
- 用 string-array 型別 category-region 替換，該型別不包含空格，並在引用的標籤部分中列舉的兩個字元國家程式碼之間使用分號隔開；這些程式碼以兩個大寫字母的全寫形式給出，包含 列舉 程式碼，程式碼之間用 ';' 分隔，但最後一個程式碼在終止結束引號之前沒有分隔符。
- 字串陣列中的任何 空格 都會導致讀取錯誤和故障訊息，包括結尾引號之前的空格。
- region — TBS V1.3–v2.8 中有效的內建過濾器和地圖資產自定義本地化識別符號 (kuid)；現在唯一合法的標籤用途是在 地圖 (佈局) 資產中。
- 作為以前的過濾器修飾符，該標籤在歷史上幾乎所有資產中都存在，但它尤其普遍存在於滾動庫存、場景、樣條資產、軌道型別（包括隧道和橋樑）和具有某種程度本地化的路邊資產中。
- 地圖資產仍然保留關鍵字 Region，該關鍵字在 Map 配置中定義，其用途相反——作為 區域 kuid 引用。因此，Region *在 Maps 中是必需的*，並且自從 TS2012 起，像標籤型別一樣，在它曾經作為 TRS 系列版本 Surveyor 工具視窗的 '分組資料' '快速過濾器' 出現的大量資產中是非法的。
- 在 TRS2009 之後，任何 region 標籤到文字字串都已過時，因為在程式設計師的意識中，他們用 選擇列表 替換了 Surveyor 工具中 'type 和 region' 字串值的 *粗略過濾* 組選擇器。這兩個標籤都有一些優點和缺點，並且都追溯到 Trainz 0.9 Beta 版本。
shadows 標籤
[edit | edit source]
thumbnail 標籤
[edit | edit source]thumbnail 標籤是 縮圖容器 的早期單檢視實現（上面也有簡要說明）。Trainz 的早期 pre-N3V 程式設計師版本將在主資產根資料夾或資產名稱_art 或資產名稱_body 資料夾中查詢一個 .jpg 檔案，最好大小為 240x180 畫素，並將其用於在 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 取消了這些本地可點選過濾器功能和使用，轉而使用新的、更繁瑣的過濾器。這些使工具選擇變得快速簡單，而不是在工具選項卡之間切換時變慢和暫停——如今的 pre-TANE 版本在工具選項卡之間來回切換時，經常會因重新載入整個選擇列表而不堪重負。
- type 和 region 都預設設定為 'All'，提供與 TS09 及其後版本中的工具相同的超級列表。
筆記
[edit | edit source]- ↑ 資產 提交（TANE 的提交）是將內容納入資料庫並將其在 DB 索引中交叉引用，以便在執行時模組中訪問它的過程和步驟。
- ↑ 驗證資產的一種方法是，除了這些值之外，其他方法還可以，將 TBV 降至 2.5-3.7 範圍，看看這些訊息是否消失。您可能需要嘗試幾次降低 TBV 直到足夠低，反之亦然，在較舊的 TBV 中無法識別的較新關鍵字可能會發出不同的錯誤訊息。不要害怕嘗試，即使這樣失敗也會產生知識和經驗，而且你不會破壞任何東西！如果是這樣，您可以確信只是提供一個值就是解決問題的辦法。通常，一些現代需求只需要關鍵字對，因此在標籤之後使用空白行或在標籤之後使用空的括號對來表示容器將滿足需求，其中錯誤測試有點過於嚴格。
- ↑ 注意：此列表在 N3V TrainzOnline Wiki 上是 '維基化' 的，這意味著在 'KIND' 之後第一個字母已大寫，而 config.txt 檔案中的實際資料標籤名稱是 全部小寫 文字。該維基還使用雙引號來表示許多術語，我們將在本文中免除您體驗這種做法。
- ↑ 'kind consist' 並不經常直接看到，它只存在於選單和內容管理器列表中。
- ↑ 必須謹慎使用過時表，它最常出現在 Auran 創作的資產中。該表用較新的版本替換了較舊的 kuid，大多數內容建立者正確地使用 kuid 的 Kuid2 形式來取代較舊的版本。相比之下，N3V 過度使用了過時表來更新新版本 '升級' 的內建資產，這會導致很多混亂，並導致無法獲得人們期望看到的內容。（例如，許多不錯的 '翻轉樹' 在 TS10 和 TS12 中被過時，轉而使用 加速樹，這影響了許多路線，因為建立者在這些路線中 *不想要* 也不 *需要* 加速樹。在所有安裝中，這也會導致依賴項缺失，直到可以找到包含過時表的資產為止。
• 此外，Assets.tdx 資料庫索引中只支援每個 kuid 的一個過時條目，用 Kuid2 版本過時 kuid 會導致問題（即你將看到哪個？）。
• 過時表的一個很好的用途是使用特定部件（特別是轉向架）升級一系列資產。新增一系列 kuid 以用較新的好的轉向架替換，可以顯著改善路線或會話的外觀，只需進行一次編輯即可（前提是轉向架，例如，是相容的並且尺寸合適！） - ↑ 最近使用過時的資產匯入 TANE 的經驗表明，至少有五個備用 kuid 過時了那個可憐的 翻轉樹資產。由於加速樹的引入造成的混亂以及 TANE 的大修，它積極地追求最合適的更新資產，現在在內容管理器程序中容忍了多個不同 kuid 的資產過時了同一個 kuid。作為一個良好的實踐，只有在絕對必要時才使用過時表……例如，在您要上傳到 DLS 或在網站上自行釋出的依賴資產中，使用過時表來替代不想要的付費資產。
- ↑ 關於 category 時代的標籤範圍：安全的操作，已知有效。其他 *'未來十年'* 值應在依賴這些值之前進行測試。
- ↑ 許多容器在列表中使用虛擬/佔位符名稱。這些可以是描述性詞語，只要它們不包含空格字元。在短語構造的名稱中使用下劃線或句點可以保留可讀性並大大提高畫質晰度。例如，一輛貨運車廂可能裝載 45 種合法產品型別。這些將在依賴項容器中列出。使用 Coal、granite、crushed_limestone 等，可以使維護和更改表格變得更容易。Jes Sayin' 作為一名自 '76 年以來的程式設計師
- ↑ 在第二個縮圖容器示例中，有一個第二張 512x512 大小的影像，這是一個額外的影像。DLS 使用哪個是未知的。也可以包含更大的影像大小，並且透過電子郵件聊天，T:ANE 可能支援一個更大的影像大小，該大小將在預覽操作或 DLS 列表中使用。N3V Games 通常不會電報這樣的資訊。
- ↑ 早期的做法可以追溯到 Trainz 1.x，使用關鍵字/標籤 'thumb' 和一個用引號引起來的路徑規範引用，指向執行時選單的 240x180 縮圖影像。art 資料夾包含一個 512x512 的 tga 檔案，帶有一個 alpha 遮罩（通常是 bmp 檔案，但格式正確的 tga 可以用作自遮罩），以及 64x128 的選單圖示影像及其控制 texture.txt 檔案。
- ↑ 在 2014-2015 年冬季與前版本經理 James Moody 的私人電子郵件對話中，關於此主題，DLS 上傳審查軟體很可能已經改變，以強制執行正確的縮圖容器。
- ↑ 關於 category-era-nn 與 category-era 標籤值的說明： TRS 接受任何形式的 category-era 資料；但 TS2009-SP0 及其更高版本從以前合法關鍵字-值對中建立了錯誤，並試圖強迫內容建立者更改程式設計師故意破壞的所有資產。 後來，DLS 上傳軟體強制執行了轉換，但這更可接受，因為第一個操作會導致許多人為修復浪費大量時間，這些修復是多餘的，應該在稽核舊 trainz-build 資產時透過軟體預過濾過程自動執行。 這些操作實際上保證了舊資產下載將存在錯誤。 這是 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 程式碼 標準的更新資訊，這些標準在軟體新增功能時會發生變化。 |