跳轉到內容

Trainz/refs/TrainzBaseSpec

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


KIND 繼承體系簡介

[編輯 | 編輯原始碼]

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

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

父類

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

在 TANE 之後的版本中，許多相同的“昨天預設”定義行今天將更有可能產生故障，要求明確的數值定義，而這些數值在過去載入時是預設的。 [註釋 2]與過去的日子相比，這是一種更令人愉快的困擾，那時有缺陷的資產定義有時會導致臭名昭著的“藍色畫面宕機”或更常見的情況是，將執行時軟體崩潰到桌面，導致編輯丟失，並且可能需要重建資料庫。

子類

[編輯 | 編輯原始碼]

所有 Trainz 定義資料（內容）都包含三個必備元素：一個config.txt 檔案 用於組織資料、一個身份（即kuid，使用者名稱本身對你沒有用，但是可以建立一個合法資產，它沒有名稱！）、最後是一個合法定義的 kind 標籤。kind 負責指揮，是樂隊的指揮家、排長或 CEO 給出指示——為處理之後的所有內容設定要求。簡而言之，kind 的值，一個小的、緊密定義的、僅限成員的組——告訴 Trainz 軟體在虛擬世界中要渲染和顯示什麼內容，以及如何（或在哪裡）找到在該 config.txt 檔案中將資產的這些部分連結在一起所需的其他部分。
  下面的每個子類都被認為是具有TrainzBaseSpec 作為其資料“父類”。[註釋 3]下面列出的幾個 kind，那些帶下劃線的 kind，是早於Trainz 資料模型在TS2009 釋出（即 2008 年後期）中更改的遺留 kind，並且自 N3V 程式設計師實施了這些更改以來，這些更改只是逐步（增量）實施的。
  目前可以在 N3V Trainz Wiki TrainzOnline 網站此處 的內容建立者指南 部分中找到修復基於這些遺留 kind 的資產的詳細資訊，並提供了遺留 kind 的示例此處。強烈建議所有Trainz 下載站的使用者或任何考慮建立內容的使用者仔細閱讀 CCG。通過了解舊內容是如何定義的背景歷史，然後可以將這些資訊與當前 TrainzOnline 對相同資料型別的覆蓋進行對比和比較，因為通常這種“那時與現在”的比較可以為修復、更改和定製資產提供有價值的見解。更重要的是，CCG 中的文字是由專業人員撰寫的，而且更加贅述——它經常會讓你瞭解如果改變了這個或那個內容會產生哪些擴充套件效果，而 Trainz Wiki 就沒有提供這些資訊。在 TrainzOnline 上釋出的 CCG 是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 (容器)

  { 依賴項列表
  按 kuids 分組 }

  一個鍵-值表，列出此資源所依賴的所有資源。
 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 視窗中需要使用逗號作為多個 kuids 的分隔符。將資料聚合在完整的 kuid 標籤結束括號中通常更容易，並且通常更容易閱讀。對於剪下和貼上一個巨大的列表，緩衝區大小限制可能會中斷列表的末尾，在這種情況下，在文字編輯器中修剪掉兩個結束括號可能允許將整個列表放入 API 中。



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

 

trainz-build 標籤

[edit | edit source]
主要內容：trainz-build 標籤，縮寫：TB & TBV (TB-value)∅
型別：由 N3V [2] 列舉的一個小數點浮點數，用於跟蹤和識別與演進軟體的技術水平相對應的資料型別。
範圍：1.0–4.3 直接對應（對映onto3rd’ 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 無 Service Pack）到當前版本（v3.7 = TS12-SP1，v3.8 = Mac2，3.9=TANE-CE，4.0—4.3，從此以後？從 2016 年 3 月起，4.3 及更高版本為 TANE SP，待定。）遞增 0.1。
  • 從 v2.0 (TRS2004) 開始，Trainz-build 標籤編號值已經增加了 23 個步驟，這些步驟雖然是非單調的，但卻是連續的，因為 Trainz TS09-sp3—TS09-sp4 共享一些 Trainz-build[2] 值；也就是說，在 TS2009 和 TS2010 的聯合開發時代和版本中，有一些 TBV 共享。
  • 此外，N3V 進軍 Macintosh 計算機打斷了基於 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 之後的 trainz-build 版本（v2.7）中，當編輯資產時，使用者名稱也成為作業系統資料夾名稱，並且忽略資產檔名，而它在 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 多行字串，提供對資產的清晰語言描述。
