跳轉到內容

Trainz/refs/config.txt 檔案

來自 Wikibooks,開放世界開放書籍
logo
中級和高階內容建立

Trainz 資產維護和建立
TOC | 開始有趣 | AM&C | 建立 | 書內參考文獻 ORP 參考文獻:  • 索引 • 容器 • 種類 • 標籤 | 附錄  • 版本

這是對 Trainz ini 檔案 型別(稱為 config.txt 檔案)的更技術性的介紹。

有關主題的介紹,請參見:Trainz/Config.txt files,有關一般基礎知識的構建,請參見 Trainz/AM&C/config.txt files

無論 Trainz 釋出版本如何,特定版本的 Trainz 資料模型 始終具有 KIND 資料容器,它位於 config.txt 檔案中,並具有 kuid 標識碼,作為 Trainz 內容專案的最小中央描述需求。這使得特定資產資料夾中的 config.txt 檔案成為任何給定資產的中央描述;為了使模型更加緊湊,配置檔案在資料庫中定義了它所在資料夾的名稱,而不是用於編輯。

每個內容專案在其資料夾中都有一個名為 config.txt 的定義檔案,它確定資產的名稱,識別其種類,並指定KUID ID 程式碼,唯一地允許從資產到資產或到執行時軟體進行資料匹配和引用。每個配置檔案,取決於資產 KIND,還將儲存各種特定於種類的詳細資訊,這些資訊定義了該資產以及允許在使用相同資產的多個例項(例項)執行 GUI 時出現多次的任何鍵。(樹木、火車車廂、房屋等——其中許多都半自定義,帶有指令碼影響,例如隨機車號、替代皮膚、標籤和其他會話編寫器定義的特性。)


config.txt 檔案在很大程度上所有文字格式的 Trainz 檔案型別)儲存在 ACS 文字格式 中,簡而言之,它定義了關鍵字和值配對。一些關鍵字是聚合值,在 Trainz 中,對應於一個 容器,該容器包含此類資料對列表和其他容器。

  • 在手動編輯檔案時,必須注意使用正確的語法,否則檔案部分或全部內容的意義可能會永久丟失。當內容安裝到 Trainz 中,或者當它被存檔(在 CDP 格式 或類似的 .cdpa 檔案格式中)時,config.txt 檔案將儲存在機器最佳化的二進位制格式中。如果內容隨後使用 內容管理器 提取,則 config.txt 檔案將轉換回文字格式,但是任何自定義格式或錯誤語法都已丟失,無法恢復。

TBS 標準標籤

[編輯 | 編輯原始碼]
主要文章:TrainzBaseSpec

Trainz 數字模型基於資料定義,所有資料定義都遵循一種格式,其中列舉的標籤關鍵字引導一行,並在同一行後面跟著資料配對。在某些更復雜的資料允許的情況下,資料元素剛剛開始——一個引號設定了資料或一個開括號 '{',它設定了其他特定的關鍵字——資料配對。即使是複雜的容器,有些帶有子容器也遵循這種要求的格式。從這個意義上講,容器和子容器都包含一個用匹配的括號括起來幷包含在其中的標籤和值集,這是一種來自 C 程式語言的約定。 

