跳轉到內容

Trainz/refs/TrainzBaseSpec

Add links
來自華夏公益教科書，開放世界的開放書籍
logo
 Trainz 註釋參考頁
Trainz 資產維護和建立
TOC | 開始 | 樂趣 | AM&C | 建立 | 書內參考 | ORP 參考：  • 索引 • 容器 • 種類 • 標籤 | 附錄  • 版本
[e]
KIND（型別資產組）
和 容器


KIND 層次結構簡介

[編輯 | 編輯原始碼]

KIND TrainzBaseSpec 為所有 Trainz 資產型別在所有 config.txt ini 檔案 中提供基礎定義。TBS 提供了一些“標準標籤”，這些標籤對所有 Trainz 資產都適用（或者至少，可以合法地定義）[1]。

  • 其中一些是強制性的，因為它們決定了資產的進一步處理，以及對 config.txt 檔案和其資料夾中資產資料的解釋。
  • 然而，大多數是可選的，在大多數子資產中，可以使用該標籤的定義行可以省略。

父類

[編輯 | 編輯原始碼]
  • 無，所有內容都由事實上的父容器定義，即 config.txt 檔案，該檔案是所有 Trainz 數字模型所必需的。KIND TrainzBaseSpec (TBS) 是一個根類，其他 Trainz 資產類都是從它派生的。
  • 之所以說它們是派生的，是因為它們繼承了處理屬性（指令）和引數中定義的值，其中最重要的一個是 kind 標籤的值。該列舉詞決定了資產的特定 kind 宣告和要求，這些宣告和要求被新增到該資產配置檔案中 TBS 的定義中。其他重要的 TBS 定義的資料具有明顯的意義和作用，例如資產的名稱、Kuid 識別符號和版本、Trainz 構建值 (TBV)，以及其他需要定義、適用性和範圍廣泛可變的定義，例如字串表、過時表、kuid 表和縮圖影像都是情景性的。即使是資產名稱和描述這樣的字串值，在實踐中大多數情況下都是完全不必要的，可以完全省略。
  • 當宣告一個 kind 時，該 kind 就會成為父類，它需要並規定必須在類中滿足的資料對，除了 TBS 中列出的那些資料對。
  • 某些引數可能在資產 kind 的情況下保持未定義，特別是對舊的歷史 Trainz 構建標籤值來說是一種常見做法，對於那些標籤，內容管理器或 Content Creator Plus (CCP) 實用程式將分配一個預設值，但在處理時會顯示警告訊息。TrainzOnline wiki、此處或較舊的 TC3 時代 內容建立者指南 (CCG 中的許多標籤都會提到一個預設值。
  • 從 TRS2006 和 Trainz Classics (TC1&2) 開始，每個版本的內容管理器模組都會強制進行越來越多的預先承諾錯誤測試[註釋 1]，並且每個版本都變得越來越堅定地警告這種標籤在期望這種標籤 - 資料對時沒有被定義。

在 TANE 後釋出的版本中，許多這些“昨天預設”的定義行今天會更常產生錯誤，要求明確的數值定義，而在過去的載入中這些值是預設的[註釋 2]。與過去時代相比，這是一種更好的煩惱，那時有缺陷的資產定義有時會導致臭名昭著的“藍色畫面宕機”，或者更常見的是，將執行時軟體崩潰到桌面，導致編輯丟失，並可能需要重建資料庫。

子類

[編輯 | 編輯原始碼]

所有 Trainz 定義的資料（內容）都有三個必需的元素：一個 config.txt 檔案 用於組織資料，一個身份，即一個 kuid（只有使用者名稱是行不通的，但即使沒有名稱，也可以建立合法的資產！），最後，一個合法定義的 kind 標籤。kind 是負責人，是管絃樂隊的指揮、排長或執行長，給出指示 - 為所有後續處理過程設定要求。簡而言之，kind 的值，一個小型、精選、嚴格定義的會員制群體 - 告訴 Trainz 軟體在虛擬世界中渲染和顯示什麼，以及如何（或在哪裡）找到其他部分，使 config.txt 檔案中資產的這些部分連結在一起。
  以下每個子類都被認為具有 TrainzBaseSpec 作為其資料 '父類' [註釋 3]。以下列出的一些 kind，即那些帶有下劃線的 kind，是早於 Trainz 資料模型 在 TS2009 版本（即 2008 年底以來）中發生更改的遺留 kind，N3V 程式設計師僅從那時起對它們進行了一些逐步（增量）更改。
  目前，可以在 N3V Trainz Wiki TrainzOnline 網站此處 的 內容建立者指南 部分找到基於這些遺留 kind 修復資產的詳細資訊，其中包含一些具有啟發性的 遺留 kind 的示例。強烈建議所有使用 Trainz 下載站 或考慮建立內容的使用者仔細閱讀 CCG。瞭解舊內容是如何定義的歷史背景可以與當前 TrainzOnline 對相同資料型別的覆蓋進行對比和比較，因為這種過去與現在的對比往往可以提供修復、更改和自定義資產的寶貴見解。更重要的是，CCG 在 TrainzOnline 上釋出的是 TC1&2/TC3 版本 - 它是從 1999 年的 Trainz 開始出版的幾本小冊子中的最後一個版本；TC3 CCG 包含來自 TRS2004/TRS2006 和 UTC 資料模型的經過修改的 Enginespecs 機車資產，需要進行適當更新。

TrainzBaseSpec 子類 KIND（資產型別組）

 


表 I, TBS 標準定義

[編輯 | 編輯原始碼]

TBS 標準定義

[編輯原始碼]

這些標籤和容器是標準定義，幾乎所有資產中都會找到。一些標籤是可選的，內容創作者可以選擇是否定義它們。標籤是關鍵詞，並且具有分配的單一鍵值或容器，例如字串陣列或 '{' ... '}' 繫結封閉的標籤值對或子容器。（Trainz 配置檔案中宣告的所有內容都是成對的，即使 '{' ... '}' 也被認為是一個 '鍵值'.

  • 容器是'鍵' 和 '鍵值' 對的集合 以及 TBS 中的 '上層容器'（與縮圖容器中的子容器相反）通常以 '-table' 結尾。
 種類    "'字串值'"
 trainz-build '浮點數', 1 位小數
 kuid  <Kuid 編碼值>
 使用者名稱    使用者名稱 "'字串值'"
 使用者名稱-XX    使用者名稱-XX "'字串值'"
 描述    描述 "'字串值'"
 描述-XX    描述-XX "'字串值'"
 kuid-table (容器)

  { 依賴項列表
  按 kuid 分組 }

  一個鍵值表，列出了此資產依賴的所有資產。
 obsolete-table (容器)
    {
    }		  kuids 列出此資產替換的資產（使其過時）
 通常沒有（為空）[註釋 5]
 string-table (容器)
    {
    }		  資產中使用的字串和訊息的鍵值列表
通常為空，僅在路線和會話中很大。
 string-table (容器[s])
    {  非英語
    語言文字 }		  翻譯字串列表 匹配到 必須的英語 string-table
 類別-區域標籤 列舉 程式碼  類別-區域 "'字串陣列'"  
 類別-類別標籤  類別-類別 "'列舉 字串值'" 
 類別-年代標籤  類別-年代 "'約束字串陣列'"  年代
 類別-關鍵詞 "'字串陣列'" 最大長度 64 位元組    類別-關鍵詞標籤 自然語言搜尋關鍵詞
  (替換型別，區域)
 自定義類別列表 
 "'字串陣列'"		  指令碼介面功能
 必須擁有產品許可權 
 "'字串值'"  		  DRM 字串陣列
 不得擁有產品許可權 
 "'字串值'"  		  DRM 字串陣列
 許可權 (容器)
    {
    }		  更多 DRM
 縮圖 (容器)
    {
    }		  縮圖容器
 指令碼 (檔名)    "'字串值'"
 類 (指令碼資產類)    "'字串值'", 必須與 指令碼 規範類同步。
 script-include-table
    {
    }		  (列出庫指令碼的容器)
 擴充套件 (容器)
    {
    }		  資產也使用的正式指令碼擴充套件
 許可證 "'字串值'"  資產建立者的版權宣告
 作者    "身份 '字串值'"
 組織    "第三方組身份 '字串值'"
 聯絡電子郵件    "電子郵件地址 '字串值'"
 聯絡網站    "作者/組網頁 URL '字串值'"
 所屬組 (容器)
    {
    }		  一個 KIND 資產組 資產列表，其中包含此資產。

 



支援的標籤

[編輯 | 編輯原始碼]

TrainzBaseSpec 在 config.txt 檔案 中支援以下標籤。 ∅:  

種類標籤

[編輯 | 編輯原始碼]
型別: 字串。
欄位定義: 此 config.txt 檔案 所代表的資產型別。請檢視索引 種類 和列表：這裡（上面）

 

kuid 標籤

[編輯 | 編輯原始碼]
型別: KUID（簡短），主要：KUIDs
欄位定義: 引用此資產的唯一資產 ID。
KUID
'Koolthingz Unique IDentifier'. Trainz 系統軟體的唯一資料庫參考號，它也擴充套件到 KUID2 格式以跟蹤多個版本。Trainz 可升級性和資產模組化設計的核心，因為每個資產都有自己的唯一 kuid 程式碼，因此可以指定元件（轉向架）或整個火車車廂，並選擇性地在新的資產中替換它們（重新貼皮或修改卡車）。
  • 基本 KUID 格式：'<kuid:wwwwww:xxxxxx>'，其中 wwwwww 是作者的 '唯一 Trainz 身份'，xxxxxx 代表作者分配的 模型標識程式碼。
編輯注： 但請注意，許多線上網站需要使用單獨的資料欄位（作者和序列號）進行搜尋，內容管理器需要三個或四個冒號分隔的資料欄位，但不需要方括號 - 儘管在搜尋 API 視窗中，逗號是多個 kuid 的必要分隔符。在完整的 kuid 標籤結束括號中聚合資料通常更容易，並且通常更易於閱讀。對於剪下和貼上大量列表，緩衝區大小限制可能會截斷列表的末尾，在這種情況下，在文字編輯器中修剪掉兩個結束括號可能會允許將整個列表放入 API 中。



  • 大多數 Trainz 資產在他們的 kuid-table 中指定了依賴項列表 - 軟體套件的各個部分組裝的其它元件資產，以在 kuid-table 容器 中構成可渲染和可使用的資產。
  • 許多資產的核心包含特定標籤，這些標籤可能由kuid 引用定義並使用被引用的資產作為其一部分。實際上，這就是重製皮膚的方式，並且也可以在資產中使用網格，儘管更現代的做法建議這種引用應指向網格庫資產。
KUID2
KUID 格式的更新和更新跟蹤修改版本，它允許指定版本號。<kuid:xxx:yyy> 等同於 <kuid2:xxx:yyy:0>（零修訂或版本零，表示原始版本）
  • 這允許資料項（Trainz 資產）攜帶資產的固有版本程式碼。這通常不與 CM Trainz-build 程式碼 相匹配，後者標識軟體技術級別，但它指示先前版本的歷史記錄。
  • 如果資料庫儲存了兩種資產，那麼具有更高字尾程式碼的 KUID2 資產將覆蓋或替換舊的資產。擁有早期版本並非必要，但 CM 會將缺少的修訂鏈列為缺少的依賴項，對於那些反感 CM 中這種設施被汙染的人來說，這是一種軟體錯誤，或者說，程式設計師保留的“功能”，無論如何，都減少了使用 CM 識別使用者缺少什麼的功能，並導致使用者花費時間手動找出實際情況。

 

trainz-build 標籤

[edit | edit source]
主要範圍：trainz-build 標籤，縮寫：TB & TBV (TB-value)∅
型別： 由 N3V[2] 列舉的具有一個小數點的浮點數，用於跟蹤和識別與演化軟體的技術水平相對應的資料型別。
範圍： 1.0–4.3，直接對應（對映到3rd）Trainz 1.0—TANE-SP1+hf2；預計此值將隨著每次新的主要軟體升級而增加 0.1。

每個合法值必須與已釋出的 Trainz 版本號 完全匹配，但以下情況除外

  • 分配給 V1.4 的 TBV 或版本值是 Auran 的 Paintshed 版本，這是一個重製皮膚工具，也適用於 Microsoft Trainz Simulator (MSTS)，並且也作為 TRS2004 輔助軟體模組的構建值出現；具體來說，它是 ContentManager.exe 實用程式。
  • 1.7 和 2.0 之間的差距要麼是外語版本，要麼，經過數小時的挖掘和研究，更可能的情況是，Auran 沒有使用它，因為在構建最初 Trainz 的程式設計師團隊的心目中，TRS2004 版本是第二個 Trainz 產品，無論前臺如何宣傳營銷名稱（比如 Trainz UTC，是終極的任何東西……真的嗎？ 拜託！ 說真的！！？）
Trainz 版本系列及其相應的 Trainz-build 標籤 值為 Trainz 1.0=v1.0，Trainz 1+SP1 ⇒ V1.1，Trainz 1.0+SP2 ⇒ V1.2，Trainz 1+SP3 ⇒ V1.3，等等（但跳過 1.4 & 1.7–1.9），所以 TRS2004-SP0 = v2.0 然後遞增，其中每個版本從 2.0（TRS2004 無服務包）開始遞增 0.1，一直到現在的版本（v3.7 = TS12-SP1，v3.8 = Mac2，3.9=TANE-CE，4.0—4.3 及此後？ 從 2016 年 3 月開始，4.3 及以上版本為 TANE SP TBDL）。
  • 從 v2.0 (TRS2004) 開始，Trainz-build 標籤編號值已經透過 23 個步驟遞增，這些步驟是連續的，儘管不是單調的，因為 Trainz TS09-sp3—TS09-sp4 共享一些 Trainz-build[2] 值；也就是說，在 TS2009 和 TS2010 的聯合開發時代和版本中，有一些 TBV 是重疊的。
  • 此外，N3V 進軍 Mac 電腦領域，打斷了 Windows 版本的 Trainz 版本的 TBV 3.4、3.5、3.6、3.7 & 3.8 在 Windows 和 Mac 作業系統之間的平滑遞增。
    注意： 熱修復程式 不會更改版本號。
欄位定義： 此資產構建（和存檔）的檔案格式版本，不一定與資產使用的技術級別有關，但與在 Content Creator Plus 中建立資產時分配的資產級別相對應，與在 CM 的標題欄中找到的值相同。
  • 程式設計師建議此編號通常應設定為建立和測試資產的 Trainz 安裝的 Trainz 版本號。相比之下，Content Creator 社群試圖將此編號設定得儘可能低，以便在下載時為新資產提供儘可能廣泛的受眾/使用者範圍。較好的內容創作者會在對應版本的裸機安裝（無新增內容）上對其進行測試，並驗證生成的 cdp 是否包含所有相關材料。
  • 某些資產型別根據其trainz-build 版本標籤的解析方式存在很大差異。注意：trainz-build 標籤 是強制性的。如果未指定，Trainz 將根據 config.txt_file 的內容，嘗試以一種原始的方式猜測舊版本的 Trainz 版本，通常會解析為 1.3 的 TBV 值。

 

使用者名稱標籤

[edit | edit source]
型別： UTF-8 字串，資產的使用者名稱，強制規範。
欄位定義： 此資產的英文人眼可見的名稱。

在 TC1&2 (v2.7) 之後的 trainz-build 中，使用者名稱也成為編輯資產時作業系統的資料夾名稱，並且資產檔名被忽略，而它在 v2-6 配置檔案中優先順序更高。根據 N3V Games 的 TBS 標準，此欄位絕不能包含非英文文字，除非資產名稱是專有名詞（例如地名），並且沒有英文字地化變體。此值是每個人通常搜尋和記住的資料，因此建議保持清晰的名稱。

在建立資產時，強烈建議您在 CM 搜尋中針對幾個試用部分名稱驗證新的提議名稱，並根據這些知識採用與現有可用內容合理匹配的名稱。
我們需要容忍多少個“house 2”或“road”資產來進一步混淆我們？ 好吧，實際上，我們都會搜尋 house 並從圖片中選擇，但是能夠指定一個唯一的名稱並獲得你期望的東西真是太棒了！


 
 

username-XX 標籤

[edit | edit source]
型別： UTF-8 字串，使用者名稱標籤 的替代語言版本。
欄位定義： （其中XX 被替換為所代表語言的相應 本地化程式碼。）此資產的本地化人眼可見的名稱。此欄位類似於使用者名稱欄位，但代表非英文語言環境。一個資產中可能存在多個username-XX 標籤，每個支援的語言環境一個。如果不存在適當的“username-XX”標籤來在給定終端使用者系統上表示此資產，則改為使用英文使用者名稱標籤。

 

描述標籤

[edit | edit source]
型別： UTF-8 多行字串，提供資產的清晰語言描述。
欄位定義： 此資產的英文人眼可見的描述性摘要。

描述在 Content Manager 的“資產詳細資訊”窗格中可見，用於闡明資產名稱，提供規格，以及通常的簡要歷史記錄。

N3V 的 Chris Bergmann 已經宣告此欄位應保留為簡短的（1-2 段）描述資產的簡介，並應透過info-url 頁面提供擴充套件細節，但容忍相當長的文字塊。有些人將文字塊的底部用作版本更改記錄。

此欄位必須包含英文描述性文字，儘管文字可以引用非英文專有名詞，如其他地方所述。其他語言翻譯或源文字應放置在許多可能的替代語言本地化標籤之一中（參見 description-xx 標籤）。 

description-XX 標籤

[編輯 | 編輯原始碼]
型別: UTF-8 多行字串，描述標籤.
欄位定義: (其中XX 被替換為相應的 本地化程式碼 來代表當前語言。) 此資產的本地化人眼可見的描述性摘要。 此欄位類似於description 欄位，區別在於它代表非英語語言環境。 一個資產中可能存在多個description-XX 標籤，每個支援的語言環境對應一個。 如果在特定終端使用者系統上沒有合適的'description-XX' 標籤來代表此資產，則改為使用英語description 標籤。

 

字串表容器

[編輯 | 編輯原始碼]
型別: UTF-8 字串列表容器，字串表容器.
欄位定義: 一個英語字串的鍵值對列表。 每個鍵是一個有意義的指令碼識別符號，對映到二進位制資料並被其引用。 每個值都是一個英語字串。 英語字串可以包含或引用非英語專有名詞作為識別符號。 非英語母語作者創作的資產，如果需要，仍然必須建立一個無後綴的字串表容器。 軟體只連結到無後綴的字串表容器中的名稱和值並引用它們，這對於西班牙語、法語、德語、捷克語、荷蘭語…日語作者來說無疑是令人困擾的。 換句話說，帶字尾的字串表僅僅是為了翻譯目的，這在用非英語編寫的路線中會產生問題——沒有 string-table-en 來提供一個表用於反向翻譯。 同樣，username-en 和 description-en 也是如此。 這三個缺失都表明了一種過時的、漫不經心的傲慢和對世界動態的漠不關心。

  其他語言也透過類似的字串表 (例如 string-table-XX) 支援，這些字串錶帶有本地化程式碼字尾 (XX)，與描述和使用者名稱關鍵字/標籤的國際化字尾匹配，但這些以語言為鍵的字串表容器的左側條目始終具有相同的鍵值。  

  • 這些左側鍵或標籤既用作'本地索引關鍵字'，又用作語言之間的'等價表'。
  • 左側列始終包含內容建立者賦予“特殊”名稱的物件，例如訊號、里程標、工廠、連線點等名稱，這些名稱可能會被引用，並且會出現在駕駛員和測量員模組的“查詢工具” (CTRL+F ) 功能小程式中。
  • 相反，索引側也不會列出諸如無數連線點之類的預設名稱，這些連線點在構建路線圖時會由隨機數自動索引 (即無意義的雜亂。如果重要，路線構建 CC 會命名它！)； 但會自動包含潛在的臨時資產，例如火車車的預設名稱。 如果重新命名，這些名稱將取代其對應的預設名稱。
  • 它的主要用途是那些旨在與指令碼引用互動並接受可變屬性的物件，例如火車站或工廠所需或準備出貨的產品數量，或由互動式火車車 (滾動式工廠到指令碼) 和其他可配置資產運載，這些資產與通用廣告牌風格的標誌一樣簡單，透過一些高度調整和角度扭轉，可以放置在庫存建築或工廠的正面，以便在建築物上放置不同的企業名稱。 換句話說，一些可配置的場景。
  • 總體而言，在路線圖或佈局中，這些 LHS 名稱對應於地圖資產上的命名物件，這就是大多數字符串表被看到的地方 (從字面上講，在一個大型路線kind 地圖中，有數千個條目)。
  • 在某些資產中，該預設名稱被連線到軟體指令碼，因此字串表變得特別重要，而不是平淡無奇。(見下文)
  • 在任何型別的資產中使用字串表型別都是合法的，就像描述標籤、trainz-build 和 kind 標籤一樣。 與它們不同的是，它不需要存在或定義，並且在任何情況下都不是強制性的。 字串表容器中封裝的值除非程式碼期望它們匹配，否則沒有任何功能或效果。
  • 在其他資產中，同樣以假設的可程式設計企業標誌為例，如果要與軟體互動，則必須為字串表賦予預設名稱。 所有地圖可放置資產都可以命名或重新命名，但“特殊名稱”必須與指令碼和字串表索引值匹配。 大多數可配置資產定義了一個介面變數，該變數用於替換預設名稱作為索引或查詢表，並由指令碼和資產的二進位制資料引用。 可能會在可程式設計資產中定義其他變數。 每個變數都可以被指令碼引用，但正是索引值使它進入地圖或會話字串表，當需要駕駛員或會話建立者可變性時，使所有東西協同工作。
  • 相反，如果沒有系統軟體知道索引中命名專案的定位，那麼物件的指令碼可能沒有觸發、條件檢查或更新能力。 這是 2000 年代Trainz 1.0 中物件的特徵，自 2003 年釋出TRS2004 以來，並非更現代的 Trainz 鐵路模擬器。 (我們從那時起走了很長一段路！)
  • 有些資產只能作為一個組協同工作。 在這種情況下，在地圖或會話層中命名每個資產可以使它們協同工作。 例如，考慮一個有五個軌道的公路平交道，其中兩個軌道在連線點之外，形成所謂的 '菱形交叉路口' 與直通軌道。 如何設定訊號，以便任何鐵路交通都會關閉公路閘門，或者如何使用菱形交叉路口來禁止其他列車穿過正在過路的列車。 道路和鐵路訊號、道岔和閘門必須協同工作。 由字串表匹配的某些“ATLS 系統”資產及其指令碼可以使這個複雜的系統正常工作。
  • 有關更多資訊，請參見 string-table-XX。

 

string-table-XX 容器

[編輯 | 編輯原始碼]
型別: UTF-8 字串列表容器，本地化字串表，每個字尾對應於英語以外的語言。
欄位定義: (其中XX 被替換為相應的 本地化程式碼 來代表當前語言。) 此欄位類似於string-table 欄位，區別在於它代表非英語語言環境。

英語字串表 (無後綴) 是強制性的，其他本地化語言是可選的，由資產作者決定。 提交到 DLS 並隨後在與 Trainz 版本捆綁在一起的路線中使用的許多資產通常會被翻譯，並具有針對 description-XX 和字串表的完整本地化翻譯集。 特別是，與版本捆綁在一起的路線和會話會在每個零售版本中接受專業翻譯，翻譯成多種語言。

請注意，字串表的左側列是相同的，因為它是一個對映的符號表，並且索引到諸如網格、會話或路線檔案之類的二進位制資料。 只有使用名稱，即兩個元素中的右側或資料元素是本地化的，並由執行時本地化軟體替換。 如果需要，即使在英語字串表中，也可以手動編輯這些名稱，以獲得更友好的名稱。 索引或左側引用列語法不能以任何方式更改，因此在資料列中更改名稱時，請謹慎使用全域性 SAR 規範。

一個資產中可能存在多個string-table-XX 標籤，每個支援的語言對應一個。 每個標籤都應該包含一個字串列表，該列表與string-table 列表具有相同的鍵，但具有不同的值。 如果沒有合適的'string-table-XX' 標籤來代表特定終端使用者系統上的此資產，或者該列表中缺少相應的字串，則改為引用英語string-table 容器。  

kuid-table 容器

[編輯 | 編輯原始碼]

kuid-table   {
 numberit_library                      <kuid2:75134:99003:7>
 0                                     <kuid:-3:10164>
 1                                     <kuid:-1:42004201>
 2                                     <kuid2:50567:11155:1>
 3                                     <kuid2:58422:50120:1>
 4                                     <kuid:-3:10003>
 5                                     <kuid2:30671:94407101:1>
 6                                     <kuid2:87907:94407101:1>
 7                                     <kuid2:87907:94407103:1>
 8                                     <kuid2:87907:94407105:1>
 9                                     <kuid2:30671:9870190:1>
 10                                    <kuid2:30671:94407100:1>
 11                                    <kuid2:87907:94407100:1>
 12                                    <kuid2:87907:94407102:1>
 13                                    <kuid2:87907:94407104:1>
 14                                    <kuid:-3:10013>
 15                                    <kuid2:60318:10008:1>
 16                                    <kuid2:60318:10010:2>
 17                                    <kuid2:189041:301:1>
 18                                    <kuid2:50567:11121:1>
 19                                    <kuid2:30671:9840820:1>
 20                                    <kuid2:30671:9870899:1>
 21                                    <kuid2:50567:12646:3>
 22                                    <kuid2:124017:30000:2>
 23                                    <kuid2:124017:30001:2>
 24                                    <kuid2:124017:30002:2>
 25                                    <kuid2:124017:30003:2>
 lodi_icon                             <kuid2:124017:35000:1>
 lodi_lib                              <kuid2:124017:40000:1>
 26                                    <kuid2:30671:69006:1>
 27                                    <kuid2:124017:35000:1>
 28                                    <kuid2:30671:90810901:1>
 29                                    <kuid2:30671:9081290:1>
 30                                    <kuid2:60318:10009:1>
}
型別: KUID 列表容器，與過時表容器 (如下) 的格式相同。 一個虛擬引數 + 一個 (依賴項) KUID
欄位定義: 鍵值對列表，用於區分此資產依賴的資產。

 

通常
只有具有子元件或備選方案（貨物）的資產才會具有長度可觀的 kuid 表。大多數只有子元件的資產只有幾個。
  • 其次，由於內部關鍵字有時是“自動定義”的，因此出現了一種慣例——僅列為一個沒有名稱的數字，例如 佔位符引數，偽關鍵字，可以是任何唯一值（通常是按順序遞增的從零開始的整數。[註釋 1]）它們可以被命名也可以不被命名，取決於使用者或作者的偏好。
  • 此表中的條目有兩個目的
    ‌首先：確保遊戲系統知道這種依賴關係，以便安裝和載入此資產將成功安裝和載入任何依賴關係，以及
    ‌其次：允許指令碼定位相關的子資產。
  • Kuid 表中只應包含第一級依賴關係——具有自己依賴關係的子資產或部件資產將在該子資產的驗證和資料庫提交過程中進行處理。
  • 迴圈依賴關係是非法的。
  • 如果資產也標記為此資產的過時版本，則不能將其列為依賴關係。（Trainz 資產索引（歷史上是 assets.tdx 檔案）中的 KUID 中只有一個替換 KUID 插槽，這將建立一個迴圈定義，要求其自身的較早版本！)
  • 類似地，資產不能被列為其自身的依賴關係。[另一方面，這已經出現過（例如，在 TSxx CM 中，見證了成功提交的無錯誤資產）在使用 GSARS 將地圖和會話移植到不同安裝之間，以更改 KUID，從而避免重疊覆蓋已使用相同 KUID 的資產在目標安裝上，而不會看到錯誤訊息。] 它的功能是否也需要比我更勇敢或更愚蠢的人！--Fabartus，編輯。
