跳轉到內容

Trainz/型別

來自華夏公益教科書
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 列舉型別名稱””行所定義的
將這些計算機科學翻譯成英文:每個“型別標籤”都設定了 資源 的規則,以及提交到 Trainz 內容管理器進行 提交(現在奇怪地稱為 提交,因為 TANE 內容管理器出現了)或 驗證(錯誤檢查和測試,在將資源提交(或提交)到資料庫之前進行的步驟。 也是在上傳到 DLS 之前進行的步驟。 每個型別都與一個源 config.txt 檔案關聯,通常是其最前面的幾行之一[註釋 2]。 一切都是 TAG--DATA 對的一部分。 有些是 TAG-Container,很多是 TAG-Value,但所有配置資料都是成對的。 容器中的子容器遵循相同的規則。 即使是陣列資料元素 - 字串、多個值、多個可能性(類別時代和類別區域) - 也在一行中定義為成對關係。 因此,容器是關鍵字標籤,意味著期待“{”和“}”,並根據標籤名稱定義的規則處理它們之間的 data。

瞭解 KIND 的作用可以說僅略微不那麼重要,因為它瞭解 TrainzBaseSpec 的作用以及兩者無處不在的容器 config.txt 檔案的作用。 這三者都將在某個時間點,為該案例,成為使用者掌握以修復或建立資源最重要的資料元素。 幸運的是,每種型別的 Trainz 資源都有一個唯一的 KIND,因此這些可以根據需要或系統地逐一掌握,類似地,理解每個 容器 可以逐一進行。

事實上,這三個元素緊密相連,因為它們在資源 根資料夾 中協同工作,該資料夾 必須包含 配置,而配置反過來“必須”包含 TBS 中的型別標籤 和其他強制性 TBS 支援定義,如 kuid使用者名稱,以及從 TBS 行中定義和選擇的 KIND,因此“必須”包含該 型別標籤 所要求的那些定義,以及所有支援定義... 包括必需的容器和子容器。

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

在 Trainz 資料模型中定義資源


Trainz 型別是定義資源型別下最少資料結構的上層 容器,這些資源型別在一個唯一的標識 KUID 下。

層次結構和級別

[編輯 | 編輯原始碼]

KIND 在 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 的種類

[edit | edit source]

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

TrainzBaseSpec 子類 KIND(型別資產組)

 


重要日常KIND

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

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

場景 KIND

[編輯 | 編輯原始碼]

這些通常比較簡單,因此要介紹 KIND 的使用方式,

軌道 KIND

[編輯 | 編輯原始碼]

軌道旁 KIND

[編輯 | 編輯原始碼]

機車 KIND

[編輯 | 編輯原始碼]

發動機規格

[編輯 | 編輯原始碼]

kind engine

  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' 並不經常直接看到,它基本上只存在於選單和內容管理器列表中。

參考資料

[編輯 | 編輯原始碼]


華夏公益教科書