跳轉至內容

Trainz/種類

來自 Wikibooks,開放世界的開放書籍
logo
Trainz 培訓基礎

Trainz 註釋參考頁面
目錄 | 開始趣味 | AM&C | 創作 | 書內參考文獻 ORP 參考文獻:  • 索引 • 容器 • 種類 • 標籤 | 附錄  • 版本
 詞彙表
 HKeys-CM
 HKeys-DVR
 HKeys-SUR
 HKeys-WIN
 滑鼠使用
 符號

Kind 標籤

[編輯 | 編輯原始碼]
點選 此處快速導航到 KIND 的目錄

本地安裝資料庫之外定義 Trainz 資源的所有元素都包含在一個單個資料夾中——資原始檔夾資源原始檔夾——當資源分別開啟進行編輯或構建時,這兩個資料夾都可以訪問——都涉及(可能多種型別的編輯)編輯和資料操作。

 

種類是在這些資源原始檔夾中定義的特殊父資料形式,並在資料夾的唯一config.txt 檔案中定義。Kind 標籤的合法值受到嚴格限制。[註釋 1]每個配置都有一個種類,並且每個配置在本地定義的目錄中都有一個家,用於構建該資源。因此,資源原始檔夾也可以分類為高於 Trainz 容器的一般資料型別,並且每個都由其明確的唯一關鍵字指定型別控制,即Kind 標籤值。 