格式 (所有值均為 <kuid:aaaaa.bbbbb> 格式)
kuid-table {
 0            Kuid-1
 1            Kuid-2
 3            Kuid-3
 ...          kuid-ii
 N-1          Kuid-N
 }
大多數使用者的第一項內容將是自動克隆內建路線及其關聯的會話。通常是因為想要修改某些內容。檢查路線或會話的 kuid 表將使新手或老手 Trainzer 能夠獲得路線中資產的可編輯列表。這些可以很容易地轉換為樣式表“過濾器”（選擇列表），它允許使用者使用與原始作者相同的資產新增和更改路線... 或者在您自己的擴充套件中複製他的樣式。


  • 利用這些是虛擬引數這一事實的一個非常有用的方式是將複雜滾動庫存資產中的產品的 KUID 配對。一個貨車可能包含各種各樣的產品... 獲得許可權將您的作者 ID 分配給您自己的系列，並使用不同的裝載集，這可能是您進行重大內容創作的第一步！考慮一輛運貨汽車，允許的產品容器，kuid 列表可能包含以下條目
...  {

Animal_chickens		<kuid:-25:230>

Animal_Horses		<kuid:-25:236>

Animal_Cows		<kuid:-25:239>

Animal_Piggies		<kuid:-25:238>

Animal_Sheep_Flock	<kuid:-25:240>

} ...

