跳轉到內容

Trainz/containers

來自華夏公益教科書
(重定向自 Trainz/Containers)
logo
Trainz 學員基礎知識

Trainz 資料元素簡介 - 2 容器
目錄 | 開始有趣 | AM&C | 建立 | 書中參考資料 ORP 參考資料:  • 索引 • 容器 • 種類 • 標籤 | 附錄  • 版本
 術語表
 HKeys-CM
 HKeys-DVR
 HKeys-SUR
 HKeys-WIN
 滑鼠使用
 符號

 

關於容器

[編輯 | 編輯原始碼]
有關 Trainz 容器的技術背景,請參見 Trainz/AM&C/containers.
此頁面列出了本華夏公益教科書涵蓋的特定 Trainz 容器的“參考頁面連結”,並在簡要介紹了它們在 Trainz 資料模型 中的作用之後。


容器 是 Trainz 對大於單個引數的資料的稱呼,單個引數通常在標籤中表示,但仍符合 Trainz 所有資料檔案強制使用的 ACS 文字格式。在此背景下,容器是複雜的 資料結構,包含多個元素 資料型別,在從處理軟體的角度正確定義的情況下,代表一個 R 值。對我們人類來說,它們實際上是相關標籤和值的集合,也符合 ACS 文字格式標準,而且它們代表了可重用的分組資料定義,這些定義是為了在多個 Trainz 種類 中重複使用而有意定義的。配置檔案和 KIND 在抽象意義上都是“合併容器”,但 KIND TBS 和 KIND 共同建立了一種獨特的容器型別和型別。

從某種意義上說,Trainz 資源不過是使用正確的 列舉程式碼 組織的資料集合,這些容器(包括被稱為 種類 的父類容器)定義了資源的相互關係和配置,以及數字模型在 GUI 執行時軟體(即 遊戲引擎)中的行為。容器只是資源自我定義中的一個元素,該定義由資源建立者初始化。

回憶一下初等數學

{X: A, B, C, ..., xx}讀作“合法值的集合 'X',它們是其中之一:有效資料值的列表。”



資料組織

[編輯 | 編輯原始碼]

所有 Trainz 資料都由關鍵字和值表示。容器 由一個唯一的列舉關鍵字 (識別符號) 識別,對於容器來說,成對的波浪括號 '{' and '}' 內的所有值在抽象意義上都是容器關鍵字的值。在內部,所有元素再次都是成對的值,通常又是關鍵字和值。 

在許多容器中(或者在實踐中,是子容器 - 請參見 縮圖 中的表單、格式和示例,瞭解一個經常出現的、易於理解的表示形式和示例),關鍵字實際上是變數(非列舉、未宣告、不受約束),通常按照約定用簡單的整數表示{X: 1, 2, 3, ..., nn}後面跟著空格和“值”,作為 config.txt 檔案中定義資料值的右側列。 

這些被稱為“虛擬引數”“虛擬關鍵字”,或者“偽關鍵字”,內容建立者可能很容易地使用{X: A, B, C, ..., xx}{X: throttle1, throttle2, throttle3, ..., tt},因為在這種情況下,事實上,在所有容器中,值(s) 被排序和組織,以填充記憶體中與 KIND 相關的物理地址,通常是 陣列 的一部分(參見 節流功率容器)或 列表(參見 縮圖容器 中的幾個示例)。

 

Trainz 華夏公益教科書容器

[編輯 | 編輯原始碼]

Trainz 華夏公益教科書和 N3V Games TrainzOnline wiki(或 Trainz Wiki)側重點和目的不同。TrainzOnline 頁面旨在作為內容建立者的技術規範和參考,以及傳達執行時軟體為使資源在 Trainz GUI 中正常執行所需的資料的方法。它作為內容定義的簡潔指南。

在這裡,在 Trainz 華夏公益教科書中,我們的重點是提供從入門到中級,有時到高階的知識,來傳授理解,幫助新的 Trainz 使用者和老使用者更詳細地瞭解 Trainz 的內幕。一家小型企業為了維持生計而苦苦掙扎的成本和人力限制了 Trainz Wiki,它必須具有權威性。我們在這裡努力做到同樣的準確性,但也力求更全面,因此,對於 Trainz 不斷發展過程中引入的一些變化,我們必然會有時間延遲。如果沒有這種變化,該產品將無法生存,雖然這使得它難以“趕上”,但也讓 Trainz 體驗不斷改進。 

如果我們認為某個主題需要額外的闡述,並且缺乏基礎知識的連貫構建,我們就會用更多資訊、解釋、示例來擴充 TrainzOnline Wiki 的頁面,並希望在 N3V 程式設計師(負責 Trainz Wiki)不希望使用更嚴格、更簡潔的寫作的地方,幫助理解。以下是迄今為止我們容器頁面的目錄。在目錄下面,您將看到 TrainzBaseSpec 中一些關鍵基礎知識的回顧。

容器目錄

[編輯 | 編輯原始碼]
[e]
KIND (資產型別組)
容器


作為TBS一部分的容器

[edit | edit source]
  1. 擴充套件容器, 擴充套件
  2. kuid 表格容器
  3. 成員組容器
  4. 過時表格容器
  5. 許可權容器
  6. 指令碼包含表格容器
  7. 縮圖容器, 縮圖容器

 

  • 上面列出的兩個連結中,第一個連結到一個關於容器型別的專用參考頁面,第二個連結到 TrainzBaseSpec (TrainzBaseSpec) 中涵蓋容器關鍵字(名稱)的部分。大多數以上鍊接將導航到 TBS 的相應部分。