欄位定義：此資產的英文人眼可見描述性摘要。

描述在內容管理器“資產詳細資訊”窗格中可見，用於闡明資產名稱、提供規格，以及通常的簡短歷史記錄。

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

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

description-XX 標籤

[edit | edit source]
型別：UTF-8 多行字串，描述標籤.
欄位定義：（其中XX 被替換為要表示的語言的適當 本地化程式碼。）此資產的本地化人眼可見描述性摘要。此欄位類似於描述欄位，但表示非英文區域設定。資產中可能存在多個description-XX 標籤，每個支援的區域設定一個。如果適當的“description-XX”標籤不存在以在給定終端使用者系統上表示此資產，則使用英文描述標籤。

 

字串表容器

[edit | edit source]
型別：UTF-8 字串列表容器，字串表容器(s).
欄位定義：一個鍵值對列表，包含英文字串。每個鍵是與二進位制資料對映並引用的有意義的指令碼識別符號。每個值都是一個英文字串。英文字串可能包含或引用非英文專有名詞作為識別符號。非英語母語的作者如果需要，仍然需要建立一個沒有後綴的字串表容器。軟體只連結並引用字串表容器中沒有後綴的名稱和值，這會讓西班牙語、法語、德語、捷克語、荷蘭語...日語作者感到非常困擾。換句話說，帶字尾的字串表僅僅是為了翻譯目的而存在的，這在非英語語言編寫地圖時會造成問題，因為沒有“string-table-en”來提供反向翻譯的表格。同樣，username-en和description-en也是如此。這三者的缺失都體現了一種過時而傲慢的態度，以及對世界動態的漠不關心。

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

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

 

string-table-XX 容器

[edit | edit source]
型別：UTF-8 字串列表容器，本地化字串表，每個字尾對應除英語以外的語言。
欄位定義：（其中XX被替換為代表的語言的適當本地化程式碼。）此欄位類似於string-table欄位，但代表非英語語言環境。

英文字串表（無後綴）是強制性的，其他本地化語言是可選的，由資源作者決定。許多提交給 DLS 並在 Trainz 版本附帶的路線中使用的資源通常會翻譯成多種語言，並具有完整的本地化翻譯，用於 description-XX 和字串表。特別是，與版本捆綁在一起的路線和會話在每個零售版本中都會被專業翻譯成多種語言。

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

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

kuid-table 容器

[edit | edit source]

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-table。大多數具有子元件的資源只有幾個。
  • 其次，由於內部關鍵字有時是“自動定義”的，因此只列出一個沒有名稱的數字，作為佔位符引數，偽關鍵字可以是任何唯一值（通常是零索引的連續整數。[註釋 1]）。使用者或作者可以根據需要為它們命名。
  • 此表中的條目有兩個目的
    ‌ 首先：確保遊戲系統瞭解依賴項，以便安裝和載入此資源將成功安裝和載入任何依賴項，以及
    ‌ 其次：允許指令碼定位相關的子資源。
  • kuid-table 中只包含一級依賴項——具有自身依賴項的子資源或部件資源將在該子資源的驗證和資料庫提交過程中進行處理。
  • 迴圈依賴關係是非法的。
  • 如果一個資源也被標記為此資源的過時版本，則不能將其列為依賴項。（在 Trainz 資源索引（歷史上的 assets.tdx 檔案）中的 kuid 中只有一個替換 kuid 槽，這將建立一個迴圈定義，要求使用它本身的舊版本！）
  • 同樣，一個資源不能將其自身列為其自身的依賴項。[另一方面，這已經體驗過（即在 TSxx CMs 中作為成功無故障提交的資源被見證過），在安裝之間使用 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-table 將使新或老手 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>

} ...

注意連線單詞的下劃線... 兩個符號，鍵和值！我們讓學生弄清楚在哪裡將 kuids 新增到載入和允許的產品隊列表條目中。（歡迎你，但這確實是一個改變名稱的好理由！保持思路清晰幾乎是製作資產的全部戰鬥！）  

obsolete-table 容器

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

 

category-region 標籤