注意單詞之間的下劃線... 兩個符號，鍵和值！我們讓學生來找出如何將 KUID 新增到裝載和允許的產品隊列表條目中。（歡迎，但這是改變名稱的一個很好的理由！保持思路清晰幾乎是製作資產的全部戰鬥！) 

obsolete-table 容器

[edit | edit source]
型別: KUID 列表容器，與 Kuid-table 容器 格式相同。
欄位定義: 一個“佔位符-鍵—鍵-值”資產列表，這些資產被此資產淘汰。任何嘗試載入此列表中的任何資產將導致載入此資產。
  • 此外：兩個資產都標記第三個資產為過時的行為是非法的，除非兩個資產中的一個也標記另一個為過時。[註釋 6]
  • 迴圈過時引用是非法的。
  • 此資產的所有低編號 KUID2 版本都被隱含地標記為過時，並且不需要包含在此列表中。同時，更新的改進資產（具有更高的 Kuid2）及其某個前身永遠不應該將相同的前身（例如原始的！）列為“中間”的中間前身——因為這些值被用作 替代條目表，並且只有一個資產可以替換之前的版本。（陣列只儲存一個值，不能將兩個替換為一個！)
  • 將此資產的更高編號 KUID2 版本標記為過時的行為是非法的，因為這會建立一個隱式迴圈引用。
  • 此列表中引用的資產必須與此資產具有相同的建立者，才能由 DLS 上傳流程稽核和接受，此限制在您的本地版本中不適用，例如，它可以用於將大型火車車組上所有舊的紙輪 KUID 替換為一個更具圖形美感和更新的 KUID。

 

