Trainz/refs/TrainzBaseSpec
(重定向自 Trainz/refs/thumbnails)
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] 與過去的日子相比，這是一個更好的煩惱，在過去的日子裡，有缺陷的資源定義有時會導致臭名昭著的“藍色畫面宕機”或更常見的情況是，將執行時軟體崩潰回桌面，導致編輯丟失，並且可能需要重建資料庫。
所有 Trainz 定義的資料（內容）都包含三個必需的元素：一個config.txt 檔案 用於組織資料，一個身份，即一個kuid（僅使用者名稱對你沒有任何幫助，但是一個合法的資源可以在沒有名稱的情況下建立！），最後，一個合法定義的種類標籤。種類負責，指揮樂隊的指揮，排長或 CEO 下達指示 - 為所有之後被處理的東西設定要求。簡而言之，種類的值，一個小型精選的嚴格定義的會員專用組 - 告訴 Trainz 軟體要渲染和顯示在我們建立的虛擬世界中的內容，以及如何（或在哪裡）找到用於將資源的這些部分連結在一起的配置檔案中所需的其他部分。
以下每個子類都被認為具有TrainzBaseSpec 作為其“父類”資料。[註釋 3] 下面列出的一些種類，那些帶下劃線的種類，是早於Trainz 資料模型在TS2009（即 2008 年末以來）版本中更改的遺留種類，N3V 程式設計師只對這些更改進行了漸進的（增量）更改。
目前可以在 N3V Trainz Wiki 的內容建立者指南 部分找到基於這些遺留種類的修復資源的詳細資訊TrainzOnline 網站，並提供有啟發性的遺留種類的示例。強烈建議所有使用Trainz 下載站或考慮建立內容的使用者仔細閱讀 CCG。瞭解如何定義舊內容的背景歷史的見解可以與當前 TrainzOnline 對相同資料型別的覆蓋內容進行對比和比較，因為這種以前與現在的對比通常可以提供寶貴的見解來修復、更改和定製資源。更重要的是，CCG 在 TrainzOnline 上釋出的是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-table (容器) { 依賴項列表 |
一個鍵值表，列出了此資源所依賴的所有資源。 |
| obsolete-table (容器) { } |
kuids 列出了此資源所替換（使之過時）的資源 通常為空（空）[註釋 5] |
| string-table (容器) { } |
字串和訊息的鍵值列表，在資源中使用 通常為空，在路線和場景中較大。 |
| string-table (容器[s]) { 非英語 語言文字 } |
翻譯字串列表，匹配 強制性的英語 string-table |
| 類別-區域 標籤 列舉 程式碼 | 類別-區域 "'字串陣列'" |
| 類別-分類 標籤 | 類別-分類 "'列舉 字串值'" |
| 類別-時代 標籤 | 類別-時代 "'受限字串陣列'" 年代 |
| 類別-關鍵字 "'字串陣列'" 最大長度為 64 位元組 | 類別-關鍵字 標籤 自然語言搜尋關鍵字 (替換型別，區域) |
| 自定義-類別-列表 "'字串陣列'" |
指令碼介面功能 |
| 必須擁有產品權利 "'字串值'" |
DRM 字串陣列 |
| 不能擁有產品權利 "'字串值'" |
DRM 字串陣列 |
| 許可權 (容器) { } |
更多 DRM |
| 縮圖 (容器) { } |
縮圖容器 |
| 指令碼 (檔名) | "'字串值'" |
| 類 (指令碼資源類) | "'字串值'", 必須與 指令碼 規範類同步。 |
| script-include-table { } |
(列出庫指令碼的容器) |
| 擴充套件 (容器) { } |
資產也使用的正式指令碼擴充套件 |
| 許可 "'字串值'" | 資源建立者的版權宣告 |
| 作者 | "身份 '字串值'" |
| 組織 | "第三方組身份 '字串值'" |
| 聯絡郵箱 | "電子郵件地址 '字串值'" |
| 聯絡網站 | "作者/組的網站 url '字串值'" |
| 所屬組 (容器) { } |
此資源所屬的 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 程式碼 相匹配，CM Trainz-build 程式碼識別軟體技術級別，但它表明了以前版本的歷史。
- 在資料庫中存在這兩種資源的情況下，具有更高字尾程式碼的資源會覆蓋或替換舊的資源。擁有早期版本並非必需，但 CM 會將缺失的修訂鏈列為缺失的依賴項，對於那些反感 CM 中這種汙染的軟體錯誤的人來說，或者對於那些仍然堅持程式設計師保留這種“功能”的人來說，從任何角度來看，都降低了使用 CM 來識別使用者缺少什麼的實用性，並導致使用者花費時間手動弄清楚到底是什麼是什麼。
- 主要涵蓋：trainz-build 標籤，縮寫：TB & TBV (TB-值)∅
- 型別：帶有小數點的小數，由 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 在經過數小時的挖掘和研究後，更可能的原因是 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。
- 型別：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 字串列表容器，String-table 容器.
- 欄位定義：英文字串的鍵值對列表。每個鍵都是一個有意義的指令碼識別符號，對映到二進位制資料並被二進位制資料引用。每個值都是一個英文字串。英文字串可以包含或引用非英語專有名詞作為識別符號。非英語母語的作者必須在需要時建立沒有後綴的 string-table 容器。軟體只連結到和引用 string-table 容器中沒有後綴的名稱和值，這會導致西班牙語、法語、德語、捷克語、荷蘭語……日語作者感到厭煩。換句話說，帶字尾的 string-table 僅用於翻譯目的，這在以非英語編寫的 map 時會造成問題——沒有 string-table-en 來提供用於反向翻譯的表。同樣，username-en 和 description-en 也是如此。所有三個缺失都體現了一種過時的和傲慢無禮的態度，對世界動態缺乏敏感性。
其他語言透過類似的 string-table（例如 string-table-XX）支援，帶有與描述和使用者名稱關鍵字/標籤的國際化字尾匹配的本地化程式碼字尾 (XX)，但這些語言鍵控的 string-table 容器始終具有相同的左手條目中的鍵值對。
- 這些左手鍵或標籤既用作“本地索引關鍵字”，又用作“語言之間的等效表”。
- 左側欄將始終包含內容建立者提供的“特殊”名稱的物件，例如訊號、軌跡標記和行業、連線點等的名稱，這些名稱可能被引用，並且將出現在駕駛員和測量員模組的“查詢公用設施”（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 和字串表。特別是，與版本捆綁在一起的路線和會話會收到針對每個零售版本的專業翻譯成多種語言。
請注意，字串表的左側是相同的，因為它是一個對映的符號表，並索引到二進位制資料，如網格、會話或路線檔案。只有使用名稱，即兩個元素中的右側或資料元素，才是本地化的，並由執行時本地化軟體替換。如果需要，這些名稱可以在英語字串表中手動編輯，以獲得更友好的名稱。索引或左側引用列語法不得以任何方式更改，因此在資料列中更改名稱時，請謹慎使用全域性 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 列表容器，與obsolete-table 容器（在下文）格式相同。一個虛擬引數 + 一個（依賴）kuid
- 欄位定義： 界定此資產所依賴的資產列表的鍵值。
- 通常
- 只有具有子元件或具有替代選擇（貨物）的資產才會具有長度可觀的 kuid-table。大多數具有子元件的資產只有幾個。
- 其次，存在一個慣例，源於有時內部關鍵字是“自動定義”的——僅僅列為一個沒有名稱的數字，作為佔位符引數，偽關鍵字可以是任何唯一值（通常是零索引的連續整數。[notes 1]）可以給它們命名也可以不命名，使用者或作者可以隨意選擇。
- 此表中的條目有兩個目的
首先：確保遊戲系統知道依賴關係，以便安裝和載入此資產會成功安裝和載入任何依賴關係，並且
其次：允許指令碼找到相關的子資產。 - 在 kuid-table 中只包含一級依賴關係——具有自身依賴關係的子級或部件資產在該子級資產的驗證和資料庫提交過程中進行處理。
- 迴圈依賴關係是非法的。
- 如果某個資產也被標記為此資產的過時版本，則該資產不能被列為依賴關係。（Trainz 資產索引（歷史上為 assets.tdx 檔案）中只有一個替換 kuid 槽位，這將建立一個迴圈定義，需要它自己的舊版本！）
- 類似地，某個資產不能被列為它自己的依賴關係。[另一方面，這已經被體驗過（即在 TSxx CM 中被證實為一個成功提交的無故障資產）在安裝之間移植地圖和會話，使用 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-table 容器 格式相同。
- 欄位定義: 一個“佔位符鍵-鍵值”列表，表示被此資源標記為廢棄的資源。任何嘗試載入此列表中的任何資源都將導致載入此資源。
- 此外: 兩個資源均標記第三個資源為廢棄是非法的，除非這兩個資源中的一個也標記另一個為廢棄。[注 6]
- 迴圈廢棄引用是非法的。
- 此資源的所有較低編號的 KUID2 版本都隱含地被標記為廢棄，無需包含在此列表中。同時，較新的改進資源（具有較高的 Kuid2）及其祖先之一不應將同一個祖先（例如原始資源！）列入“中間”祖先列表中，因為這些值用作替代條目表，並且只能用一個資源替換較早的版本。（陣列只儲存一個值，不能用兩個值替換一個值！）
- 將此資源的較高編號的 KUID2 版本標記為廢棄是非法的，因為這會建立一個隱式迴圈引用。
- 此列表中引用的資源必須與此資源具有相同的建立者，才能透過 DLS 上傳流程進行稽核和接受，此限制在您的本地版本中不適用，例如，它可以用來用一個更美觀且更新的資源替換一組大型火車車廂上的所有舊紙質車輪 kuids。
- 用途: 在 CM 和 Surveyor 中進行過濾（搜尋條件）
- 型別: 列舉字串或字串陣列。
- 欄位定義: 一個由分號 (;) 分隔的雙字元 類別-區域標籤 程式碼列表。字串中不應出現其他字元（包括空格等）。此資源被認為與每個指定的區域相關 - 這對 kind 火車車廂 和 kind 移動訊號 資源最為重要，但可以為任何資源提供。
- 示例
- 類別-區域 "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"
}
}
另一個常見的大小是 調車場 和 surveyor 資源選擇 API 中使用的 128x64“圖示”，它應該有一個 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 熱修復程式刪除了這種做法。
• 如果缺少縮圖容器的資產（即使有過時的縮圖標籤）後來在一個新的內建路線或會話中被選擇，該資產通常會被分發為沒有影像的專案——如果紋理 .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 連結，並且僅在嵌入式 Web 瀏覽器中有效，而不在任何外部 Web 瀏覽器中有效。當此標籤存在時，遊戲內按鈕將允許使用者檢視資產描述或幫助，而無需離開遊戲環境。
這對於駕駛員在訪問路線圖、指南或會話說明或澄清時可能非常有價值。
建議在任何情況下使用通用組頁面來表示所有型別的資產，這些資產提供類似的功能，但外觀略有不同。這減少了建立、維護和本地化此類文件的時間成本。
- 型別: ASCII 字串。
- 欄位定義:所需的產品權利列表，以分號 (;) 分隔。如果本地安裝沒有所需的產品權利，則某些遊戲系統可能無法載入資產。
- 型別: ASCII 字串。
- 欄位定義:衝突的產品權利列表，以分號 (;) 分隔。如果本地安裝具有其中一個列出的產品權利，則某些遊戲系統可能無法載入資產。
- 型別: privileges 容器 是某些作者使用的 DRM，版權保護實現，也可以稱為 privileges 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.
- 相關
extensions 容器是具有特定命名約定的自定義標籤或子容器列表。
此容器是指令碼資產名稱及其 KUID 的簡單鍵值表，在編譯資產的指令碼檔案時搜尋指令碼包含。鍵或標籤名稱目前未使用（即，是一個 佔位符引數）在搜尋中；值表示要包含的資產的 KUID。能夠搜尋和識別鍵名稱是內容建立者請求的功能，因此建議使用指令碼檔名而不是數字虛擬標籤名稱作為最佳實踐，因為它比 KUID 引用傳達的資訊更多。
通常最好將此類引用限制為 KIND 庫 資產，但這並非強制性，可以引用任何資產。
script-include-table {
a-key <kuid:nnnn:nnnnn>
enginespec <kuid2:www:xxxxx:yy>
anim-doors <kuid:tttt:uuuuuu>
}
- 型別: Extensions 容器。
- 欄位定義： 一組擴充套件屬性，為指令碼提供超出此資產型別定義的 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 容器，配對的 佔位符引數 和 資產組 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 標籤的。
- “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 中的單行上[註釋 12]。雖然在 Surveyor 中無法直接訪問，但在 TR06 和 CMP 之後，可以定義一個過濾器來選擇日期範圍，並將該過濾器與區域和型別一起用於 Surveyor，以驗證 Surveyor 的放置和選擇工具中可以列出的資產。在 TS09 及之後版本中已過時，TS09 使用更短的category-era 標籤 字串陣列 放在單行中，而不是使用多個帶有“ -nn”字尾的標籤-值對。
- 字串陣列中的空格會導致錯誤；所有值都必須以“s”為字尾，並具有四位數字，例如 1880s;1950s;2010s（這可能完全適合某些型別的女性服裝，這些服裝會流行起來然後又過時！）。不幸的是，目前無法定義範圍，但使用者社群已經提出了要求。
- 用字串陣列型別的category-era 標籤 替換，標籤之間沒有空格，並使用分號分隔；這些標籤是完整的四位數字年代數字，後跟“s”（小寫 s）字尾。
- 型別 category-region-nn — V1.3–v2.8 —在歷史上幾乎所有值得標註位置的資產中都發現。這些標籤已被category-region 標籤中的“字串陣列”中的兩位字母列舉 ISO 國家程式碼 取代。
- 用字串陣列型別替換 category-region，兩個字元的國家程式碼之間沒有空格和分號，這些程式碼在引用的標記部分中列出；這些程式碼以完整的兩個大寫字母的形式給出，包括 列舉 程式碼，後面跟著程式碼之間的 ';' 分隔符，但在最後一個程式碼之前的末尾引號之前沒有分隔符。
- 字串陣列中的任何 空格 都會導致讀取錯誤和錯誤訊息，包括結尾引號之前的空格。
- region —TBS V1.3–v2.8 中有效的內建過濾器和地圖資源自定義本地化識別符號 (kuid) 部分；現在唯一合法的標記用途是在 kind map（佈局）資源中。
- 作為以前的過濾器修飾符，該標記在歷史上幾乎所有資源中都存在，但它在滾動庫存、場景、樣條線資源、軌道型別（包括隧道和橋樑）以及具有某種程度的本地化的路邊資源中尤為普遍。
- 地圖資源仍然保留關鍵字 Region，該關鍵字在 Map 配置檔案中定義，但使用方式相反——作為 kind region kuid 引用。因此，Region 在 Maps 中是必需的，並且自 TS2012 以來，與標記型別一樣，它在大量曾經作為 TRS 系列版本 Surveyor 工具視窗的“分組資料” “快速過濾器”出現的資源中是非法的。
- 任何區域標記到文字字串在 TRS2009 之後都已過時，因為在程式設計師看來，他們用 Pick List 替換了 Surveyor 工具中“型別和區域”字串值的粗略過濾組選擇器。這兩個標記都有一些優點和缺點，而且都可追溯到 Trainz 0.9 Beta 版本。
陰影標記
[edit | edit source]- 參見上面的彎曲，已棄用/過時的 pre-TS2009 遺留 kind track 資源模式控制標記。
縮圖標記
[edit | edit source]縮圖標記是 縮圖容器 的早期單檢視實現（上面也有簡要說明）。Trainz 的早期 pre-N3V 程式設計師版本會在主資源根資料夾或資源名稱_art 或資源名稱_body 資料夾中找到一個 .jpg 檔案，最好大小為 240x180 畫素，並使用它在 CMP 和 DLS 中顯示資源（如果它被上傳）。該標記在 TRS2006 期間被棄用，因為縮圖容器是在 v2.0（TRS2004-SP0）中引入的。在舊的已修復資源中，如果 TBV 保持在 v2.4 以下，則縮圖通常仍然可以在較新的 CM 中正常工作，前提是它位於 _art 子資料夾中，並且資源名稱與使用者名稱匹配。
型別標記
[edit | edit source]- type — V1.3–v2.8 —以前的過濾器修飾符，在歷史上幾乎所有資源中都存在，但它在滾動庫存、場景、樣條線、軌道型別（包括隧道和橋樑）以及路邊資源中尤為普遍。
- 型別標記與“區域標記”一樣，在 Trainz 0.9—TC3 版本中用作“在 Surveyor 中的組過濾器”，它與區域結合，提供更小的資源選擇（工具組）。自 TS2009 以來，刪除了這些本地可點選過濾器功能及其使用，轉而採用一種新的、更繁瑣的過濾器。這些使得工具選擇變得快速簡便，而不是在工具選項卡之間切換時變慢並暫停——如今的 pre-TANE 版本在工具選項卡之間來回切換時，通常會因重新載入整個選擇列表而感到不堪重負。
- 型別和區域都預設為“全部”，提供與 TS09 及其後的工具相同的超級列表。
備註
[edit | edit source]- ↑ 資源 提交（TANE 的提交）是指將內容合併到資料庫中並在 DB 索引中進行交叉引用的過程和步驟，以便它可以在執行時模組中被訪問。
- ↑ 驗證資源的一種方法是降低 TBV 到 2.5-3.7 範圍，看看這些訊息是否消失。您可能需要進行幾次嘗試，直到降低到足夠低的水平，反之亦然，在較舊的 TBV 中無法識別的較新的關鍵字可能會給出不同的錯誤訊息。但是不要害怕嘗試——即使失敗也能帶來知識和經驗，而且您不會破壞任何東西！如果是這樣，您可以確信，提供一個值就是解決問題的辦法。通常，一些現代需求只需要關鍵字對，因此在標記後面新增一個空白行或在標記後面新增一個空的花括號集就可以滿足需求，而錯誤測試則過於嚴格。
- ↑ 注意：此列表在 N3V TrainzOnline Wiki 上“維基化”，這意味著在“KIND”一詞之後，第一個字母已大寫，而 config.txt 檔案中的實際資料標記名稱是全部小寫文字。該維基在許多術語中也使用雙引號，我們將在本文中免除您體驗這種做法。
- ↑ “kind consist” 並不經常直接看到，它只存在於選單和內容管理器列表中。
- ↑ 必須謹慎使用過時表格，它最常出現在 Auran 編寫的資源中。該表格用更新的版本替換了舊的 kuid，大多數內容建立者正確地使用 kuid 的 Kuid2 形式來取代舊版本。相比之下，N3V 過度使用過時表格來更新新版本“升級”的內建資源，這會導致很多混淆，並且無法獲得預期的結果。（例如，許多漂亮的“Flip-trees”在 TS10 和 TS12 中被 Speedtrees 取代，影響了許多路線，而建立者不希望也不需要 Speedtrees。在不同的安裝中，這也會導致依賴關係缺失，直到找到包含過時表格的資源。
• 此外，Assets.tdx 資料庫索引中每個 kuid 只支援一個過時條目，用 Kuid2 版本取代 kuid 會導致問題（即，您將看到哪個？）。
• 過時表格的一個很好的用途是使用特定部件（尤其是轉向架）升級一系列資源。新增一組被更新的優質轉向架取代的 kuid 可以透過一次編輯顯著改善路線或會話的外觀（前提是轉向架（例如）相容且尺寸正確！）。 - ↑ 最近將過時資源引入 TANE 的經驗表明，至少有五個替代 kuid 取代了那臺可憐的 Flip-tree 資源。看來，由於 Speedtrees 的引入以及 TANE 大力追求最合適的更新資源所帶來的混淆，現在內容管理器流程中允許存在多個取代相同 kuid 的不同 kuid 資源。作為一個良好的做法，僅在絕對必要時使用過時表格……例如，用您想上傳到 DLS 或自行釋出到網站的依賴資源中的不希望的付費資源來取代該資源。
- ↑ 關於 category-era 標記範圍：安全玩法，已知有效。其他“未來十年”值應在依賴於這些值之前進行測試。
- ↑ 許多容器在列表中使用虛擬/佔位符名稱。這些可以是描述性詞語，只要它們不包含空格字元即可。在短語構造的名稱中使用下劃線或句點可以保持可讀性並大大提高畫質晰度。例如，一輛貨運車廂可能承載 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 的選單圖示影像及其控制紋理。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。增強的資訊由 Yesterdayz-Trainz 使用者組的成員新增。
腳註
[edit | edit source]- ↑ N3V 的 KIND_TrainzBaseSpec，作為未增強的源頁面，缺少此處找到的歷史資訊（標籤）；accessdate=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 程式碼標準的更新資訊，這些標準隨著軟體功能的新增而不斷變化。 |