[編輯 | 編輯原始碼]
目的：CM 和 Surveyor 中的過濾器（搜尋條件）
型別：列舉字串或字串陣列。
欄位定義：一個由分號 (;) 分隔的雙字元 類別區域標籤 程式碼列表。字串中不應出現其他字元（包括空格等）。此資產被認為與每個指定的區域相關 - 這與 火車車組 和 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"（大多數第一世界國家）

 

類別-類別標籤

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


 

請注意，許多類別類別程式碼只與特定資產類別相關 - 必須不要將類別類別程式碼應用於不適當類別的資產。

示例
    category-class "XBG" 箱形車 - 來自 PRR 60'
    category-class "BR" 鐵路（風景非功能性） - 可能是一座建築
    category-class "BIN" 具有產品處理功能的工業資產

 

類別-年代標籤

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

 

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

 

縮圖容器

[編輯 | 編輯原始碼]
目的：CM 和 Surveyor 中的過濾器（搜尋條件）
型別：縮圖容器。
欄位定義：在整個遊戲環境中（包括在遊戲中、在 內容管理器 中以及在 下載站 上）用於在 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 檔案，而是在 '_art' 子資料夾中列出了 .tga 檔案（Targa True Color）（Trainz 1.0—TC3 慣例：_art、_body 和 _shadow 是由早期 Trainz 資料模型要求命名的三個子資料夾，名為“資產檔名字尾”（過時的標籤-<值> 對），看起來如下[註釋 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 修補程式放棄了這種做法。
 • 如果缺少縮圖容器的資產（即使使用過時的 thumb 標籤）後來在新的內建路線或會話中被選中，該資產通常將被分發為沒有影像的專案 - 如果 texture.txt 或 config.txt 縮圖容器沒有正確引用，它們將被剝離出去。[註釋 11].  

軟體連結

[編輯 | 編輯原始碼]

info-url 標籤

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

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

這在 Driver 中非常有價值，可以訪問路線圖、指南或會話說明或澄清。

建議在任何情況下，對於提供類似功能但外觀略有不同的資產類別，都使用通用組頁面。這減少了建立、維護和本地化此類文件的時間成本。

 

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) 重新儲存對資產的任何更改（提交（提交）重新驗證的資產到資料庫）。

 

指令碼標籤

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

 

類標籤

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

 

script-include-table 容器

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

The script-include-table 容器 是任何從 KIND TrainzBaseSpec 派生的資產（簡而言之，所有資產）可用的頂級config.txt 檔案 條目。此容器允許資產使用 包含另一個資產的指令碼 來自父資產的指令碼檔案，使用 N3V TrainzScript 的 Script_Include_Directive.

相關

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

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

[編輯 | 編輯原始碼]

此容器是指令碼化資產的名稱及其 kuids 的簡單鍵值表，這些指令碼化資產在編譯資產的指令碼檔案時會搜尋以查詢指令碼包含。鍵或標籤名稱目前未使用（即為佔位符引數）用於搜尋；值指示要包含的資產的 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 保留根據擴充套件建立者的指南，在以後日期新增對擴充套件容器 中特定條目的驗證的權利。

 

更新且不太常見

[編輯 | 編輯原始碼]

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

category-keyword 標籤

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

 

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

custom-category-list

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

 

member-of-groups 容器

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

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

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

可選的已棄用標籤

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

 

license

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


 

author 標籤

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

 

organisation 標籤

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

 

contact-email 標籤

[編輯 | 編輯原始碼]
型別：字串，電子郵件地址。（被可更新的Planet Auran 資料庫 棄用。）
欄位定義：此資產建立者的聯絡電子郵件地址。不建議使用此欄位，因為可以透過程式設計方式確定歸屬，並且可以針對建立者的Auran 賬戶 Planet Auran 賬戶 註冊聯絡方式，以便在必要時對其進行限制或更新。

 

contact-website 標籤