category-region 標籤

[edit | edit source]
目的：CM 和 Surveyor 中的過濾器（搜尋條件）
型別: 列舉字串或字串陣列。
欄位定義: 一個由分號 (';') 分隔的雙字元 category-region 標籤 程式碼列表。字串中不應包含其他字元（包括空格等）。此資產被認為與每個指定的區域相關——這對 kind traincar 和 kind mosignal 資產最為相關，但可以針對任何資產提供。
示例
category-region “CA;US”
category-region “CA;MX;US”（北美國家，加拿大、墨西哥、美國）
category-region “CA;CS;DE;MX;US;VE;AU;FR;IN;IT;JP;KR;ES;AR;AT;BE;CH;DK;IE;EE;NL; NO;NZ;PA;PL;PR;PT;RO;RU;SE;SK;UA;UK”（大多數第一世界國家）

 

類別-類別標籤

[edit | edit source]
目的：CM 和 Surveyor 中的過濾器（搜尋條件）；根據 KIND 聲明確定 CM 軟體如何處理資產以及 Surveyor 在何處列出它。
型別: 列舉字串。
欄位定義: 一個描述此內容專案的單個 2-3 個字元的 category-class 程式碼。category-class 標籤用於提供超出資產種類隱含含義的額外的人工子分類。每個 Trainz 資產的 category-class 標籤有助於描述資產在遊戲中的“意圖”，而不是資產的內部結構。
內容建立者指南 (CCG) 適用於 TRS2006 和 Trainz Classics 的 CCG 解釋了這些類別代表了一種標準化系統，用於引用各種型別的機車、滾動庫存、景觀、樣條線和工業資產。Category-class 分類程式碼在 Trainzer 搜尋和/或過濾適合資產以使其成為會話或路線（佈局）中的內容時變得很重要。


 

請注意，許多 category-class 程式碼僅與特定資產種類相關——不應將 category-class 程式碼應用於不適當種類的資產。

示例
    category-class “XBG” 貨車——來自 PRR 60'
    category-class “BR” 鐵路（景觀非功能性）——可能是一棟建築
    category-class “BIN” 具有產品處理功能的工業資產

 

類別-年代標籤

