跳轉到內容

Trainz/種類

來自華夏公益教科書,開放世界開放書籍
(重定向自 Trainz/KIND)
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-Container,很多是 TAG-Value,但所有配置資料都是成對的。容器中的子容器遵循相同的規則。即使是陣列資料元素——字串、多個值、多種可能性(類別時代和類別區域)都在一行上以成對關係定義。因此,容器是關鍵字標籤,表示預期“{”和“}”,並按標籤名稱定義的規則處理兩者之間的資料。

理解 KIND 的作用,可以說僅略微不比理解 TrainzBaseSpec 的作用和包含這兩者的無處不在的容器 config.txt 檔案的作用重要。所有這三種元素在某一時刻都是對使用者來說最重要的資料元素,以便修復或建立資產。幸運的是,每種 Trainz 資產都有一個獨特的 KIND,因此可以根據需要或系統地逐個掌握它們,同樣,可以逐個理解每個 容器

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

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

在 Trainz 資料模型中定義資產


Trainz 種類是定義最小資料結構的上層 容器,用於在單個標識 kuid 下表徵資產型別。

層次結構和級別

[編輯 | 編輯原始碼]

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

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

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


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


KIND 的種類

[edit | edit source]

所有 Trainz 定義的資料(內容)都具有三個必需元素:一個 config.txt 檔案 來組織資料,一個標識,即 kuid(僅使用者名稱是不夠的,但是合法資產可以在沒有名稱的情況下建立!),以及最後,一個合法定義的種類標籤。種類是負責的,是樂團的指揮,是排長或 CEO 指示 - 為所有在之後進行處理的內容設定要求。簡而言之,種類的值 - 一個由少數嚴格定義的成員組成的封閉團體 - 告訴 Trainz 軟體要渲染和顯示在我們建立的虛擬世界中的內容,以及如何(或在哪裡)找到在該 config.txt 檔案中將這些資產部分連結在一起所需的其餘部分。
  下面的所有子類都被認為具有 TrainzBaseSpec 作為其資料的“父類”。[註釋 4] 以下列出的幾種種類,那些帶下劃線的種類,是早於 Trainz 資料模型TS2009 釋出(即 2008 年底以來)的更改的遺留種類,N3V 程式設計師僅從那時起實施了漸進式(增量式)更改。
  基於這些遺留種類的資產修復細節目前可以在 N3V Trainz Wiki 的 內容建立者指南 部分找到 TrainzOnline 網站在這裡,其中有啟發性的 遺留種類的示例在這裡。強烈建議所有 Trainz 下載站 使用者或考慮建立內容的任何人都仔細閱讀 CCG。從瞭解如何定義舊內容的背景歷史中獲得的見解,可以與 TrainzOnline 對相同資料型別的當前報道進行對比和比較,因為這種過去與現在的對比通常可以為修復、更改和自定義資產提供寶貴的見解。更重要的是,CCG 在 TrainzOnline 上釋出的版本是 TC1&2/TC3 版本 - 這是自 1999 年 Trainz 以來出版的幾本小冊子中的最新版本;TC3 CCG 包含來自 TRS2004/TRS2006 和 UTC 資料模型的已更改的 Enginespecs 機車資產,需要進行適當的更新。

TrainzBaseSpec 子類 KIND(型別資產組)

 


重要的日常 KIND

[edit | edit source]
本節提供指向一組示例子頁面的連結,這些頁面顯示了通用資產的演變
到種類配置,從 v1.3-v1.5、v2.2、v2.5、v2.9、v3.7、v3.9 或其他版本,在這些版本中,活動的 資料模型 發生了變化,可以使用 檔案比較軟體 檢視這些差異。
最重要的 KIND 是什麼?

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

景觀種類

[編輯 | 編輯原始碼]

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

軌道 KIND

[編輯 | 編輯原始碼]

軌道旁 KIND

[編輯 | 編輯原始碼]

機車 KIND

[編輯 | 編輯原始碼]

發動機規格

[編輯 | 編輯原始碼]

KIND 引擎

  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”一詞之後首字母已大寫,而 config.txt 檔案中實際的資料標籤名稱都是小寫文字。該維基還使用雙引號來表示很多術語,在這裡我們將避免使用雙引號。
  5. 'KIND consist' 並不常直接看到,它只存在於選單和內容管理器列表中。

參考資料

[編輯 | 編輯原始碼]


華夏公益教科書