[編輯 | 編輯原始碼]
型別：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) 可以透過新增一個 mesh-table 來在 TS 版本中正常工作，以替換自 TS 版本以來被忽略的 'asset-filename' 的前者效果，使用原始 Trainz data model 的資料夾分組定義路徑，使用帶有後綴 '_art'、'_body' 和 '_shadow' 的子資料夾和名稱（其中由資產名稱加字尾定義的字串設定了資產元件的路徑。
  • 反過來，帶有 TBs v2.9 及更高版本的 TS 版本資產通常可以通過了解這些標籤的效果和用途以及對 texture.txt 修改器行進行一些明智的修改來進行反向改裝，以便在早期版本中使用，以消除 texture.txt 修改器行（例如，AlphaHint 需要註釋掉，等等）。


  • asset-name、name 和 name-XX — V1.3–v2.8 —歷史上存在於幾乎所有 v1.3-v2.0 資產中。而 'asset-name' 在 v2.8 之前一直被保留，沒有引起任何抱怨，但在 v2.5 之後已不再被鼓勵；因此，在 v1.5 之後，資產的 config.txt 檔案中唯一需要、想要或認可的名稱是 username-XX 變體。

 

Asset-name

[edit | edit source]

Asset-name 是 Trainz 1.x--TRS2004 Trainz 時代的主要資料夾名稱，並且通常是 CM 開啟檔案進行編輯時開啟的資料夾的名稱；在這些早期的 data model 資產中，通常會發現 asset-name 也被用於早期 Trainz 時代的 data 子資料夾系統，在火車車廂資產中給出子資料夾名稱 'asset-name_art'、'asset-name_body'、'asset-name_shadow'。在修復這些資產時，通常可以使用從資原始檔複製和貼上下來的樣板檔案中的 SAR 替換該值。此替換通常會正確定義和連結資產的子資料夾（用於主體、陰影和藝術作品），因為早期方案中的檔名基於 asset-name 標籤。 

bendy 標籤

[edit | edit source]
範圍：存在於 v2.9 標準之前的 軌道或橋樑資產 中，當時樣條物件經歷了重大更改，以統一資料模型定義，放棄了混合中的幾個先前的 KIND，而有利於將所有樣條物件統一到 kind track 下。

 

casts-shadow 標籤

[edit | edit source]
參見上面的 bendy，已棄用/過時的 TS2009 之前遺留的 kind track 標籤。

 

name 和 name-XX 標籤

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

 