[edit | edit source]
目的：CM 和 Surveyor 中的過濾器（搜尋條件）
型別: 列舉格式字串陣列。
欄位定義: 由 分號 (';') 分隔的五字元 時代程式碼 列表。
  • 每個時代程式碼代表一個十年，由一個四位數的整陣列成，然後 必須以 's' 結尾 (例如“1990s;2000s;2010s”) ，從而建立一個列舉軟體標記（值），它必須與一個指定的合法 時代程式碼 完全匹配。
  • 字串中不應包含其他字元（包括空格等），包括（尤其是在字串末尾）在終止雙引號字元之前。
  • 允許的年份範圍是 1800-2010s[註釋 7]
  • 此資產對其他人類的唯一意義是，此資產被認為在指定的時代範圍內有效且相關，並且 內容管理器 將接受指定適用年份的搜尋過濾器。

 

示例
category-era              "1920s;1930s;1940s;1950s"

 

縮圖容器

[edit | edit source]
目的：CM 和 Surveyor 中的過濾器（搜尋條件）
型別: thumbnails 容器.
欄位定義： 用於在整個遊戲環境中（包括遊戲內、內容管理器 和 下載站）以 2D 預覽框、列表和圖示形式代表此資源的縮圖。每個資料集都包含在一個子容器中（通常），使用 佔位符引數 作為鍵名或標籤。[註釋 8] 慣例將這些設定為 0 索引的整數，但該值可以是任何非空文字值，可以評估為 字串。（見下文第二個例子）
一個實際的例子
（來自資源修復編輯[3]）
thumbnails {
	0 {
		width					240
		height					180
		image					"$Screenshot (240)(kuid 68787 25222).jpg"
	}
	1 {
		width					512
		height					512
		image					"$Screenshot (512)(kuid 68787 25222).jpg"
	}
}

另一個常見的尺寸是 火車場 和測量員資源選擇 API 中使用的 128x64“圖示”，它應該有 Alpha 遮罩 或非常淺的背景。許多較舊的資源沒有使用 jpg 檔案，而是將 .tga 檔案（Targa True Color）列在“_art”子資料夾中（Trainz 1.0 - TC3 慣例：_art、_body 和 _shadow 是早期 Trainz 資料模型要求規定的三個子資料夾，名為“asset-filename_suffix”（過時的標籤 - 對），看起來像這樣[註釋 9]

thumbnails
{
  Icons
  {
    width 128
    height 64
    image "40ft_boxcar_art\40ft_boxcar_art_icon.texture"
  }
 CM
 {
   width 240
   height 180
   image "$screenshot PRR 40ft_boxcar (240).jpg"
 }
 DLS1
 {
   width 512
   height 512
   image "40ft_boxcar_art\40ft_boxcar_art_512.texture"
 }
 DLS2
 {
   width 512
   height 512
   image "$screenshot PRR 40ft_boxcar (512).jpg"
 }
}

在 TS2009 和 TS2010 的早期版本中，沒有正確縮圖容器的資源會被標記為有缺陷。之後的補丁將這些標記改為警告。[註釋 10] 這種做法在 TS12 的一個熱修補程式中被取消，因為使用者社群中對此有很多抱怨。
 • 如果缺少縮圖容器的資源（即使有過時的縮圖標籤）後來在新內建路線或會話中被選中，該資源通常會作為沒有影像的專案進行分發 - 如果沒有被 texture.txt 或 config.txt 縮圖容器正確引用，它們會被刪除[註釋 11]。  

軟體連結

[編輯 | 編輯原始碼]

info-url 標籤

[編輯 | 編輯原始碼]
型別： URL 字串。
欄位定義： 指向資源線上描述、資源說明（幫助）或 TrainzOnline Wiki 上其他幫助頁面的連結，旨在從嵌入式專用 N3V 瀏覽器中使用。URL 必須解析到 Trainz Online 安全區 內的網站。目前，嵌入式瀏覽器接受三個域
     auran.com
    ts2009.com
    ts2010.com

此外，建議使用自定義的 Trainz 短 URL 格式來防止將來網站佈局變化，而不是直接連結到這些域。'短 URL' 是 Trainz 特定的 URL，透過允許內容建立者引用 N3V 網站上的某些頁面來幫助將來保護內容，而無需依賴特定的網頁佈局。短 URL 旨在用於遊戲內使用，例如 info-url 連結，並且僅在嵌入式網頁瀏覽器中有效，而不是在任何外部網頁瀏覽器中。在存在此標籤的情況下，遊戲內按鈕將提供給使用者，允許使用者檢視資源描述或幫助，而無需離開遊戲環境。

這在駕駛員中可能非常有用，可以訪問路線地圖、指南或會話說明或說明。

建議在任何情況下使用通用組頁面來表示具有類似功能但外觀略有不同的所有資源類別。這減少了建立、維護和本地化此類文件的時間成本。

 

must-have-product-rights 標籤

[編輯 | 編輯原始碼]
型別： ASCII 字串。
欄位定義： 一個由分號 (;) 分隔的必需產品許可權列表。如果本地安裝沒有必需的產品許可權，則某些遊戲系統可能無法載入資源。

 

must-not-have-product-rights 標籤

[編輯 | 編輯原始碼]
型別： ASCII 字串。
欄位定義： 一個由分號 (;) 分隔的衝突產品許可權列表。如果本地安裝具有列出的產品許可權之一，則某些遊戲系統可能無法載入資源。

 

許可權容器

[編輯 | 編輯原始碼]
型別： “許可權”容器 是某些作者使用的 DRM（數字版權管理）和複製保護實施，也可以稱為許可權 DRM 容器。DRM 表示數字版權管理，這就是它實現的內容。如果已定義，某些引數將阻止檢視資源的 config.txt 檔案。
欄位定義： 資源建立者設定的一組許可權，用於控制如何操作此資源。
privileges {
  is-payware-content 0 
  permit-listing 1
  permit-edit 1
  permit-commit 1
}

  上面的容器使用預設值設定，這意味著

0）這不是付費資源，因此其他欄位有意義[當付費資源編輯和提交將為零時，但可能允許列出]；

允許

1）檢視資源的 config.txt 檔案，
2）編輯資源，包括檢視其主資料夾中元件檔案的內容，
3）重新儲存對資源的任何更改（將重新驗證的資源提交（提交）到資料庫）。

 

script 標籤

[編輯 | 編輯原始碼]
型別： 字串檔名。
欄位定義： 指示此資源的主指令碼檔案的路徑（如果有）。此路徑應始終以“.gs”副檔名結尾 - 執行時將嘗試新增或替換“.gs”副檔名，如果路徑具有其他副檔名。

 

class 標籤

[編輯 | 編輯原始碼]
型別: 字串。
欄位定義： 指示要載入的指令碼類名稱，作為此資源的主類（如果有）。此類從此資源的主指令碼檔案載入。

 

script-include-table 容器

[編輯 | 編輯原始碼]
型別： KUID 引數列表及其對應的名稱作為鍵。
欄位定義： 一個鍵值表，其中包含在編譯此資源的指令碼檔案時搜尋指令碼包含的指令碼資源。鍵（一個變數，所以不是標籤）當前未使用，但必須是唯一的；值表示要包含的資源的 KUID。

script-include-table 容器 是任何資源都可以使用的頂級 config.txt 檔案 條目（簡而言之，所有資源）。此容器允許資源使用 N3V TrainzScript 的 Script_Include_Directive，直接從父資源的指令碼檔案包含另一個資源的指令碼。

相關

擴充套件容器是具有特定命名約定的自定義標籤或子容器列表。

S-I-T 容器支援的標籤

[編輯 | 編輯原始碼]

此容器是一個簡單的鍵值表，其中包含指令碼資源的名稱及其 KUID，在編譯資源的指令碼檔案時會搜尋指令碼包含。鍵或標籤名稱在搜尋時當前未使用（即為 佔位符引數）；值表示要包含的資源的 KUID。能夠搜尋和識別鍵名稱是內容建立者請求的功能，因此建議使用指令碼檔名而不是數字虛擬標籤名作為最佳實踐，因為它比 KUID 引用傳達的資訊更多。

S-I-T 容器驗證

[編輯 | 編輯原始碼]

通常最好將此類引用限制為 KIND 庫 資源，但這並非強制性，可以引用任何資源。

S-I-T 容器示例

[編輯 | 編輯原始碼]
script-include-table {
                       a-key        <kuid:nnnn:nnnnn>
                       enginespec   <kuid2:www:xxxxx:yy>
                       anim-doors   <kuid:tttt:uuuuuu>
                     }

 

擴充套件容器