不屬於 TBS 的容器

[edit | edit source]

這些是 Trainz 配置容器,不屬於 TrainzBaseSpec,但被多種 資源型別 使用。不屬於 TrainzBaseSpec 的容器是常態,而不是例外,因為容器被定義為多用途資料子組,用於 *自身定義* 多種 KINDs 的資源或資源的一部分。

  • 附加樣條線容器 -- 軌道型別 資源的可選並行樣條線定義,也就是說 Trainz 中任何自 TS2009 資料模型釋出以來完全更新的樣條線資源。
  • 轉向架容器 -- 在一些鐵路文化中也稱為“卡車”,Trainz 使用 bogeyNN 符號來表示車輪組在車架上的佈置位置,以及其他修飾符來調整、滑動或旋轉車輪組。轉向架容器是火車車廂類資源的固有部分。
  • 流量大小容器 -- Enginespec
  • 連線頂點容器 -- 連線頂點容器
  • 佇列容器 -- 工業和互動資源;該容器的定義用於裝載火車車廂,以及向工業設施解除安裝或裝載貨物。
  • 體積容器 -- Enginespec
  • 網格表格容器 -- 是任何“表現”資源的基礎,如果沒有網格,就沒有東西可以用紋理繪製,所以也就沒有東西可以看。
  • 季節選擇器容器 -- 在樣條線資源中新增用於多季節紋理改變(自 TB v2.9/TS2009 資料模型 以來都是 軌道型別 的變體),TS12(TB V3.5)中的新功能。
  • 煙霧容器 -- 最古老的容器型別之一。從水龍頭噴出的水流到鄉村小屋煙囪上的濃密松木煙柱,火車場周圍到處都是煙霧和蒸汽;半透明的薄霧狀物體可以製造出許多幾乎神奇的效果。有人喜歡用煙霧和鏡子來增強真實感嗎?這種容器在各種資源中都有應用。不止一個容器獲得了 NN 編號作為字尾,形成 smoke0、smoke1、smoke2、...、smokeNN,根據資源需要而定。煙霧也是互動的,並與軟體有各種介面,煙霧容器定義構成此類軟體連結的一部分。
  • 軌道LOD樹容器 -- TS2009 資料模型更改中新新增的功能,軌道LOD樹容器用於為在高解析度和低多邊形網格之間進行選擇提供決策引數。實際上,它經常被遞迴使用,為渲染軟體提供在 LOD 系列中的三個或多個網格之間進行選擇的能力。因此,它的主要功能是透過減少物體在距離越來越遠時所需的*多邊形計算量*來保持遊戲幀率,*無論是在近處、附近、更遠、中間還是遠處的距離*。

 


TBS 中的資源型別列表

[edit | edit source]

TrainzBaseSpec (TrainzBaseSpec) 是所有 Trainz 資料模型 標籤和容器的綜合列表,這些標籤和容器是 *強制的或可選的*,適用於任何和所有 Trainz 資源。下面回顧的部分列出了 Trainz 資料模型 中的 KINDs,並提供了與上面 TOC 相同的連結,或者連結到 N3V Wiki,以方便參考。

  • KINDs 是一種特殊的容器,因為它們的 defines 還包含偷偷潛入 config.txt 檔案中的標籤,因此似乎根本沒有包含任何東西。定義 kind 標籤 會使這種判斷處於危險之中 - 透過定義 kind,就好像程式設計師在高階語言中添加了一個包含檔案。在這種情況下,需要手動新增,而不是像真正的包含檔案那樣讀取文字。
  • 在 KIND 定義中是標籤的東西,也是配置檔案中的標籤。理解這一點,就成功了一半。


KINDs 的型別

[edit | edit source]

所有 Trainz 定義的資料(內容)都有三個必需元素:一個 config.txt 檔案 來組織資料,一個表示身份的 kuid(僅使用者名稱是不夠的,但合法的資源可以不使用名稱建立!),最後是一個合法定義的 kind 標籤。kind 負責一切,是管絃樂隊的指揮、排長或 CEO 下達命令——為 config.txt 檔案中處理後的所有內容設定需求。簡而言之,kinds 的值——一個由少量成員組成的緊密定義的排他性群體——告訴 Trainz 軟體要渲染和顯示我們在虛擬世界中建立的內容,以及如何在何處找到其他部分,這些部分需要在 config.txt 檔案中將資源的這些部分連結在一起。
  以下每個子類都被認為以 TrainzBaseSpec 作為其資料“父類”。[note 1] 下面列出的部分 kind,即帶下劃線的那些,是遺留 kind,早於 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 機車資產需要正確更新。

TrainzBaseSpec 子類 KIND(型別資產組)

 

 

註釋和腳註

[編輯 | 編輯原始碼]
  1. 注意: 此列表在 N3V TrainzOnline Wiki 上進行了“維基化”,這意味著單詞“KIND”之後的第一個字母已大寫,而 config.txt 檔案中的實際資料標籤名稱則全部為小寫文字。該維基也使用雙引號來表示很多術語,我們將在本文中省略這種做法。
  2. “kind consist” 並不經常直接出現,它基本上只存在於選單和內容管理器列表中。

 

華夏公益教科書