請注意,這種複雜的資料定義在子程式資料處理級別是有意義的,因為標籤一旦被識別,就會被用來選擇適當的處理子程式(在計算中,一個處理程式例程),它輸入行(或多行)的其餘部分,知道如何解釋在第一個 '{'(或引號字形)之後包含的資料,直到它遇到匹配的閉括號 '}'(或結束引號 '")。的 種類 資料子型別定義了該資產在遊戲引擎中正確渲染所需的唯一配對。  相反,各種標籤和容器在法律上可供所有 Trainz 內容定義種類使用,在該種類資產的 config.txt 檔案中是合法的,無論具體的資產型別是什麼。為了方便起見,自從 TS2009 釋出和 TrainzOnline Wiki 的誕生以來,這組資料關鍵字和通常強制性的資料定義被稱為Trainz 基礎規範(TBS),在程式設計師的 (駝峰式) 行話 中變成了TrainzBaseSpec 規範——一個始終合法的標籤、容器及其必要定義的列表。
 • 合法性不涉及您當地的法律機構,而是涉及內容管理器核心和 DLS 錯誤檢查軟體例程中的警察。如果標籤-值對超出上下文,例如子容器標籤放置在容器邊界之外,或者不合適,那麼“警察”會生成錯誤訊息和投訴(“起訴書!”),並將資產標記為故障... 使其無法使用,直到修復(至少在後來的 Trainz 版本中——早期版本更寬容)。因此,各種配置檔案標籤,既有必需的標籤,也有可選的標籤,都是從 kind trainzbasespec 基本資產型別繼承的,並且在其中進行了詳細描述。這些值型別是

標籤 或單個行開頭詞是'關鍵字',並且具有一個單個分配的 '鍵值' ,一個正確格式化的容器資料結構,或者有時該鍵值需要被組織為一個帶引號的字串陣列(實際上,一個容器,用於定義該特定標籤型別的引數),通常是受限的編碼值(列舉列表成員),透過引號字形之間用分號分隔,定義單個字串(一個字串值)對於該標籤。(示例:"CA;MX;US" 是一個 類別-區域 定義,涵蓋整個北美——加拿大、墨西哥和美國

容器 是關鍵字和鍵值對以及可能存在的子容器的集合。上層容器(與子容器相反,例如縮圖容器內的子容器)是 KIND 規範(包括 KIND TBS)的一部分,是高使用容器,特別是那些可能採用可變數量的子容器元素的容器,例如 網格表容器 通常以“ -table”為字尾。

最後,也是最重要的一點,有 各種 型別(見下面的第二個表格或 TBS 中的列表),每個配置檔案都對應一個 config.txt 檔案,該檔案定義了其他關鍵字,包括強制性關鍵字和可選關鍵字 滿足該型別資產的任何定義所需的。因此,每個型別資料組都擴充套件了必需和可選引數、標籤和容器,這些引數、標籤和容器必須在該 config.txt 檔案中詳細定義,以便正確地將所有用於建立數字模型(Trainz 資產)的元素組合在一起。請注意,型別是定義其他容器和其他特定標籤的容器,這些標籤必須在 內容管理器 的錯誤檢查中得到滿意地定義,以接受(並 提交)資產到資料庫中。如果數字模型不在資料庫中,則內容創作者無法在製作場景或地圖時顯示和使用它。

表 1 中的鍵可在任何 config.txt 檔案中找到。

[編輯 | 編輯原始碼]
以下表格 正式稱為'Trainz 基礎規範TrainzBaseSpec (TBS). TBS 包含 Trainz 資料模型規範的 關鍵字和鍵值對,這些規範可能在任何資產中找到。其他標籤和值由 型別 標籤的值定義,該值列在 型別表 中。
  1. 在缺少這些標籤的 config.txt 檔案中新增任何一個標籤都不會導致問題,只要您的語法(輸入和拼寫)正確無誤。
  2. 字尾為 -XX 的標籤是支援多種語言的非英語語言支援。字尾源於 ISO 標準縮略詞列表,但通常是直接的。例如:-it 表示義大利語,-fr 表示法語,-cz 表示捷克語,-de 表示德語,-es 表示西班牙語,等等。
  型別     "'字串值'"
  trainz-build '浮點數', 1 位小數
  kuid   <Kuid 編碼值>
  使用者名稱     使用者名稱 "'字串值'"
  使用者名稱-XX     使用者名稱-XX "'非英語語言字串值'"
  描述     描述 "'字串值'"
  描述-XX     描述-XX "'非英語語言描述字串值'"[註釋 1]
  kuid 表 按 kuid 列出的依賴項(容器)

  {
  }

  此資產依賴的資產的鍵值列表。
  已過時表 (容器)
    {
    }
  kuids 列表,此資產替換(使其過時)
通常為空(空)
  字串表 (容器)
    {
    }
  資產中使用的字串和訊息的鍵值列表
通常為空,但!
路線和場景中可能非常大。(地圖上的命名資產在此列出,從軌道標記和觸發器到訊號、命名建築和行業、以及路標。)
 字串表-XX 按每種非英語語言(容器[s])
    {
    }
  翻譯後的字串列表 對應 強制性的 字串表
  類別-區域 "'字串陣列'"     類別-區域標籤
  類別-類別 "'列舉字串值'   類別-類別標籤
  類別-時代 "'字串陣列'"     類別-時代標籤
  類別-關鍵字 "'字串陣列'"     自然語言關鍵字
  (替換型別、區域)
  自定義類別列表 
 "'字串陣列'"
  指令碼介面功能
  必須擁有的產品權利 
 "'字串值'"  
  DRM 字串陣列
  不能擁有的產品權利 
 "'字串值'"  
  DRM 字串陣列
  特權 (容器)
    {
    }
  更多 DRM
  縮圖 (容器)
    {
    }
  縮圖容器
  指令碼 (檔名)     "'字串值'"
  類別 (指令碼資產類別)     "'字串值'", 必須與 指令碼 規範類別同步。
  指令碼包含表
    {
    }
  (列出庫指令碼的容器)
  擴充套件 (容器)
    {
    }
  資產也使用的正式指令碼擴充套件
  許可證 "'字串值'"   資產建立者的版權宣告
  作者     "身份 '字串值'"
  組織     "第三方組身份 '字串值'"
  聯絡電子郵件     "電子郵件地址 '字串值'"
  聯絡網站     "作者/組的網頁地址 '字串值'"
  所屬組 (容器)
    {
    }
  此資產所屬的 型別資產組 資產列表。

 

型別的型別

[編輯 | 編輯原始碼]

所有 Trainz 定義的資料(內容)都包含三個必需元素:一個 config.txt 檔案 來組織資料,一個身份,即一個 kuid(只有使用者名稱是不夠的,但合法的資產可以在沒有名稱的情況下建立!),最後是一個合法定義的型別標籤。型別負責,就像樂隊的指揮、排長或 CEO 指示——設定處理後所有內容的要求。簡而言之,型別的值,一個很小且嚴格定義的成員組——告訴 Trainz 軟體在虛擬世界中渲染和顯示什麼,以及如何(或在何處)找到與 config.txt 檔案中的這些資產部分連結在一起的其他部分。
  下面的每個子類都被視為具有 TrainzBaseSpec 作為其資料'父類'。[註釋 2] 下面列出的一些型別,那些帶下劃線的型別,是比 TS2009 釋出時 Trainz 資料模型變更早期的遺留型別(即自 2008 年後期以來),N3V 程式設計師只對這些型別進行了逐漸(增量)的更改。
  目前可以在 N3V Trainz Wiki 的 內容建立者指南 部分找到基於這些遺留型別的資產修復的詳細資訊 TrainzOnline 網站在此處,以及發人深省的 遺留型別的示例在此處。強烈建議 Trainz 下載站 的任何使用者或任何考慮建立內容的使用者仔細閱讀 CCG。通過了解舊內容定義的背景歷史,可以將這些知識與 TrainzOnline 對相同資料型別的當前覆蓋範圍進行對比和比較,因為這種'過去-現在'的比較通常可以為修復、更改和自定義資產提供寶貴的見解。更重要的是,CCG 在 TrainzOnline 上釋出的是 TC1&2/TC3 版本——這是自 1999 年 Trainz 釋出以來印刷的幾本小冊子的最新版本;TC3 CCG 包含來自 TRS2004/TRS2006 和 UTC 資料模型的已更改引擎規範機車資產,需要正確更新。

TrainzBaseSpec 子類型別(型別資產組)

 


本地化

[編輯 | 編輯原始碼]
  • 本地化 是 '學術術語' 用於“國際化”或資料翻譯成其他語言...

由於 ACS 文字格式 使用 UTF-8 編碼,因此非英語文字字串條目可能會出現在 config.txt 檔案中的任何字串欄位中,除非有規定。(例如,使用者名稱標籤 應該始終是英語,但語言字尾形式也允許在區域語言中支援多種語言環境 - 為了避免混淆,需要本地化支援的標準字串標籤實際上允許多個條目,因為執行時軟體使用以下約定

  • 使用者名稱 - 內容的人類可讀名稱,以美式英語表示。資產的英文名稱必須存在,並且應該用英文定義。(不幸的是,少數資產在上傳時沒有受到此標準的約束,因此在 DLS 上找到了一些非英語名稱。)
  • 使用者名稱-cz - 內容的人類可讀名稱,以捷克語表示。
  • 使用者名稱-de - 內容的人類可讀名稱,以德語表示。
  • 使用者名稱-es - 內容的人類可讀名稱,以西班牙語(西班牙語)表示。
  • 等等。

以下標準標籤支援這種本地化形式
其中 XX 是語言的 ISO 兩字元縮寫。(例如 de=德語,fr=法語,it=義大利語,等等。)

常用容器

[編輯 | 編輯原始碼]
[編輯 | 編輯原始碼]

 

註釋、腳註和參考文獻

[編輯 | 編輯原始碼]

Config.txt 檔案在 Trainz 資產中是普遍存在的,因為沒有任何資產可以在沒有這種型別的 計算機科學容器 的情況下進行定義。 

  1. 大多數內容建立者很少注意在英語中提供清晰、經過深思熟慮的描述文字。在來自非英語地區的資產中,這些標籤的使用很少。
  2. 注意:此列表在 N3V TrainzOnline Wiki 上“維基化”,這意味著在“KIND”一詞之後,首字母大寫,而 config.txt 檔案中實際的標籤名稱全部為小寫文字。該維基還使用了很多雙引號,我們在此將為您省去這些體驗。
  3. 'kind consist' 不常直接看到,它只存在於選單和內容管理器列表中。

 

 

參考文獻

[編輯 | 編輯原始碼]

 

華夏公益教科書