[編輯 | 編輯原始碼]
型別：擴充套件容器。
欄位定義：一組擴充套件屬性，它們為指令碼提供了超出此資產型別定義的Config.txt 檔案規範的額外資訊。在建立新擴充套件時，應注意遵守擴充套件命名指南，並在為現有擴充套件提供資料時遵守擴充套件建立者的指南。Auran 保留根據擴充套件建立者的指南，在將來新增對擴充套件容器中特定條目的驗證的權利。

 

較新且不太常見

[編輯 | 編輯原始碼]

以下關鍵詞是比較新的發展，在舊的資產中沒有類似物或存在。 

類別關鍵字標籤

[編輯 | 編輯原始碼]
型別：UTF-8 字串。
欄位定義：一個自然語言關鍵字列表，用分號 (;) 分隔。字串中不應存在其他字元（包括空格或無關的標點符號）。這些關鍵字構成了資產關鍵字搜尋的基礎。資產的使用者名稱不需要在類別關鍵字列表中重複。
  • 根據資產型別 (KIND+類別-類別)，會自動提供各種預設搜尋關鍵字，因此不需要，可能也不應該重複。Ø
  • 標籤可能不會作為空字串 ("") 或空白出現在標籤之後——這些情況會產生錯誤。
  • 明顯的使用：公司如 ATSF、Santa Fe 和 AT&SF、B&O、Chessie、CSX、NS、PRR 或 NYC 等等，而基本型別如平板車、貨車、料斗車應該是自動的。橋接鍵如凹陷、井車和側傾卸（換句話說，是修飾符）可能應該用於增強自動關鍵字生成的有限智慧。自動生成的術語的重複不應令人擔憂。

 