因此,每個 Kind 都表示在自定義的自包含 Trainz 資源定義層次結構中的一組基本的 Trainz 資源型別或資源種類資料類。內部的config.txt 檔案負責定義唯一 KIND 行的“資源型別”資料需求,並將 KIND 要求定義為必要的(或可選的)內容與 TBS設定的其他強制性和可選資源資料定義聚合在一起——實際上,配置的任務是定義父 KIND,將其他TrainzBaseSpec定義行所需的內容與父 KIND 行(種類“名稱”)值所需的定義行合併,以建立種類 KIND 型別的資源,如在 TBS 中設定“種類“KIND 列舉型別名稱””行所定義。
將計算機科學翻譯成英文:每個“Kind 標籤”都設定了 資源是什麼,以及其資原始檔夾在提交給 Trainz 內容管理器進行提交(現在,由於 TANE 內容管理器的出現,奇怪地稱為提交)或驗證(錯誤檢查和測試,在將資源提交(或提交)到資料庫之前的步驟。也在上傳到 DLS 之前。每個種類都與其源 config.txt 檔案配對(通常)作為其最開始的行之一[註釋 2]。所有內容都是 TAG--DATA 對的一部分。有些是 TAG-容器,許多是 TAG-值,但所有配置資料都是配對的。容器中的子容器遵循相同的規則。即使是陣列資料元素——字串、多個值、多種可能性(類別時代和類別區域)在一行上以配對關係定義。因此,容器是關鍵字標籤,表示預期“{”和“}”,並根據標籤名稱定義的規則處理兩者之間的資料。

理解 KIND 的作用可以說僅次於理解 TrainzBaseSpec 和包含這兩者的普遍容器 config.txt 檔案的作用。在某種情況下,這三者都是使用者在修復或建立資源時需要掌握的最重要的資料元素。幸運的是,每種 Trainz 資源都有一個唯一的 KIND,因此可以根據需要或系統地逐個掌握這些 KIND,類似地,可以逐個理解每個容器

事實上,所有這三個元素都緊密相連,因為它們在資源根資料夾中一起工作,該資料夾必須包含配置,而該配置又“必須”包含TBS 中的 Kind 標籤和其他強制性 TBS 支援定義,例如kuid使用者名稱,並且根據 TBS 行中定義和選擇的 KIND,“必須”因此包含該Kind 標籤和所有支援定義所需的所有定義……包括必需的容器和子容器。

在較小程度上,KIND 和類別類標籤一起告訴 內容管理器軟體在資源的config.txt 檔案中哪些其他關鍵字是必要的、可選的或非法的,而後者旨在將類別類成員(正在定義的資源)新增到各種排序標準的組合中,這些標準對 CM 的排序和選擇操作很有用。

在 Trainz 資料模型中定義資源


Trainz 種類是定義用於描述單個識別 kuid 下資源型別的最小資料結構的上層容器

層次結構和級別

[編輯 | 編輯原始碼]

KINDs 在 Trainz 模擬器中定義了屬性,這些屬性與類別-類設定一起構成必要的資訊欄位,以便正確渲染資產模型。從非常真實的意義上講,KIND 資料結構(將與模型渲染和執行時模擬需求相關的不同型別相關資料進行分組)是 Trainz 中的第一級容器(儘管它有一個特殊的名稱“KIND”),並且幾乎總是需要其他容器級資料組在 ini 檔案中與其一起使用。這些是列舉的支援容器和標籤,KIND 標籤和類別-類的列舉型別組合使用這些標籤和容器來確定必須為這種資產定義哪些其他資料元素,這可以被認為是子 KIND,因為所有類似的資產都需要定義相同的資料元素。

現在所有容器和類似容器的結構都位於 config.txt 檔案中,但區別僅僅在於“容器定義型別”通常在幾個不同的 KIND 定義的資產中具有作用域(適用性),並表示一個共享屬性(一個特徵,例如轉向架),而每個 KIND 對該類資產都是唯一的。KIND 機車和 KIND 貨車都具有轉向架(卡車上的車輪),因此兩者都在其 ini 檔案中都有一個轉向架容器。

在 Trainz 資料模型 II 中定義資產


下面的列表截至頁面撰寫時是完整的,並且會定期更新。請參閱Trainz-Wiki KIND TrainzBaseSpec以獲取可能的更新。(那裡下面的許多連結連線到 N3V TrainzOnline Wiki,並且這些連結與 Wikibook 部分連結之間存在細微的顏色差異。在 2014 年 8 月下旬,那些仍然是紅連結的連結尚未在 N3V Wiki 中正式定義,儘管該類可能已在內容建立者的論壇之一中推廣。)


KIND 的種類

[編輯 | 編輯原始碼]

所有 Trainz 定義的資料(內容)都包含三個必需元素:一個config.txt 檔案 用於組織資料,一個標識,即kuid(僅使用者名稱對您沒有用處,但是可以建立合法的資產而無需名稱!)以及最後,一個合法定義的 KIND 標籤。KIND 負責,是管絃樂隊的指揮,是排長或 CEO 發出指示——為處理後的一切設定要求。簡而言之,KIND 的值,一個小的、選擇的、嚴格定義的僅限成員的組——告訴 Trainz 軟體在虛擬世界中渲染和顯示什麼,以及如何(或在哪裡)找到使資產的那些部分連結在一起的其他部分在該 config.txt 檔案中。
以下每個子類都被認為具有TrainzBaseSpec作為其資料“父類”。[註釋 4]下面列出的一些 KIND,那些帶下劃線的 KIND,是早於Trainz 資料模型TS2009版本中(即 2008 年後期以來)更改的舊版 KIND,並且自那以後 N3V 程式設計師只施加了漸進的(增量的)更改。
目前,有關基於這些舊版 KIND 修復資產的詳細資訊可以在 N3V Trainz Wiki 的內容建立者指南部分TrainzOnline 網站此處找到,並提供有啟發性的舊版 KIND 示例此處。強烈建議Trainz 下載站的任何使用者或任何考慮建立內容的人員仔細閱讀 CCG。通過了解舊內容定義的背景歷史獲得的見解,然後可以與 TrainzOnline 對相同資料型別的當前覆蓋範圍進行對比和比較,因為通常這種過去與現在的對比可以為修復、更改和自定義資產提供寶貴的見解。更重要的是,CCG 中的寫作是專業製作的,並且更具同義反復性——它通常會讓您瞭解如果更改了這一點或那一點的擴充套件效果,而 Trainz Wiki 則沒有提供這些資訊。TrainzOnline 上釋出的 CCG 是TC1&2/TC3版本——最後出版的幾本小冊子,其出版日期可追溯到 1999 年的Trainz;TC3 CCG 包含來自 TRS2004/TRS2006 和UTC資料模型的已更改的 Enginespecs 機車資產,需要正確更新。

TrainzBaseSpec 子類 KIND(資產型別組)

 


重要的日常 KIND

[編輯 | 編輯原始碼]
本節將提供指向一組示例子頁面的連結,展示一個常見資產的演變過程
到 v1.3-v1.5、v2.2、v2.5、v2.9、v3.7、v3.9 等版本的 KIND 配置,或到其他活躍的資料模型發生變化的版本,可以使用檔案比較軟體檢視差異。
什麼是最重要的 KIND?

答案取決於您目前正在處理哪種資產和資產子型別。在人類的思維過程中,機車和貨車都是“火車車廂”(Kind "traincars"),但在 Trainz 配置檔案中則是不同的 KIND 宣告,而且柴油機車和蒸汽機車都需要定義不同的資料引數來模擬資產;這種配置中的差異來自kind的定義,而強制性的類別-分類標籤僅在CM勘探者選擇和排序過濾器中起作用。

景觀種類 (Scenery Kinds)

[編輯 | 編輯原始碼]

這些通常比較簡單,因此可以引入 KIND 的用法。

軌道種類 (Track Kinds)

[編輯 | 編輯原始碼]

路旁種類 (Trackside Kinds)

[編輯 | 編輯原始碼]

機車種類 (Locomotive Kinds)

[編輯 | 編輯原始碼]

引擎規格 (Enginespecs)

[編輯 | 編輯原始碼]

kind engine

註釋 (Notes)

[編輯 | 編輯原始碼]
  1. KIND 和許多其他 Trainz 資料定義,雖然範圍廣泛,但都是列舉資料型別……這意味著它們必須是從允許的單詞列表中選取的 <值>。其他都不適用!
  2. 配置檔案中所有標籤和容器的位置實際上並不重要,除了資料結構在引號、方括號和圓括號中的正確巢狀。
  3. 雖然 N3V 程式設計師沒有正式承認(我在任何地方都沒有看到),但LOD 檔案[1](例如 'meshname.LM.txt' 和filespec.texture.txt 檔案)可以被認為是ini 檔案型別或包含檔案型別,實際上擴充套件了配置檔案中內聯定義。(texture.txt 檔案 + LM.txt 檔案) 每個檔案不僅包含路徑資訊,還包含必要的如何實現資料指令行,並且與 config.txt 檔案行一樣,必須採用正確的格式,否則資產將生成錯誤。
     • config.txt 檔案和此類包含檔案之間的一個關鍵區別在於,它們並不嚴格遵循 Trainz關鍵字—<值>對在一行上的格式,而是經常在其語法中使用等號。
  4. 注意:此列表在 N3V TrainzOnline Wiki 上被“維基化”,這意味著在“KIND”一詞之後首字母已大寫,而配置檔案中實際的資料標籤名稱則是全部小寫文字。該維基在相當多的術語中也使用了雙引號,我們將在本文中避免這種情況。
  5. 'kind consist' 並不經常直接看到,它只存在於選單和內容管理器列表中。

參考文獻 (References)

[編輯 | 編輯原始碼]


華夏公益教科書