注意：Username（英文）是 DLS 上的官方資產名稱，永遠不應該使用外語；在 TB v2.5 (TRS2006-SP0 之後，它也取代和替換了 CM 開啟資料夾進行編輯時的 'asset-name'。

按照慣例，子資料夾名稱將以 username/asset-name 欄位開頭，並使用 _art、_body 和 _shadow 作為字尾作為正常命名約定的一部分。這可能是 3ds Max 和 gmax 的約定，延續到 Trainz 中，Trainz 與該圖形開發軟體有歷史聯絡。（Gmax 與 Trainz 版本 V0.9—v2.4 捆綁在一起）


 

category-era-nn 標籤

[edit | edit source]
被 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 行上[note 12]。雖然在 Surveyor 中無法直接訪問，但在 TR06 和 CMP 之後，可以定義一個過濾器來選擇一個日期範圍，並使用該過濾器以及區域和型別在 Surveyor 中驗證 Surveyor 的放置和選擇工具中可列出的資產。在 TS09 中被廢棄，TS09 使用較短的 category-era 標籤 字串陣列 放在一行中，而不是使用多個帶 '-nn' 字尾的標籤-值對。
  • 字串陣列中的空格會導致錯誤；所有值必須以 's' 結尾，幷包含四個數字，例如 1880s;1950s;2010s（這可能完全適用於某種型別的女性服裝，這種服裝會流行起來和過時！）。定義一個範圍目前還不可行，但已被使用者社群要求。
  • 用字串陣列型別的 category-era 標籤 替換，沒有空格，日期程式碼之間用分號分隔；這些程式碼以完整的四位數年代數字加 's'（小寫字母 s）字尾的形式給出。

 

category-region-nn 標籤

[edit | edit source]
被 category-region 標籤 取代
  • 型別 category-region-nn — V1.3–v2.8 —歷史上存在於幾乎所有值得本地化的資產中。它們已被 category-region 標籤中的由兩個字母組成的列舉 ISO 國家程式碼的“字串陣列” 取代。
  • 用字串陣列型別的 category-region 替換，沒有空格，列舉的兩位大寫字母國家程式碼之間用分號分隔，但在最後一個程式碼之前不使用分號，直到末尾引號之前。
  • 字串陣列中的任何 空格 都會導致讀取錯誤和錯誤訊息，包括末尾引號之前的空格。

 

  • region —作為 TBS V1.3–v2.8 的有效部分，作為內建過濾器和地圖資產自定義本地化識別符號（kuid）；現在唯一合法的標籤使用是在 kind map（佈局）資產中。
作為以前的過濾器修飾符，該標籤歷史上存在於幾乎所有資產中，但它在滾動庫存、場景、樣條資產、軌道型別（包括隧道和橋樑）以及具有某種程度本地化的軌道旁資產中尤為普遍。
  • 地圖資源仍然保留了在“地圖配置”中定義的關鍵字“Region”，但其使用方式卻與之相反——它是一個區域型別kuid 引用。因此，地圖中需要“Region”，而自TS2012開始，就像標籤型別一樣，“Region”在大量的資源中被禁止使用，這些資源曾經將其用作TRS系列版本Surveyor工具視窗中的“分組資料”和“快速篩選”功能。
  • 在TRS2009之後，任何將“region”標籤與文字字串關聯的行為都已過時，因為在程式設計師看來，他們用選擇列表取代了Surveyor工具中“型別和區域”字串值的粗略篩選組選擇器。這兩個標籤都有一些優缺點，它們都可以追溯到Trainz 0.9 Beta版本。

 

shadows 標籤

[編輯 | 編輯原始碼]
參見上面的彎道，在TS2009之前已過時/廢棄的傳統軌道型別資源模式控制標籤。

 

thumbnail 標籤

[編輯 | 編輯原始碼]

“thumbnail”標籤是縮圖容器的早期單檢視實現（在上面也有簡要說明）。Trainz 的早期版本（在N3V程式設計師之前）會在資源主根資料夾或“資源名稱_art”或“資源名稱_body”資料夾中找到一個.jpg檔案，並將其大小設定為240x180畫素，用於在CMP和DLS中顯示資源（如果上傳的話）。自TRS2006開始，“thumbnail”標籤已過時，因為縮圖容器在v2.0（TRS2004-SP0）中引入。在舊的修復後的資源中，如果TBV保持在v2.4以下，則縮圖通常仍然可以在較新的CM中工作，前提是它位於“_art”子資料夾中，並且資源名稱與使用者名稱匹配。 

type 標籤

[編輯 | 編輯原始碼]
  • type — V1.3–v2.8 —以前的一種篩選修飾符，在歷史上幾乎所有資源中都存在，但特別是在滾動庫存、景觀、脊樑、軌道型別（包括隧道和橋樑）以及軌道旁資源中非常普遍。
  • “type”標籤與“region”標籤一樣，在Trainz 0.9—TC3版本中用作“Surveyor中的組篩選器”，它與“region”結合，提供了較小的資源選擇（工具組）。自TS2009開始，取消了這些本地可點選篩選器的功能和使用，轉而採用了一種新的更繁瑣的篩選器。這使得工具的選擇變得快速簡便，而不是在工具選項卡之間切換時緩慢暫停——如今的TANE之前的版本在工具選項卡之間來回切換時，往往會因重新載入整個選擇列表而感到不堪重負。
  • “type”和“region”都預設設定為“All”，提供與TS09及更高版本中工具提供的相同的大型列表。
  • 自TRS2006分支版本（即TC3）開始，所有“type”標籤都已過時，因為在程式設計師看來，他們用TS09選擇列表和篩選器取代了Surveyor工具中粗略篩選的“型別和區域”組選擇器——卻沒有賦予使用者儲存多個選擇列表或輕鬆載入在CM中定義和細化的篩選器的能力。

 

備註

[編輯 | 編輯原始碼]
  1. ↑ 資源提交（TANE的提交）是將內容納入資料庫並將其在DB索引中交叉引用以使其可以在執行時模組中訪問的過程和程式。
  2. ↑ 驗證資源的一種方法是，除了這些值之外，其他方法都正常，將TBV降低到2.5-3.7範圍內，看看這些訊息是否消失。您可能需要降低幾次嘗試，直到足夠低，反之亦然，在較舊的TBV中無法識別的較新關鍵字可能會給出不同的錯誤訊息。不要害怕嘗試，即使嘗試失敗也會產生知識和經驗，而且您不會破壞任何東西！如果是這樣，您可以確信只需提供一個值就是問題的解決方案。通常，一些現代需求只需要關鍵字對，因此在標籤後面新增一個空行或在標籤後面新增一個空的花括號集合就可以滿足需求，而錯誤測試則過於嚴格。
  3. ↑ 注意：此列表在N3V TrainzOnline Wiki上進行了“wiki化”，這意味著在“KIND”一詞之後首字母已大寫，而config.txt檔案中實際的資料標籤名稱全部為小寫文字。該wiki還在許多術語中使用了雙引號，這種做法我們將在此省略。
  4. ↑ “kind consist”並不經常直接看到，它只存在於選單和內容管理器列表中。
  5. ↑ “obsolete-table”必須謹慎使用，最常在Auran製作的資源中看到。該表用較新的版本替換了較舊的kuid，大多數內容建立者正確地使用kuid的Kuid2形式來取代舊版本。相比之下，N3V過度使用“obsolete-table”來進行新版本“升級”的內建資源，這會導致很多混亂，以及無法獲得預期看到的內容。（例如，許多漂亮的“翻轉樹”在TS10和TS12中被“Speedtrees”取代，這影響了許多路線，而建立者在這些路線中並不想要或需要Speedtrees。在跨安裝過程中，這也會導致依賴項缺失，直到找到包含“obsolete-table”的資源。 • 此外，在Assets.tdx資料庫索引中，每個kuid只支援一個過時條目，而用Kuid2版本取代kuid會導致問題（例如，您會看到哪個？） • “obsolete-table”的一個很好的用法是使用特定零件（尤其是轉向架）升級一系列資源。新增一系列kuid，並用較新的好的轉向架來替換它們，可以顯著改善路線或會話的外觀（前提是轉向架（例如）相容並且尺寸合適！)
  6. ↑ 最近使用一個過時的資源匯入TANE的經驗表明，有五種不同的kuid來取代那個可憐的“翻轉樹資源”。隨著Speedtrees的引入以及TANE的大修（積極追求最適合更新的資源），在ContentManager程序中，現在容忍了多個不同kuid的資源來取代同一個kuid，這似乎造成了混亂。作為最佳實踐，只在絕對必要時使用“obsolete-table”...例如，用您想要上傳到DLS或在網站上自發布的依賴資源中，取代一個不想要的付費資源。
  7. ↑ 關於類別時代標籤範圍：安全播放，已知有效。其他“未來十年”值應在依賴於此之前進行測試。
  8. ↑ 許多容器在列表中使用虛擬/佔位符名稱。這些可以是描述性詞語，只要它們不包含空格字元。在短語構造的名稱中使用下劃線或句點可以保留可讀性並顯著增強清晰度。例如，一個貨運車廂可能裝載45種合法產品型別。這些將在依賴項容器中列出。使用Coal、granite、crushed_limestone等可以使維護和更改表變得更容易。Jes Sayin' 是一位自1976年開始的程式設計師。
  9. ↑ 在第二個縮圖容器示例中，還有一個512x512大小的影像，一個額外的影像。DLS將使用哪個影像尚不清楚。也可以包含更大的影像尺寸，透過電子郵件聊天，T:ANE可能支援一個更大的影像尺寸，該尺寸將在預覽操作或DLS列表中使用。N3V Games通常不會透露此類資訊。
  10. ↑ 早期的做法可以追溯到Trainz 1.x，當時使用關鍵字/標籤“thumb”，並在引號中使用路徑規範引用240x180的縮圖影像，用於執行時選單。art資料夾包含一個512x512的tga，帶有alpha蒙版（通常為bmp檔案，但格式正確的tga可以用作自alpha蒙版），以及64x128的選單圖示影像及其控制的texture.txt檔案。
  11. ↑ 在2014-2015年冬天與前版本經理James Moody進行的私人電子郵件交流中，關於此主題，DLS上傳驗證軟體可能已經更改，以強制執行正確的縮圖容器。
  12. ↑ 關於類別-時代-nn 與類別-時代標籤值： TRS 接受類別-時代資料兩種形式； 但 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#obsolete-table_container"
華夏公益教科書