{{anchor|custom-category-list 容器|自定義類別列表容器|custom-category-list 標籤|自定義類別列表標籤|custom-category-list 字串|自定義類別列表字串|自定義類別列表容器|custom-category-list 容器

custom-category-list

[編輯 | 編輯原始碼]
型別：ascii 字串陣列容器。
欄位定義：一個自定義類別識別符號列表，用分號 (;) 分隔。每個自定義類別識別符號應為一個短（例如 3-6 個字元）的字母數字標記。字串中不應存在其他字元（包括空格）。
  • 這些自定義類別用於使指令碼能夠快速定位特定類別的資產。強烈建議謹慎引入新的自定義類別識別符號。
  • custom-category-list 標籤值總共不應超過 64 個字元。除非存在只能透過 custom-category-list 方法滿足的特定指令碼要求，否則此標籤應保留為空。

 

member-of-groups 容器

[編輯 | 編輯原始碼]
最小版本：V3.5 及更高版本
型別：Member-of-groups 容器，配對佔位符引數和asset-group kuids 的列表。
欄位定義：此資產所屬的KIND_Asset-group 資產列表。有關如何以及何時使用它的詳細資訊，請參閱kind KIND Asset-group 文件。

容器儲存一個 KIND Asset-group KUID 的常規列表。此包含宣告，此後，尤其是在搜尋操作（包括指令碼介面和 TrainzUtil）中，此資產將被視為每個列出的資產組的成員。

如果給定“member-of-groups”容器未指定任何條目，或者如果資產省略了“member-of-groups”容器，則模擬器軟體可能會根據資產的 Config.txt 檔案指定一些預設資產組。確切的行為可能會在模擬器的不同版本之間發生變化，但是當前的邏輯在這裡進行了描述。 

可選的已棄用標籤

[編輯 | 編輯原始碼]
以下標籤對任何資產都不是強制性的，許多資產將它們留空。
從歷史上看，標識和許可標籤從 Trainz 0.9（Beta）開始。

 

許可證

[編輯 | 編輯原始碼]
型別：UTF-8 多行字串。（已由程式設計師法令棄用。）
欄位定義：一個許可證，描述資產建立者希望如何使用此資產。最常見的是許可證宣告，禁止在任何付費路線、依賴資產（例如轉向架、耦合器等火車部件）或重製皮膚中使用受版權保護的資產，包括在任何付費運營的網站上分發資產。（從理論上講，即使是 DLS 也是如此。FCT 費用用於更快地訪問和無限下載，而不是用於訪問資產。）
許可證標籤的含義不明確，N3V 不推薦使用它，但它的存在早於 N3V 的管理 6-7 年。
上傳到下載站或用於包含在遊戲中的內容可能受特定再分配合同或許可協議的約束，該協議取代此欄位中的任何文字。許可證欄位不提供本地化支援。許可證欄位的文字未經 Auran 或 N3V 驗證或執行，可能具有法律約束力也可能不具有法律約束力。
另一方面，Planet Auran 的歷史表明，有人透過將他人內容作為自己的內容來侵犯版權，可能會導致從 Auran 網站快速禁止，並永久封鎖下載站許可權等等。此外，社群將嚴厲打擊其他使用者侵犯他人的版權，並且會排斥違規者並忽略 DLS 上允許保留的任何資產。
總之，對於試圖攀登陡峭的內容創作學習曲線的 Trainzer 來說，實驗和修改資產是一種被接受的，甚至是被認可的生活方式（每個人都想要更多內容建立者！），但是如果資產有依賴部分，尤其是網格、指令碼、紋理，這些都是智慧財產權——在上傳你的創作之前，請獲得使用屬於他人的這些部分的許可。
由“kuid 引用”指定的資產部分並不打算涵蓋此宣告——使用常見的耦合器、轉向架或基本火車車網格（Auran 鑄造了幾個標準型別，許多作者預設使用這些型別，透過對網格進行 kuid 引用，例如檢查貨車的依賴項（英國：覆蓋貨車或廂式貨車）——很可能超過一半使用對 Auran 在 Trainz 1.0 中釋出的基本網格的 kuid 引用！）


 

作者標籤

[編輯 | 編輯原始碼]
型別：UTF-8 字串。（已棄用，取而代之的是可更新的Planet Auran 資料庫。）
欄位定義：作者的姓名或標記。不推薦使用此欄位，因為歸屬可以透過程式設計方式確定。

 

組織標籤

[編輯 | 編輯原始碼]
注意英國拼寫，北美拼寫“organization”也行得通！
型別：UTF-8 字串。（已棄用，取而代之的是可更新的Planet Auran 資料庫。）
欄位定義：負責建立此資產的組織的名稱或標記。不推薦使用此欄位，因為歸屬可以透過程式設計方式確定。

 

聯絡電子郵件標籤

[編輯 | 編輯原始碼]
型別：字串，電子郵件地址。（已棄用，取而代之的是可更新的Planet Auran 資料庫。）
欄位定義：此資產建立者的聯絡電子郵件地址。不推薦使用此欄位，因為歸屬可以透過程式設計方式確定，並且可以根據建立者的Auran 帳戶 Planet Auran 帳戶註冊聯絡方式，在那裡可以根據需要限制或更新聯絡方式。

 

聯絡網站標籤

[編輯 | 編輯原始碼]
型別： URL 字串。 (已棄用，建議使用可更新的 Planet Auran 資料庫。)
欄位定義： 此資產建立者的聯絡網站。 不建議使用此欄位，因為歸屬資訊可以透過程式設計確定，並且可以針對建立者的 [聯絡方式] 在 Auran 帳戶 Planet Auran 帳戶 中進行註冊，在那裡可以根據需要對其進行限制或更新。

 

已棄用標籤

[編輯 | 編輯原始碼]
以下“標籤列表”為“事實上的”，因為它們的“使用約定”先於上述列出的 TBS 標籤的正式彙編，但並非先於使用它們的規範，事實上，也先於 TrainzBaseSpec 術語的創造（於 2008-2009 年隨著 TrainzOnline Wiki 出現），或者它在 N3V Wiki 頁面 中的正式定義，2009 年 5 月 12 日 11:32 [4].


 

  • 在最初的編譯之後，一些在舊版資料模型中發現的常見但現在已過時的標籤已在下面新增，例如在許多橋樑資產中發現的 bendy 及其下方的朋友。

 

編輯者注： 這些“TrainzBaseSpec 標籤”在某些情況下由於程式設計師的命令而過時，尤其是在 TB V2.7 中（主要與機車種類相關的那些），並且在所有情況下，在 TS2009-SP0 及其後的所有N3V Games 版本中都過時（儘管許多使用者發現它們在某些情況下很有用，但它們會給內容建立者帶來時間損失，也不能夠僅僅忽略那些在預處理操作 中不再有用的標籤），並且如果資產開啟以編輯並透過將trainz-build 標籤 提升至 V2.9 及更高版本的資料模型 進行部分升級，則會生成錯誤（錯誤訊息）：
  • 資產可以本地升級至 V2.8 或更早版本，並且通常可以正常工作，即使在經過幾代資料模型元素改進之後也是如此，然後正常執行。 以這種方式，許多資產可以設定為在 TRS2004 或 TRS2006 資料模型中執行，同時又符合 TS 版本的處理和渲染。
  • 例如，大多數 TRS 時代之前的 data model 資產（v1.0–v2.3）可以透過新增一個網格表來在 TS 版本中執行，以替換自 TS 版本以來被忽略的“資產檔名”的先前效果，以使用原始 Trainz 資料模型 的資料夾分組使用子資料夾和帶有後綴“_art”、“_body”和“_shadow”的名稱來定義路徑（其中由資產名稱加字尾定義的字串設定資產元件的路徑）。
  • 相反，具有 TBs v2.9 及更高版本的 TS 版本資產通常可以通過了解這些標籤的影響和用途，以及一些明智的修改來回溯適應，以消除 texture.txt 修飾符行（例如，AlphaHint 需要註釋掉等），這些行不被早期版本理解。


  • 資產名稱、名稱和 name-XX — V1.3–v2.8 — 在幾乎所有 v1.3-v2.0 資產的歷史記錄中都有發現。 雖然“資產名稱”一直保留到 v2.8，並且沒有引起任何抱怨，但從 v2.5 開始就不再鼓勵使用。 因此，在 v1.5 之後，資產的 config.txt 檔案中唯一需要的、想要的或認可的名稱是 使用者名稱-XX 變體。

 

資產名稱

[編輯 | 編輯原始碼]

資產名稱是 Trainz 1.x--TRS2004 時代的資產的主要資料夾名稱，並且通常是 CM 開啟檔案進行編輯時開啟的資料夾的名稱。 在這些早期的 data model 資產中，通常會發現資產名稱也用於那個早期的 Trainz 時代的 data 子資料夾系統，在火車車廂資產中，會給出子資料夾名稱“資產名稱_art'”、“資產名稱_body'”、“資產名稱_shadow'”。 在修復此類資產時，通常可以使用從資原始檔複製貼上下來的模板中的 SAR 來替換該值。 此替換通常會正確定義和連結資產的子資料夾（用於車身、陰影和圖稿），因為該早期方案中的檔名基於資產名稱標籤。 

bendy 標籤

[編輯 | 編輯原始碼]
範圍： 在 v2.9 標準之前，在 軌道或橋樑資產 中找到，當時樣條物件經歷了重大更改，成為統一的資料模型定義，在混合中放棄了幾個先前的種類，轉而使用所有樣條物件統一在 kind track 下。

 

casts-shadow 標籤

[編輯 | 編輯原始碼]
參見上面的 bendy，已棄用/過時的 TS2009 之前遺留的 kind track 標籤。

 

name 和 name-XX 標籤

[編輯 | 編輯原始碼]
  • 'name' 和 'name-XX' 是早期 data model 中的更長的 使用者名稱 和 使用者名稱-XX 標籤的形式，XX 代表英語“name 標籤”（或今天的“使用者名稱”標籤）的非英語語言翻譯的 ISO 雙字母后綴。 “XX”形式與 description-XX 一樣，是“本地化”支援其他語言的友好值的組成部分。
  • 在最古老的 Trainz 時代（v1.0-v2.4）資產中，將 name 和 name-XX 替換為使用者名稱和使用者名稱-XX，或者如果存在使用者名稱，則直接刪除。
    • 如果資產的trainz-build 版本為 v2.7 或更高，name-XX 會導致錯誤。 有趣的是，即使在 TS12 這樣的版本中，name-XX 標籤也會在 Surveyor 工具的搜尋列表中顯示為資產名稱，如果不存在，則會顯示 TrainzBaseSpec。

 

注意：使用者名稱（英語）是 DLS 上的官方資產名稱，不應使用外語；在 TB v2.5 之後（TRS2006-SP0），它還會在 CM 開啟資料夾進行編輯時取代和替換“資產名稱”。

根據慣例，子資料夾名稱將具有以使用者名稱/資產名稱欄位開頭的路徑規範名稱，並使用 _art、_body 和 _shadow 字尾作為正常命名約定的一部分。 這可能是 3ds Max 和 gmax 慣例遺留到 Trainz 中的，該慣例與圖形開發軟體有著歷史淵源。（Gmax 與 Trainz 版本 V0.9—v2.4 捆綁在一起。）


 

category-era-nn 標籤

[編輯 | 編輯原始碼]
被 category-era 標籤 取代
  • category-era-nn — V1.3–v2.8 s.a. {tag: category-era-0, category-era-1, category-era-2, ...} — 具有數字字尾的舊的日期系統—在幾乎所有值得日期的資產的歷史記錄中都有發現，直到 TBV 2.0 （甚至在 TBV 2.8 構建的資產中發現！），當時引入了當前的 category-era 字串陣列，將這些標籤組合到 config.txt 中的一行上[註釋 12]。 雖然在 Surveyor 中無法直接訪問，但在 TR06 和 CMP 之後，可以定義一個過濾器來選擇日期範圍，並在 Surveyor 中使用該過濾器以及區域和型別來篩選可在 Surveyor 的放置和選擇工具中列出的資產。 在 TS09 及其後續版本中已棄用，TS09 使用更短的 category-era 標籤 字串陣列 在一行中，而不是使用多個帶“-nn”字尾的標籤-值對。
  • 字串陣列中的空格會導致錯誤；所有值必須以“s”結尾，並且具有四位數字，例如 1880s;1950s;2010s（這可能完全適合某些型別的女性服裝，這些服裝會流行起來，然後又會過時！）。 遺憾的是，目前無法定義範圍，但使用者社群已提出請求。
  • 用字串陣列型別 category-era 標籤 替換，沒有空格，日期程式碼之間用分號隔開。 這些日期程式碼用完整的四位數的年代數字加“s”（小寫字母 Ess）字尾表示。

 

category-region-nn 標籤

[編輯 | 編輯原始碼]
被 category-region 標籤 取代
  • 型別 category-region-nn — V1.3–v2.8 — 在幾乎所有符合區域設定的資產的歷史記錄中都有發現。 這些標籤已經被 category-region 標籤中的“字串陣列”形式的兩位字母列舉的 ISO 國家程式碼 取代。
  • 用字串陣列型別替換 category-region，在引用的標籤部分列出的兩個字元的國家程式碼之間沒有空格和分號；這些程式碼作為完整的兩個大寫字母給出，包含 列舉的 程式碼，後面跟著程式碼之間的“;”分隔符，但在最後一個程式碼之前的尾部引號之前沒有分隔符。
  • 字串陣列中的任何 空格 都會導致讀取錯誤和故障訊息，包括尾部引號之前的空格。

 

  • region — TBS V1.3–v2.8 的有效部分，作為內建過濾器和地圖資產自定義本地化識別符號（kuid）；現在唯一合法的標籤用法是在 kind map（佈局）資產中。
作為以前的過濾器修飾符，該標籤在歷史上幾乎所有資產中都可以找到，但它在滾動庫存、風景、樣條資產、軌道型別（包括隧道和橋樑）以及具有某種程度本地化的路邊資產中尤其普遍。
  • 地圖資產仍然保留了在“地圖配置”中定義的關鍵字“Region”，它具有相反的用途——成為 kind region kuid 引用。因此，Region 在 Maps 中是必需的，並且自從 TS2012 以來，就像標籤型別一樣，在曾經作為 TRS 系列版本 Surveyor 工具的“分組資料”“快速過濾器”出現的數量非常多的資產中是非法的。
  • 在 TRS2009 之後，任何 region 標籤到文字字串都已過時，因為在程式設計師的眼中，他們用 Pick List 替換了 Surveyor 工具中“型別和區域”字串值的粗略過濾組選擇器。這兩個標籤都有一些優點和缺點，並且都追溯到 Trainz 0.9 Beta 版本。

 

shadows 標籤

[edit | edit source]
見上面的 bendy，在 TS2009 之前的遺留 kind track 資產模式控制標籤已棄用/過時。

 

thumbnail 標籤

[edit | edit source]

thumbnail 標籤是 thumbnails container 的早期單檢視實現（上面也有簡要說明）。Trainz 的早期 N3V 之前的程式設計師版本將在主資產根資料夾或 asset-name_art 或 asset-name_body 資料夾中找到一個 .jpg 檔案，最好大小為 240x180 畫素，並將其用於在 CMP 和 DLS 中顯示資產（如果它已上傳）。該標籤在 TRS2006 期間已棄用，因為 thumbnails container 是從 v2.0（TRS2004-SP0）開始引入的。在舊的修復資產中，如果 TBV 保持在 v2.4 以下，那麼縮圖通常仍然可以在更新的 CM 中工作，前提是它在 _art 子資料夾中，並且資產名稱與使用者名稱匹配。 

type 標籤

[edit | edit source]
  • type — V1.3–v2.8 —以前是一個過濾器修飾符，在歷史上幾乎所有資產中都可以找到，但它在滾動庫存、風景、樣條、軌道型別（包括隧道和橋樑）以及路邊資產中尤其普遍。
  • type 標籤與“region 標籤”一樣，在 Trainz 0.9—TC3 版本中用作“在 Surveyor 中進行分組過濾”，它與 region 相結合，提供了更小的資產選擇（工具組）。自從 TS2009 移除了這些本地可單擊過濾器並改為使用新的、更繁瑣的過濾器，這些過濾器使工具選擇變得快速而簡單，而不是在工具選項卡之間切換時變得緩慢和暫停——如今的 TANE 之前的版本在工具選項卡之間來回切換時，通常會因重新載入整個選擇列表而感到不堪重負。
  • type 和 region 都預設為“All”，與 TS09 及其後的版本中的工具一樣，提供相同的超級列表。
  • TRS2006 衍生版（即 TC3）之後，每個 type 標籤都已過時，因為在程式設計師的眼中，他們用 TS09 Pick List 和過濾器替換了 Surveyor 工具中“型別和區域”的粗略過濾組選擇器——沒有為使用者提供儲存多個 Pick List 或輕鬆載入在 CM 中定義和細化的過濾器的功能。

 

註釋

[edit | edit source]
  1. ↑ 資產 提交（TANE 的提交）是將內容合併到資料庫中並將其在 DB 索引中交叉引用的過程和步驟，以便可以在執行時模組中訪問它。
  2. ↑ 驗證資產的一種方法是，除了這些值之外，其他方面都正常，方法是將 TBV 降低到 2.5-3.7 範圍，看看這些訊息是否消失。您可能需要降低幾次嘗試，直到足夠低，反之亦然，在舊的 TBV 中無法識別的較新關鍵字可能會發出不同的錯誤訊息。不要害怕嘗試，即使失敗也會產生知識和經驗，而且您不會破壞任何東西！如果是這樣，您可以確信僅提供一個值就是解決問題的方法。通常，一些現代需求只需要關鍵字對，因此在標籤後面加上空白行或在標籤後面加上空的花括號，就可以滿足容器的需求，在錯誤測試中，這種測試過於嚴格。
  3. ↑ 注意：此列表在 N3V TrainzOnline Wiki 上進行了“維基化”，這意味著在“KIND”一詞之後第一個字母已大寫，而 config.txt 檔案中的實際資料標籤名稱是全部小寫文字。該維基還使用雙引號來表示一些術語，我們將在本文中避免這種做法。
  4. ↑ “kind consist”並不經常直接看到，它只存在於選單和內容管理器列表中。
  5. ↑ 必須謹慎使用 obsolete-table，它最常在 Auran 編寫的資產中看到。該表用更新的版本替換了舊的 kuid，大多數內容創作者正確地使用 kuid 的 Kuid2 形式來取代舊版本。相反，N3V 過度使用 obsolete-table 來升級新版本“升級”的內建資產，這會導致很多混亂，並且無法獲得預期看到的內容。（例如，許多不錯的“Flip-trees”在 TS10 和 TS12 中已過時，取而代之的是 Speedtrees，這影響了許多路線，在這些路線中，Speedtrees 並非創作者的意願或期望。在跨安裝中，這還會導致缺少依賴項，直到找到包含 obsolete-table 的資產。
  6. ↑ 最近將過時的資產匯入 TANE 的經驗表明，至少有五個替代 kuid 替換了那個可憐的 Flip-tree 資產。似乎由於 Speedtrees 的引入帶來的混亂以及 TANE 在積極追求最適合的更新資產方面進行了徹底改革，現在 ContentManager 程序中容忍多個不同 kuid 的資產替換相同的 kuid。作為一種良好的做法，僅在絕對必要時才使用 obsolete-table... 例如，用您想上傳到 DLS 或在網站上自行釋出的依賴資產中不需要的付費資產替換該資產。
  7. ↑ 關於 category 時代的標籤範圍：安全的遊戲，已知有效。其他“未來十年”值應在依賴這些值之前進行測試。
  8. ↑ 許多容器在列表中使用虛擬/佔位符名稱。這些可以是描述性詞語，只要它們不包含空格字元即可。在短語構造的名稱中使用下劃線或句點可以保留可讀性並顯著提高畫質晰度。例如，貨運車廂可能裝載 45 種合法產品型別。這些將在依賴項容器中列出。使用 Coal, granite,crushed_limestone 等可以更輕鬆地維護和更改表格。Jes Sayin 是從 76 年開始的程式設計師
  9. ↑ 在第二個 thumbnails 容器示例中，還有一個 512x512 大小的影像，一個 extra。DLS 將使用哪個尚不清楚。還可以包含更大的影像尺寸，並且透過電子郵件聊天，T:ANE 可能支援更大的影像尺寸，這將在預覽操作或 DLS 列表中得到應用。N3V Games 通常不會發布此類資訊。
  10. ↑ 早期的做法可以追溯到 Trainz 1.x，使用關鍵字/標籤“thumb”以及帶引號的路徑規範引用 240x180 的縮圖。art 資料夾包含一個 512x512 的帶有 alpha 遮罩的 tga（通常是 bmp 檔案，但格式正確的 tga 可以用作自 alpha 遮罩），以及 64x128 的選單圖示影像及其控制的 texture.txt 檔案。
  11. ↑ 在 2014 年至 2015 年冬季與前版本經理 James Moody 的私人電子郵件交流中，關於此主題的重點是 DLS 上傳審查軟體可能已被更改，以強制執行正確的縮圖容器。
  12. ↑ 關於 category-era-nn 與 category-era 標籤值：TRS 將接受任何形式的 category-era 資料；但是 TS2009-SP0 及更高版本從以前合法關鍵字-值對建立了錯誤，並試圖強迫內容建立者更改程式設計師故意破壞的所有資產。 後來 DLS 上傳軟體強制執行了轉換，但這更可接受，因為第一個操作會導致許多人為修復工作而浪費時間，而這些修復是不必要的，應該在審查較舊 Trainz 版本的資產時，在軟體預過濾過程中自動實施。 這些操作幾乎保證了較舊資產的下載會出現故障。 這是 N3V 程式設計師所做的最愚蠢、最傲慢的事情之一，而 Auran 更經驗豐富的軟體人員絕不會如此輕率地對待社群的時間成本。

參考文獻

[edit | edit source]
  • 本頁面主體內容摘自 N3V TrainzOnline Wiki，來自 KIND_TrainzBaseSpec。 增強資訊由 Yesterdayz-Trainz 使用者組成員新增。

腳註

[edit | edit source]
  1. ↑ N3V 的 KIND_TrainzBaseSpec，作為未經修改的源頁面，缺少此處找到的歷史資訊（標籤）；訪問日期 = 2014 年夏季
  2. ↑ a b "Trainz-build" 標籤 直接連結
  3. ↑ 根據 fabartus 的說法，2014 年夏季；很可能是在新增此示例的同一天。
  4. ↑ Christoph Bergman，N3V Games 首席程式設計師，又名“Windwalkr”，KIND TrainzBaseSpec 歷史 頁面。
本參考頁面改編自 TrainzOnline Wiki，根據 CC-BY-SA 3.0 許可。 此頁面可能會包含比 同一主題的源頁面 更多文字解釋、闡述、歷史和/或示例。
TrainzOnline Wiki 主要由程式設計師或知識淵博的 內容建立者 維護，可能包含有關當前 trainz-build 程式碼 標準的更新資訊，這些標準隨著軟體功能的新增而有所變化。



檢索自 "https://wikibook.tw/w/index.php?title=Trainz/refs/TrainzBaseSpec&oldid=4409651"
華夏公益教科書