跳轉到內容

Trainz/refs/TrainzBaseSpec

來自華夏公益教科書,開放世界開放書籍
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 構建標籤值中尤其常見,對於那些標籤,Content Manager 或 Content Creator Plus (CCP) 工具將分配一個預設值,但在處理它時會列出警告訊息。TrainzOnline 維基、這裡或較舊的 TC3 時代 內容建立者指南 (CCG) 中的許多標籤將提到一個預設值。
  • 從 TRS2006 和 Trainz Classics (TC1&2) 開始,每個版本的 Content Manager 模組都施加了越來越多的預先承諾錯誤測試[note 1],並且每個版本都變得越來越堅定地提醒使用者,當它期望這樣的標籤-資料對時,這樣一個標籤尚未定義。

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

子類

[edit | edit source]

所有 Trainz 定義的資料(內容)都包含三個必需元素:一個用於組織資料的 config.txt 檔案、一個表示身份的 kuid(僅使用者名稱對你沒有用,但可以建立一個合法資產而無需名稱!),最後,一個合法定義的 kind 標籤。kind 負責管理,是樂隊的指揮、排長或 CEO 指揮方向 - 為所有後續處理的內容設定要求。簡而言之,kind 的值,一個小的、嚴格定義的、僅限成員的組 - 告訴 Trainz 軟體在我們要建立的虛擬世界中呈現和顯示什麼,以及如何在 (或在何處) 找到其他部分以使該資產的那些部分連結到該 config.txt 檔案中。
  下面的每個子類都被認為具有 TrainzBaseSpec 作為其資料的“父類”。[note 3] 下面列出的一些種類,那些帶下劃線的種類,是早於對 Trainz 資料模型 進行更改的遺留種類,這些更改是在 TS2009 釋出 (即 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(型別資產組)

 


表 I,TBS 標準定義

[編輯 | 編輯原始碼]

TBS 標準定義

[編輯原始碼]

這些標籤和容器是標準定義,幾乎所有資源中都可能找到。有些標籤是可選的,內容建立者可以根據自己的選擇來定義。標籤是關鍵詞,並且具有分配的單個鍵-值或容器,例如字串陣列'{' ... '}' 繫結封閉的標籤-值對或子容器。(在 Trainz 配置檔案中宣告的所有內容都是成對的,因為即使 '{' ... '}' 也被視為一個“鍵-值”。

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

  { 依賴項列表
 按 kuids 分組}

 一個鍵值表,列出了此資源依賴的所有資源。
 已棄用-table (容器)
    {
    }
 kuids 列出了此資源取代的資源(已棄用)
 通常為空(空)[註釋 5]
 字串-table (容器)
    {
    }
 資源中使用的字串和訊息的鍵值列表
通常為空,在路線和場景中很大。
 字串-table (容器)
    {  非英語
    語言文字 }
 翻譯字串列表,匹配到強制性的英語字串-table
 類別-地區標籤 列舉 程式碼  類別-地區 "'字串陣列'"  
 類別-分類標籤  類別-分類 "'列舉 字串值'
 類別-年代標籤  類別-年代 "'受限字串陣列'"  年代
 類別-關鍵詞 "'字串陣列'" 最大長度為 64 位元組    類別-關鍵詞標籤 自然語言搜尋關鍵詞
  (取代型別、地區)
 自定義-類別-列表 
 "'字串陣列'"
 指令碼介面功能
 必須擁有產品權利 
 "'字串值'"  
 DRM 字串陣列
 不能擁有產品權利 
 "'字串值'"  
 DRM 字串陣列
 許可權 (容器)
    {
    }
 更多 DRM
 縮圖 (容器)
    {
    }
 縮圖容器
 指令碼 (檔名)    "'字串值'"
  (指令碼資源類)    "'字串值'", 必須與指令碼規範類同步。
 指令碼-包含-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-build 程式碼 (標識軟體技術水平) 相匹配,但指示之前的版本歷史記錄。
  • 在資料庫中同時存在兩種資源的情況下,具有更高字尾程式碼的 KUID2 資源將覆蓋或替換舊資源。擁有早期版本並非必要,但CM 會將缺少的修訂鏈列為缺少的依賴項,對於那些不喜歡 CM 中汙染該功能的人來說,這是一個軟體錯誤,或者說是程式設計師保留的“特性”,無論如何都降低了使用 CM 來識別使用者缺少哪些資源的實用性,並導致使用者花費時間手動確定到底是什麼資源。

 

trainz-build 標籤

[編輯 | 編輯原始碼]
主要內容:trainz-build 標籤,縮寫:TB & TBV (TB-值)
型別:帶一位小數的浮點數,由 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)開始遞增 0.1,一直到現在的版本(v3.7 = TS12-SP1,v3.8 = Mac2,3.9=TANE-CE,4.0—4.3 以及之後?從 2016 年 3 月開始,4.3 及以上是 TANE SPs TBDL)。
  • 從 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 版本,這通常會將 TBV 解析為 1.3。

 

使用者名稱標籤

[編輯 | 編輯原始碼]
型別:UTF-8 字串,資產的使用者名稱必填規範。
欄位定義:此資產的英文人機可讀名稱。

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

在建立資產時,強烈建議對新的建議名稱在 CM 搜尋中針對幾個試用部分名稱進行驗證,並根據該知識採用一個與現有可用內容合理匹配的名稱。
我們需要容忍多少個“house 2”或“road”資產才能讓我們更混亂!?好吧,實際上,我們都在搜尋“house”,然後從影像中選擇,但能夠指定一個唯一的名稱並獲得你預期的東西真是太棒了!


 
 

使用者名稱-XX 標籤

[編輯 | 編輯原始碼]
型別:UTF-8 字串,使用者名稱標籤 的替代語言版本。
欄位定義:(其中XX 被替換為代表該語言的相應本地化程式碼。)此資產的本地化人機可讀名稱。此欄位類似於使用者名稱欄位,但代表非英語區域設定。資產中可能存在多個使用者名稱-XX 標籤,每個受支援的區域設定一個。如果在給定終端使用者系統上沒有合適的“使用者名稱-XX”標籤來表示此資產,則使用英文使用者名稱標籤。

 

描述標籤

[編輯 | 編輯原始碼]
型別:UTF-8 多行字串,提供資產的清晰語言描述。
欄位定義:此資產的英文人機可讀描述性摘要。

描述在 Content Manager 的“資產詳細資訊”窗格中可見,用於闡明資產名稱,提供規格,以及通常包含一些歷史資訊。

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

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

描述-XX 標籤

[編輯 | 編輯原始碼]
型別:UTF-8 多行字串,描述標籤
欄位定義:(其中XX 被替換為代表該語言的相應本地化程式碼。)此資產的本地化人機可讀描述性摘要。此欄位類似於描述欄位,但代表非英語區域設定。資產中可能存在多個描述-XX 標籤,每個受支援的區域設定一個。如果在給定終端使用者系統上沒有合適的“描述-XX”標籤來表示此資產,則使用英文描述標籤。

 

字串表容器

[編輯 | 編輯原始碼]
型別:UTF-8 字串列表容器,字串表容器
欄位定義:英文字串的鍵值列表。每個鍵都是一個有意義的指令碼識別符號,對映到二進位制資料並被二進位制資料引用。每個值都是一個英文字串。英文字串可能包含或引用非英文專有名詞作為識別符號。非英語母語作者建立的資產仍然必須建立沒有後綴的字串表容器(如果有需要)。軟體僅連結並引用字串表容器中沒有後綴的名稱和值,這對於西班牙語、法語、德語、捷克語、荷蘭語... 日語作者來說是無休止的痛苦。換句話說,帶字尾的字串表僅用於翻譯目的,這在使用非英語語言編寫地圖時會導致問題 - 沒有字串表-en 來提供用於反向翻譯的表。同樣,username-en 和 description-en 也是如此。所有三種缺乏表明了一種過時且傲慢的無視世界動態的態度。

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

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

 

字串表-XX 容器

[edit | edit source]
型別:UTF-8 字串列表容器,即本地化的字串表,每個字尾對應於除英語以外的語言。
欄位定義:(其中XX被替換為適當的本地化程式碼,用於表示的語言。)此欄位類似於字串表欄位,只是表示非英語語言環境。

英語字串表(無後綴)是強制性的,其他本地化語言是可選的,由資產作者決定。許多提交給 DLS 的資產,然後也用於與 Trainz 版本捆綁的路線,通常會被翻譯並擁有一套完整的本地化翻譯,用於描述-XX 和字串表。特別是,與版本捆綁的路線和會話會隨著每個零售版本的釋出而被專業翻譯成多種語言。

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

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

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。大多數具有子元件的資產只有幾個。
  • 其次,存在一種約定,它源於有時內部關鍵字是“自動定義”的事實——僅僅被列為一個沒有名稱的數字,作為佔位符引數,偽關鍵字,可以是任何唯一值(通常是零索引的順序整數。[notes 1])使用者或作者可以隨意為它們命名或不命名。
  • 此表中的條目有兩個目的
    首先:確保遊戲系統知道依賴關係,以便安裝和載入此資產將成功安裝和載入任何依賴關係,以及
    其次:允許指令碼定位相關的子資產。
  • 只有第一級依賴關係才應包含在 kuid-table 中——具有自身依賴關係的子資產或部件資產由該子資產的驗證和資料庫提交處理。
  • 迴圈依賴關係是非法的。
  • 如果某個資產也被標記為此資產的已棄用版本,則該資產不能被列為依賴關係。(在 Trainz 資產索引(歷史上是 assets.tdx 檔案)中的 kuid 中,只有一個替換 kuid 插槽,這將建立一個迴圈定義,要求自己使用舊版本!)
  • 同樣,某個資產不能被列為自身依賴關係。[OTOH,在將地圖和會話移植到安裝之間時,已經經歷了(即,在 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-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>
} ...

注意將單詞連線起來的下劃線... 兩個符號,鍵和值!我們讓學生去弄清楚在哪裡將 kuid 新增到裝載和允許的產品隊列表條目中。(不用謝,但這也是改變名稱的一個很好的理由!保持事物井井有條几乎是製作資產的全部戰鬥!) 

已棄用表容器

[編輯 | 編輯原始碼]
型別:KUID 列表容器,與Kuid-table 容器格式相同。
欄位定義:一個“佔位符鍵-鍵-值”列表,其中包含被該資產標記為已廢棄的資產。任何嘗試載入該列表中的任何資產都將導致載入該資產
  • 此外:兩個資產都不允許同時標記第三個資產為已廢棄,除非其中一個也標記另一個為已廢棄。[注 6]
  • 迴圈廢棄引用是非法的。
  • 該資產的所有較低編號的 KUID2 版本都被隱式地視為已廢棄,不需要包含在該列表中。同時,較新的改進資產(具有更高的 Kuid2)及其某個前身絕不應該將相同的前身(例如原始的!)列入“中間”的中間前身 - 因為這些值用作替代條目表,並且只能用一個資產替換較早的版本。(陣列只儲存一個值,不能將兩個替換為一個!)
  • 將該資產的較高編號的 KUID2 版本標記為已廢棄是非法的,因為這會建立一個隱式的迴圈引用。
  • 該列表中引用的資產必須與該資產具有相同的建立者,才能透過 DLS 上傳過程進行驗證和接受,此限制不適用於您的本地版本,例如,它可以用來將大型火車車組上所有舊的紙質輪轂 kuids 替換為一個更美觀且更新的輪轂。

 

category-region 標籤

[編輯 | 編輯原始碼]
用途:在 CM 和 Surveyor 中過濾(搜尋條件)
型別:列舉字串或字串陣列。
欄位定義:一個由分號 (';') 分隔的雙字元category-region 標籤程式碼列表。字串中不應出現其他字元(包括空格等)。該資產被認為與每個指定的區域相關 - 這對於kind traincarkind 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 個字元的category-class 程式碼,描述了此內容項。category-class 標籤用於提供超出資產種類隱含意義的附加人類子分類。每個 Trainz 資產的 category-class 標籤有助於描述資產在遊戲中的“意圖”,而不是資產的內部結構。
內容創作者指南 (CCG) 用於 TRS2006 和 Trainz Classics 的 CCG 解釋這些類代表了用於引用各種型別的機車、滾動車廂、風景、樣條線和工業資產的標準化系統。當搜尋和/或過濾適合的資產以在會話或路線(佈局)中製作內容時,Category-class 分類程式碼對所有 Trainzers 變得重要。


 

請注意,許多 category-class 程式碼只與特定的資產種類相關 - 不允許將 category-class 程式碼應用於不合適的種類資產。

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

 

類別-年代標籤

[編輯 | 編輯原始碼]
用途:在 CM 和 Surveyor 中過濾(搜尋條件)
型別:列舉格式字串陣列。
欄位定義:一個由分號 (';') 分隔的五字元年代程式碼列表。
  • 每個年代程式碼代表一個十年,由一個四位數的整陣列成,然後必須以 's' 結尾 (例如 "1990s;2000s;2010s"), 從而建立一個列舉的軟體令牌(值),該令牌必須與指定的合法年代程式碼完全匹配。
  • 字串中不應出現其他字元(包括空格等),包括(尤其是在字串末尾)在結束雙引號字元之前。
  • 允許的年份範圍是 1800-2010 年代[注 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 '圖示',它應該有一個阿爾法蒙版或非常淺的背景。許多較舊的資產沒有使用 jpg 檔案,而是在 '_art' 子資料夾中列出了 .tga 檔案(Targa True Color)(Trainz 1.0-TC3 慣例:'_art'、'_body' 和 '_shadow' 是三個子資料夾,由早期的 Trainz 資料模型要求命名為 'asset-filename_suffix'(已廢棄的標籤-<value> 對),它看起來如下[注 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 短 URL 格式,以防備未來的網站佈局更改,而不是直接連結到這些域。'短 URL' 是 Trainz 特定的 URL,透過允許內容建立者引用 N3V 網站上的特定頁面而無需依賴特定網頁佈局來幫助保護內容免受未來變化的影響。短 URL 旨在用於遊戲內使用,例如 info-url 連結,它們只會在嵌入式網頁瀏覽器中起作用,而不會在任何外部網頁瀏覽器中起作用。當此標籤存在時,遊戲內按鈕將允許使用者檢視資產描述或幫助,而無需離開遊戲環境。

這在 Driver 中非常有用,可以訪問路線圖、指南或任務說明或澄清。

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

 

must-have-product-rights 標籤

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

 

must-not-have-product-rights 標籤

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

 

privileges 容器

[編輯 | 編輯原始碼]
型別: privileges 容器 是某些作者使用的一種 DRM,版權保護實現,也可以稱為 privileges 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。

The script-include-table 容器 是 KIND TrainzBaseSpec 派生資產(簡而言之,所有資產)可用的頂級 config.txt 檔案 條目。此容器允許資產直接 包含另一個資產的指令碼 從父資產的指令碼檔案使用 N3V TrainzScriptScript_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>
                     }

 

extensions 容器

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

 


較新且不太常見

[編輯 | 編輯原始碼]

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

category-keyword 標籤

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

 

{{anchor|custom-category-list container|Custom-category-list 容器|custom-category-list 標籤|Custom-category-list 標籤|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(測試版)開始。

 

型別: UTF-8 多行字串。(由程式設計師法令棄用。)
欄位定義: 描述資產建立者希望如何使用此資產的許可證。 最常見的是許可宣告,禁止在任何付費路線、依賴資產(例如轉向架、聯軸器等火車零件)或重新制作中使用受版權保護的資產,包括在任何以付費運營的網站上分發資產。(理論上即使對於 DLS 也是正確的。 FCT 費用是為了更快地訪問和無限次下載,而不是為了訪問資產。)
license 標籤的含義含糊不清,N3V 不建議使用它,但它存在的時間比 N3V 管理早 6-7 年。
上傳到下載站 或提供以包含在遊戲中的內容可能受特定再分發合同或許可協議的約束,該協議優先於此欄位中的任何文字。 license 欄位不提供本地化支援。 license 欄位的文字不會由 Auran 或 N3V 驗證或執行,並且可能對終端使用者具有法律約束力,也可能沒有。
另一方面,Planet Auran 的歷史表明,有人透過將其他人的內容作為自己的內容來侵犯版權,可能會導致其被快速禁止訪問 Auran 網站,並永久失去下載站許可權等。 此外,社群將嚴厲打擊其他使用者侵犯他人的版權行為,並排斥違規者,並忽略 DLS 上允許保留的任何資產。
總而言之,試驗和更改資產是Trainzer 嘗試克服陡峭的內容建立學習曲線的一種被接受甚至被默許的生活方式(每個人都希望有更多內容建立者!),但如果資產有依賴部分,尤其是網格、指令碼、紋理,這些是智慧財產權 - 在上傳您的創作之前,請獲得使用這些屬於其他人的部分的許可。
由“kuid 引用”指定的資產部分不打算包含在此宣告中 - 使用通用聯軸器、轉向架或基本火車車廂網格(Auran 鑄造了幾種標準型別,許多作者預設情況下使用它們,例如檢查箱式貨車的依賴項(英國:封閉貨車或貨車)- 超過一半可能使用 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 頁面 中的正式定義 11:32, 12 May 2009[4]


 

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

 

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


  • asset-namenamename-XX — V1.3–v2.8 —在歷史上幾乎所有 v1.3-v2.0 資產中都能找到。雖然“asset-name”在 v2.8 之前一直保留,沒有引起任何抱怨,但在 v2.5 之後就被阻止;因此,在 v1.5 之後,資產的 config.txt 檔案中唯一需要、想要或認可的名稱是 username-XX 變體。

 

Asset-name

[編輯 | 編輯原始碼]

Asset-name 是 Trainz 1.x--TRS2004 Trainz 時代資產的主要資料夾名稱,並且通常是 CM 在開啟檔案以進行編輯時開啟的資料夾的名稱;在今天這樣的早期資料模型資產中,通常會發現 asset-name 也被用於早期 Trainz 時代的資料子資料夾系統,為火車車資產提供了子資料夾名稱“asset-name_art”、“asset-name_body”、“asset-name_shadow”。在修復此類資產時,通常可以將該值替換為從資原始檔複製貼上的 SAR。此替換通常會正確定義和連結身體、陰影和藝術品的資產子資料夾,因為早期方案中的檔名基於 asset-name 標籤。 

bendy 標籤

[編輯 | 編輯原始碼]
範圍:軌道或橋樑資產 中找到,早於 v2.9 標準,當時樣條物件經歷了重大變化,以實現統一的資料模型定義,放棄了混合中的幾個先前的 KIND,轉而支援所有樣條物件統一在 kind track 下。

 

casts-shadow 標籤

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

 

name 和 name-XX 標籤

[編輯 | 編輯原始碼]
  • 'name' 和 'name-XX' 是早期資料模型形式,比更長的 usernameusername-XX 標籤更短,XX 代表英文“name 標籤”(或今天的“username”標籤)的非英語語言翻譯的 ISO 雙字母后綴;“XX”形式與 description-XX 一樣,是“本地化”支援其他語言的使用者友好值的組成部分。
  • 在最古老的 Trainz 時代(v1.0-v2.4)資產中,用 username 和 username-XX 替換 name 和 name-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 Maxgmax 的一種約定,延續到 Trainz 中,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”(小寫“s”)字尾。

 

category-region-nn 標籤

[編輯 | 編輯原始碼]
category-region 標記 取代
  • 型別 category-region-nn — V1.3–v2.8 —在幾乎所有值得本地化的資產中都存在。這些已被 category-region 標記中 包含兩個字母的列舉 ISO 國家程式碼的 “string-array” 取代。
  • 用字串陣列型別 category-region 替換,在兩個字元的國家程式碼之間使用分號分隔,沒有空格。這些程式碼是完整的兩個大寫字母,由 列舉 的程式碼組成,程式碼之間使用 “;” 分隔符,但在最後一個程式碼之前沒有分隔符。
  • 字串陣列中的任何 空白 都會導致讀取錯誤和故障訊息,包括尾部引號前的空格。

 

  • region — TBS V1.3–v2.8 中作為內建過濾器和地圖資產自定義本地化識別符號 (kuid) 的有效部分;現在唯一合法的標記使用是在 kind map (佈局) 資產中。
作為以前的過濾器修飾符,該標記在歷史上存在於幾乎所有資產中,但它在滾動庫存、場景、樣條資產、軌道型別(包括隧道和橋樑)以及具有一定程度本地化的軌道旁資產中尤為普遍。
  • 地圖資產仍然保留關鍵字 Region,該關鍵字在 Map 配置檔案中定義,但使用方式相反——成為 kind region kuid 引用。因此,Region 在 Maps 中是必需的,並且自 TS2012 以來,與標記型別一樣,在它曾經作為 TRS 系列釋出的 Surveyor 工具視窗的 “分組資料” “快速過濾器” 出現的眾多資產中是非法的。
  • 在 TRS2009 之後,任何 region 標記到文字字串都已過時,因為在程式設計師的心目中,他們在 Surveyor 工具中用 Pick List 取代了 “型別和區域” 字串值的 粗略過濾 組選擇器。這兩個標記都有一些優點和缺點,並且都可追溯到 Trainz 0.9 Beta 版本。

 

shadows 標記

[編輯 | 編輯原始碼]
參見上面的 bendy,已過時/廢棄的 pre-TS2009 遺留 kind track 資產模式控制標記。

 

thumbnail 標記

[編輯 | 編輯原始碼]

thumbnail 標記是 thumbnails 容器 的早期單檢視實現(上面也有簡要說明)。Trainz 的早期 pre-N3V 程式設計師版本會找到一個 .jpg 檔案,最好大小為 240x180 畫素,位於主資產根資料夾或 asset-name_art 或 asset-name_body 資料夾中,並將其用於在 CMP 和 DLS 中顯示資產(如果上傳)。自 TRS2006 以來,該標記已過時,因為 thumbnails 容器已隨 v2.0 (TRS2004-SP0) 引入。在使用 TBV 保持在 v2.4 以下的舊修復資產中,拇指通常仍然可以在較新的 CM 中工作,前提是它位於 _art 子資料夾中,並且資產名稱與使用者名稱匹配。  

type 標記

[編輯 | 編輯原始碼]
  • type — V1.3–v2.8 —以前是一個過濾器修飾符,並且在歷史上存在於幾乎所有資產中,但它們在滾動庫存、場景、樣條、軌道型別(包括隧道和橋樑)以及軌道旁資產中尤為普遍。
  • type 標記與 “region 標記” 一樣,在 Trainz 0.9—TC3 版本中 用作 “Surveyor 內部分組過濾器”,它與 region 結合使用,提供了較小的資產選擇(工具組)。自 TS2009 以來,移除了這些本地可點選過濾器的功能和使用,轉而使用一個新的、更繁瑣的過濾器。這些使工具選擇變得快速而簡單,而不是在工具選項卡之間切換時變得緩慢和暫停——如今的 pre-TANE 版本在工具選項卡之間來回切換時,往往會因重新載入整個選擇列表而不堪重負。
  • type 和 region 都預設為 “All”,提供了與 TS09 及之後版本中的工具相同的超大型列表。
  • 在 TRS2006 分支版本(即 TC3)之後,每個 type 標記都已過時,因為在程式設計師的心目中,他們在 Surveyor 工具中用 TS09 Pick List 和過濾器取代了 “型別和區域” 的 粗略過濾 組選擇器——沒有賦予使用者儲存多個 Pick List 或輕鬆載入在 CM 中定義和精煉的過濾器的能力。

 

  1. 資產 提交(TANE 的提交)是將內容整合到資料庫中並將其在資料庫索引中交叉引用的過程和步驟,以便在執行時模組中訪問它。
  2. 驗證資產的一種方法是,除了這些值之外,其他方法都是可以的,方法是將 TBV 降低到 2.5-3.7 範圍,看看這些訊息是否消失。您可能需要多次嘗試降低它,直到足夠低,反之亦然,較新關鍵字在較舊的 TBV 中無法識別,可能會給出不同的錯誤訊息。不要害怕嘗試,即使失敗也會產生知識和經驗,而且您不會破壞任何東西!如果是這樣,您可以自信地提供值,這是解決問題的辦法。通常,一些現代需求只需要關鍵字對,因此在標記之後新增一個空白行或在標記之後新增一個空的花括號集將滿足需求,而錯誤測試則過於嚴格。
  3. 注意:此列表在 N3V TrainzOnline Wiki 上 “維基化”,這意味著在 “KIND” 這個詞之後的首字母已大寫,而 config.txt 檔案中實際的資料標記名稱全部為 小寫 文字。該維基也使用雙引號來表示許多術語,我們將在本文中避免使用這種做法。
  4. “kind consist” 並不經常直接看到,它只存在於選單和內容管理器列表中。
  5. 過時表必須謹慎使用,最常出現在 Auran 編寫的資產中。該表用較新的 kuid 替換了較舊的 kuid,大多數內容創作者正確地使用 kuid 的 Kuid2 形式來取代舊版本。相比之下,N3V 過度使用過時表來升級新發布的 “升級” 內建資產,這會導致很多混淆,並且無法獲得預期看到的內容。(例如,許多很棒的 `翻轉樹` 在 TS10 和 TS12 中被 Speedtree 取代,這影響了許多路線,其中 Speedtree 並不被建立者想要或需要。在安裝中,這也會導致依賴項缺失,直到找到包含過時表的資產。
     • 此外,在 Assets.tdx 資料庫索引中只支援每個 kuid 一個過時條目,用 Kuid2 版本過時 kuid 可能會導致問題(例如,您會看到哪個?)。
     • 過時表的絕佳用途之一是使用特定部件升級一系列資產,尤其是轉向架。新增一系列 kuid 來替換較新的好的轉向架,可以顯著改善路線或場景的外觀,只需編輯一次(前提是轉向架等部件相容並且尺寸合適!)。
  6. 最近將過時資產引入 TANE 的經驗表明,至少有五個備用 kuid 過時了那個糟糕的 翻轉樹資產。看來,由於 Speedtree 的引入和 TANE 的徹底改造(它積極地追求最適合的資產),ContentManager 程序現在容忍多個具有不同 kuid 的資產過時了同一個 kuid。作為一個良好的實踐,僅在絕對必要時使用過時表……例如,在您想要上傳到 DLS 或在網站上自行釋出的依賴資產中取代一個不想要的付費資產。
  7. 關於 category 時代的標記範圍:安全起見,已知有效。其他 “未來十年” 的值應在依賴這些值之前進行測試。
  8. 許多容器在列表中使用虛擬/佔位符名稱。這些可以是描述性詞,只要它們不包含空格字元即可。在短語構造的名稱中使用下劃線或句點可以保持可讀性,並顯著提高畫質晰度。例如,貨運列車車廂可能裝載 45 種合法產品型別。這些將在依賴項容器中列出。使用 Coal、granite、crushed_limestone 等使維護和更改表格變得更容易。Jes Sayin,自 76 年起擔任程式設計師
  9. 在第二個 thumbnails 容器示例中,有一個第二個 512x512 大小的影像,一個額外的影像。DLS 將使用哪個影像尚不清楚。也可以包含更大的影像尺寸,並且透過電子郵件聊天,T:ANE 可能會支援在預覽操作或 DLS 列表中找到用途的大影像尺寸。N3V Games 通常不會發布此類資訊。
  10. 早期的做法(可追溯到 Trainz 1.x)是在執行時選單中使用關鍵字/標記 “thumb”,並在引號中使用 pathspec 引用指向 240x180 的縮圖影像。art 資料夾包含一個帶有 Alpha 遮罩的 512x512 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 更有經驗的軟體人員永遠不會對社群的時間成本如此漫不經心。

參考資料

[編輯 | 編輯原始碼]
  • 此頁面的中心主體取自 N3V TrainzOnline Wiki 的 KIND_TrainzBaseSpec。昨天 Trainz 使用者組的成員添加了增強資訊。
  1. N3V 的 KIND_TrainzBaseSpec,作為未經增強的源頁面,缺少此處找到的歷史資訊(標籤);訪問日期 = 2014 年夏季
  2. a b "Trainz-build" 標籤 直接連結
  3. 根據 fabartus,2014 年夏季;很可能是在新增此示例的同一天。
  4. Christoph Bergman,N3V Games 首席程式設計師,又名 'Windwalkr',KIND TrainzBaseSpec 歷史 頁面。



華夏公益教科書