Trainz/refs/TrainzBaseSpec
(重定向自 Trainz/KIND TrainzBaseSpec)
KIND TrainzBaseSpec 提供了所有 Trainz 資源型別在所有 config.txt ini 檔案 中的基礎定義。TBS 提供了一系列“標準標籤”，這些標籤在所有 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] 下面列出的幾個種類，那些帶下劃線的種類，是遺留的種類，早於 TS2009 版本（即 2008 年後期）中對 Trainz 資料模型 的更改，N3V 程式設計師只是從那時起才逐步（增量式地）施加了更改。
目前，可以在 N3V Trainz Wiki TrainzOnline 網站 的 內容建立者指南 部分找到修復基於這些遺留種類的資源的詳細資訊，其中包含對 遺留種類的示例 的說明。強烈建議所有 Trainz 下載站 使用者或任何考慮建立內容的人都仔細閱讀 CCG。通過了解舊內容是如何定義的，可以將其與當前 TrainzOnline 對相同資料型別的覆蓋範圍進行對比，因為這種“當時與現在”的對比往往會提供修復、更改和定製資源的有價值的見解。更重要的是，CCG 中的寫作是專業製作的，而且更具有自明性——它通常會讓你瞭解如果改變這一點或那一點的擴充套件效應，而 Trainz Wiki 卻沒有提供這些資訊。TrainzOnline 上釋出的 CCG 是TC1&2/TC3 版本——幾個印刷手冊的最後一個出版版本，可以追溯到 1999 年的Trainz；TC3 CCG 包含需要正確更新的 TRS2004/TRS2006 和UTC 資料模型中更改的 Enginespecs 機車資源。
表格 I，TBS 標準定義
[edit | edit source]TBS 標準定義
[edit source]這些標籤和容器是標準定義，幾乎所有資源中都會找到它們。有些標籤是可選的，內容創作者可以選擇是否定義它們。標籤是關鍵字，並具有單個分配的鍵值或容器，例如字串陣列或 '{' ... '}' 繫結封閉的標籤值對或子容器。（Trainz 配置檔案中的所有宣告都是成對的，即使 '{' ... '}' 也被認為是一個 '鍵值'.
- 容器是'鍵' 和 '鍵值' 對的集合 以及 TBS 中的 '上層容器'（與子容器（例如縮圖容器中的子容器）相反）通常以 '-table' 結尾。
| kind | "'字串值'" |
| trainz-build | 'float', 1 位小數 |
| kuid | <Kuid 編碼值> |
| username | username "'字串值'" |
| username-XX | username-XX "'字串值'" |
| description | description "'字串值'" |
| description-XX | description-XX "'字串值'" |
| kuid-table (容器) { 依賴項列表 |
列出所有此資源依賴的資源的鍵值表。 |
| obsolete-table (容器) { } |
kuids 列出此資源替換的資源（使其過時） 通常沒有（為空）[註釋 5] |
| string-table (容器) { } |
資源中使用的字串和訊息的鍵值列表 通常為空，在路線和會話中很大。 |
| string-table (容器[s]) { 非英語 語言文字 } |
翻譯字串列表 匹配到 強制性英語 string-table |
| category-region tag 列舉 程式碼 | category-region "'字串陣列'" |
| category-class tag | category-class "'列舉 字串值'" |
| category-era tag | category-era "'受約束的字串陣列'" 年代 |
| category-keyword "'字串陣列'" 最大長度為 64 位元組 | category-keyword tag 自然語言搜尋關鍵字 (替換型別，區域) |
| custom-category-list "'字串陣列'" |
指令碼介面功能 |
| must-have-product-rights "'字串值'" |
DRM 字串陣列 |
| must-not-have-product-rights "'字串值'" |
DRM 字串陣列 |
| privileges (容器) { } |
更多 DRM |
| thumbnails (容器) { } |
縮圖容器 |
| script (檔名) | "'字串值'" |
| class (指令碼資源類) | "'字串值'", 必須與 script 規範類同步。 |
| script-include-table { } |
(列出庫指令碼的容器) |
| extensions (容器) { } |
資源也使用的正式指令碼擴充套件 |
| license "'字串值'" | 資源建立者的版權宣告 |
| author | "身份 '字串值'" |
| organisation | "第三方組身份 '字串值'" |
| contact-email | "電子郵件地址 '字串值'" |
| contact-website | "作者/組網站 URL '字串值'" |
| member-of-groups (容器) { } |
此資源所屬的 KIND 資源組 資源列表。 |
支援的標籤
[edit | edit source]TrainzBaseSpec 在 config.txt 檔案 中支援以下標籤。 ∅:
kind tag
[edit | edit source]- 型別: 字串。
- 欄位定義: 此 config.txt 檔案 代表的資源型別。檢視索引 種類 和列表：這裡（上面）
kuid tag
[edit | edit source]- KUID
- 'Koolthingz Unique IDentifier'. Trainz 系統軟體的資源在資料庫中的唯一引用號，在 KUID2 形式中擴充套件到跟蹤多個版本。Trainz 可升級性和資源模組化設計的核心，因為每個資源都有自己唯一的 kuid 程式碼，因此可以指定另一個資源的元件（轉向架）或整個火車車廂，並在新資源中選擇性地替換其中任何一個（重新貼皮或修改轉向架）。
- 基本 KUID 格式：'<kuid:wwwwww:xxxxxx>'，其中 wwwwww 是作者的“唯一 Trainz 身份”，xxxxxx 代表作者分配的模型識別碼。
 |
|
- 大多數 Trainz 資源在其kuid 表中指定了依賴項列表——其他元件資源，這些資源由軟體套件的各個部分組裝起來，構成一個可渲染和可用的資源，位於kuid 表容器中。
- 在許多資源的核心，特定標籤可以由kuid 引用定義，並使用引用的資源作為一部分。事實上，這就是重繪的實現方式，並且可以將網格用於資源，儘管更現代的做法建議將此類引用引用到網格庫資源。
- KUID2
- KUID 格式的更新和更新跟蹤修改版本，允許指定版本號。一個
<kuid:xxx:yyy>等同於<kuid2:xxx:yyy:0>（零次修訂或版本零，表示原始版本）- 這允許資料項（Trainz 資源）為資源攜帶一個固有的版本程式碼。這通常不會與CM Trainz-build 程式碼（標識軟體技術級別）匹配，但表示以前的版本歷史。
- 在資料庫中存在兩個資源的情況下，具有更高字尾程式碼的 KUID2 資源會覆蓋或替換舊的資源。具有早期版本不是必需的，但CM 會將缺失的修訂鏈列為缺失的依賴項，對於那些對 CM 中該功能的汙染感到不滿或程式設計師保留了該功能的人來說，這是一種軟體錯誤，無論如何都會降低使用 CM 來識別使用者缺失內容的實用性，並導致使用者花費時間手動找出什麼是真正的內容。
- 主要覆蓋範圍：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 無服務包）到現在的版本遞增 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 進軍 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。
- 型別：UTF-8 字串，資源的使用者名稱，強制性規範。
- 欄位定義：此資源的英文人眼可見名稱。
在 TC1&2（v2.7）之後的 trainz-builds 中，使用者名稱在編輯資源時也成為作業系統資料夾名稱，而資原始檔名被忽略，而在 v2-6 配置檔案中，資原始檔名具有優先權。根據 N3V Games 的 TBS 標準，此欄位不應包含非英文文字，除非資源名稱是專有名詞（例如，地名）且沒有英文字地化變體。此值是每個人通常搜尋和記住的資料，因此建議保留清晰的名稱。
 |
|
- 型別：UTF-8 字串，使用者名稱標籤 的備用語言版本。
- 欄位定義：（其中XX 被替換為適當的本地化程式碼，用於表示語言。）此資源的本地化人眼可見名稱。此欄位類似於使用者名稱欄位，但表示非英文語言環境。一個資源中可能存在多個使用者名稱-XX 標籤，每個支援的語言環境一個。如果不存在適當的“使用者名稱-XX”標籤來在給定的終端使用者系統上表示此資源，則將改用英文使用者名稱標籤。
- 型別: UTF-8 多行字串，提供資產的清晰語言描述。
- 欄位定義: 此資產的英文人類可讀描述摘要。
描述在內容管理器“資產詳細資訊”窗格中可見，用於澄清資產名稱，提供規格，以及通常的一點歷史。
N3V 的 Chris Bergmann 已經宣告此欄位應該保持簡短（1-2 段）描述資產，並透過info-url頁面提供擴充套件細節，但相當長的文字塊是可以容忍的。有些人使用塊的底部作為版本更改記錄。
此欄位必須由英文描述性文字組成，儘管文字可能引用非英文專有名詞，如其他地方所解釋。其他語言翻譯或源文字應放置在許多可能的替代語言本地化標籤之一（參見 description-xx 標籤）。
- 型別: UTF-8 多行字串，description 標籤。
- 欄位定義:（其中XX被替換為代表的語言的適當本地化程式碼。）此資產的本地化人類可讀描述摘要。此欄位類似於description欄位，只是代表非英語語言環境。多個description-XX標籤可以存在於一個資產中，每個支援的語言環境一個。如果適當的'description-XX'標籤不存在於給定終端使用者系統上以代表此資產，則使用英文description標籤。
- 型別: UTF-8 字串列表容器，String-table 容器(s)。
- 欄位定義: 一個英文字串的鍵值列表。每個鍵都是一個有意義的指令碼識別符號，對映到二進位制資料並被二進位制資料引用。每個值都是一個英文字串。一個英文字串可能包含或引用非英文專有名詞作為識別符號。非英語母語的作者仍然需要建立一個無後綴的 string-table 容器，如果需要的話。軟體只連結到並引用 string-table 容器中沒有後綴的名稱和值，這對於西班牙語、法語、德語、捷克語、荷蘭語……日語作者來說是無濟於事的。換句話說，字尾 string-table 僅僅是為了翻譯目的，這在用非英語語言編寫的路線圖時會產生問題——沒有 string-table-en 來提供反向翻譯的表格。同樣，username-en 和 description-en 也是如此。這三者都缺乏，證明了一種老式和傲慢的無視世界動態的傲慢行為。
其他語言透過類似的 string-table（例如 string-table-XX）得到支援，這些 string-table 具有與 description 和 username 關鍵字/標籤的國際化字尾匹配的本地化程式碼字尾 (XX)，但是這些語言鍵 string-table 容器的左手項始終具有相同的鍵值。
- 這些左手鍵或標籤既用作“本地索引關鍵字”，也用作“語言之間的等效表”。
- 左側列將始終包含內容創作者賦予“特殊”名稱的物件，例如訊號、軌跡標記和行業、連線點等等，這些名稱可能會被引用，並且會出現在駕駛員和測量員模組的“查詢工具”（CTRL+F ) 功能小程式。
- 反過來，索引側也不會列出預設的名稱，例如無數的連線點，在構建路線圖時由隨機數自動索引（即無意義的雜亂。如果重要，路線構建 CC 會命名它！），但會自動包含可能臨時的資產，例如火車車的預設名稱。如果重新命名，這些名稱將取代其相應的預設名稱。
- 它的主要用途是針對那些旨在與指令碼引用互動並獲取可變屬性的物件，例如火車站或行業所需的或準備裝運的產品數量，或者由互動式火車車（滾動行業到指令碼）和其他可配置資產攜帶，這些資產像一個通用的廣告牌式標誌一樣簡單，只需調整一下高度和角度，就可以放置在庫存建築物或行業的正面，在建築物上放置不同的企業名稱。換句話說，有點可配置的風景。
- 總體而言，在路線圖或佈局中，這些 LHS 名稱對應於地圖資產上的命名物件，而大多數 string table 都是在那裡看到的（從字面上講，由大型路線kind 地圖中的數千個條目填充）。
- 在某些資產中，該預設名稱與軟體指令碼掛鉤，因此 string-table 變得特別重要，而不是乏味無聊。（見下文）
- 使用 string-table 型別在每種型別的資產中都是合法的，就像 description 標籤、trainz-build 和 kind 標籤一樣。與這些標籤不同，它不需要存在或定義，而且沒有任何強制性。封裝在 string-table 容器中的值只有在程式碼期望它們配對時才具有功能或效果。
- 在其他資產中，再次以假設的可程式設計商業標誌為例，如果 string table 要與軟體互動，則必須為其指定預設名稱。所有地圖可放置資產都可以命名或重新命名，但“特殊名稱”必須與指令碼和 string table 索引值匹配。大多數可配置資產定義了一個介面變數，該變數用於替換預設名稱，作為指令碼和資產二進位制資料引用的索引或查詢表。其他變數也可能在可程式設計資產中定義。這些變數都可以由指令碼引用，但正是索引值使它進入地圖或會話 string-table，從而在需要駕駛員或會話建立者可變性時使一切協同工作。
- 相反，如果沒有系統軟體知道索引中命名的專案的 location，則物件的指令碼可能沒有觸發、條件檢查或更新能力。這是 2000 年代Trainz 1.0中物件的特徵，而不是 2003 年TRS2004釋出以來的更現代的 Trainz 鐵路模擬器。（從那時起，我們已經走了很長一段路！）
- 有一些資產只能作為一個組一起工作。在這樣的情況下，在對映或會話層中命名每個資產，使它們能夠一起工作。例如，考慮一個有五條軌道的公路平交道，其中兩條軌道的連線點不同，並與透過軌道形成所謂的“交叉道”。如何設定訊號，使任何鐵路交通關閉公路閘門，或者使用交叉道不允許其他火車透過正在透過交叉道的火車。道路和鐵路訊號以及道岔和閘門都必須協同工作。string-table 中聯姻的某些“ATLS 系統”資產及其指令碼可以使這個複雜的系統正常工作。
- 有關更多資訊，請參見 string-table-XX。
- 型別: UTF-8 字串列表容器，本地化 string-table，每個字尾對應於除英語以外的其他語言。
- 欄位定義:（其中XX被替換為代表的語言的適當本地化程式碼。）此欄位類似於string-table欄位，只是代表非英語語言環境。
英文 string-table（無後綴）是強制性的，其他本地化語言是可選的，由資產作者決定。提交到 DLS 的許多資產以及隨後用於 Trainz 版本捆綁的路線通常會被翻譯並具有完整的本地化翻譯，用於 description-XX 和 string-table。特別是，與版本捆綁在一起的路線和會話將在每次零售釋出時收到專業翻譯成多種語言。
請注意，string-table 的左側列是相同的，因為它是一個對映的符號表，並索引到二進位制資料，例如網格、會話或路線檔案。只有使用名稱，即兩個元素中的右側或資料元素，是本地化的，並由執行時本地化軟體替換。如果需要，這些名稱可以手動編輯，使其更易於使用者使用，即使是在英文 string-table 中也是如此。索引或左側引用列語法不得以任何方式更改，因此在更改資料列中的名稱時，請注意全域性 SAR 規範。
一個資源中可能存在多個string-table-XX標籤，每個標籤對應一種支援的語言。每個標籤應該包含一個字串列表，其鍵與string-table列表中的鍵相同，但值不同。如果在給定的終端使用者系統上沒有找到合適的'string-table-XX'標籤來表示此資源，或者該列表中缺少相應的字串，則會引用英文string-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-table。大多數具有子元件的資產只有幾個條目。
- 其次，由於內部關鍵字有時是“自動定義”的，僅被列為一個沒有名稱的數字，作為佔位符引數，偽關鍵字可以是任何唯一值（通常是零索引的順序整數。[注 1]) 它們可以根據使用者或作者的偏好進行命名或不命名。
- 此表格中的條目有兩個目的
首先：確保遊戲系統瞭解該依賴關係，以便安裝和載入此資源能夠成功安裝和載入所有依賴關係，以及
其次：允許指令碼找到相關的子資產。 - kuid-table 中只應包含第一級依賴關係——具有自身依賴關係的子資產或零件資產將在該子資產的驗證和資料庫提交過程中進行處理。
- 迴圈依賴關係是非法的。
- 如果一個資產被標記為另一個資產的過時版本，則它不能被列為依賴項。（Trainz 資產索引（歷史上的 assets.tdx 檔案）中的 kuid 只有一個替換 kuid 插槽，這將建立一個迴圈定義，要求使用自身較舊的版本！）
- 同樣，一個資產不能被列為其自身的依賴項。[另一方面，這在將地圖和場景移植到安裝之間時，使用 GSARS 更改 kuid 以防止重疊，並確保不會在目標安裝上覆蓋已使用相同 kuid 的資產而導致錯誤訊息的情況下，已經經歷過（即見證為成功提交到 TSxx CM 中的無故障資產）。] 是否也能正常執行需要比我更勇敢或更愚蠢的人！ --Fabartus，編輯。
- 格式 (所有值均為 <kuid:aaaaa.bbbbb> 格式)
kuid-table {
0 Kuid-1
1 Kuid-2
3 Kuid-3
... kuid-ii
N-1 Kuid-N
}
|
|
- 對這些虛擬引數進行實際利用的一個非常有用的方法是將複雜滾動庫存資產中產品對應的 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 上傳過程稽核並接受，此限制不適用於本地版本，例如，可以用來將大型火車車廂組中的所有舊紙輪 kuid 替換為一個圖形更美觀、更新的 kuid。
- 用途：CM 和 Surveyor 中的過濾器（搜尋條件）
- 型別：列舉字串或字串陣列。
- 欄位定義：一個由分號（';'）分隔的雙字元類別-區域標籤程式碼列表。字串中不應該包含任何其他字元（包括空格等）。此資源被認為與每個指定的區域相關——這對於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"（大多數第一世界國家）
- 用途：CM 和 Surveyor 中的過濾器（搜尋條件）；與 KIND 宣告一起確定 CM 軟體如何處理資源，以及 Surveyor 在哪裡列出它。
- 型別：列舉字串。
- 欄位定義：一個單一的 2-3 個字元的category-class程式碼，描述了此內容項。category-class 標籤用於提供超出資產型別隱含的附加的人工子分類。每個 Trainz 資產的 category-class 標籤有助於描述資產在遊戲中的“意圖”，而不是資產的內部結構。
|
|
請注意，許多 category-class 程式碼只與特定的資產型別相關——category-class 程式碼不得應用於不合適的資產型別。
- 示例
| category-class "XBG" | 貨車 - 來自 PRR 60' | |
| category-class "BR" | 鐵路（非功能性場景）——可能是建築物 | |
| category-class "BIN" | 具有產品處理功能的工業資產 |
- 每個年代程式碼代表一個十年，由一個四位數整陣列成，然後必須以's' 結尾
(例如，"1990s;2000s;2010s")，從而建立一個列舉的軟體標記（值），該標記必須與指定的合法年代程式碼完全匹配。 - 字串中不應包含任何其他字元（包括空格等），包括（尤其是在字串末尾）在終止雙引號字元之前。
- 允許的年份範圍是 1800-2010 年代[註釋 7]
- 此資源的唯一意義是對其他人類而言，即該資源在指定的年代範圍內被認為有效且適當相關，並且內容管理器將接受指定適用年份的搜尋過濾器。
- 示例
category-era "1920s;1930s;1940s;1950s"
- 用途：CM 和 Surveyor 中的過濾器（搜尋條件）
- 型別：縮圖容器。
- 欄位定義：用於在整個遊戲環境中（包括在遊戲中，在內容管理器和下載站中）以二維預覽框、列表和圖示形式表示此資源的縮圖。每個資料集都包含在一個子容器中（通常）使用佔位符引數作為鍵名或標籤。[註釋 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 資料模型要求指定的三個子資料夾，名為“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]。
- 型別：URL 字串。
- 欄位定義：指向資源的線上描述、資源說明（幫助）或 TrainzOnline wiki 上其他幫助頁面的連結，旨在從嵌入式特殊用途 N3V 瀏覽器中使用。該 URL 必須解析到Trainz 線上安全區域中的網站。目前，嵌入式瀏覽器接受三個域
auran.com
ts2009.com
ts2010.com
此外，不建議直接連結到這些域，而是建議使用自定義的Trainz 短連結格式來防止未來可能的網站佈局更改。 “短連結”是 Trainz 特定的 URL，透過允許內容建立者引用 N3V 網站上的特定頁面，而無需依賴特定的 Web 佈局，從而幫助防止未來內容的過時。“短連結”旨在用於遊戲內的使用，例如 info-url 連結，並且僅在嵌入式 Web 瀏覽器中有效，而在任何外部 Web 瀏覽器中無效。如果存在此標籤，則遊戲內按鈕將允許使用者在不離開遊戲環境的情況下檢視資源描述或幫助。
這在司機中可能非常有價值，可以訪問路線地圖、指南或場景說明或澄清。
建議在所有資源提供類似功能但外觀略有不同的情況下使用通用組頁面來表示整類資源。這減少了建立、維護和本地化此類文件的時間成本。
- 型別：ascii 字串。
- 欄位定義：必需的產品權利列表，以分號 (;) 分隔。如果本地安裝沒有必需的產品權利，則某些遊戲系統可能無法載入資源。
- 型別：ascii 字串。
- 欄位定義：衝突的產品權利列表，以分號 (;) 分隔。如果本地安裝具有列出的產品權利之一，則某些遊戲系統可能無法載入資源。
- 型別：“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) 重新儲存對資源的任何更改（提交（提交）重新驗證的資源到資料庫）。
- 型別：字串檔名。
- 欄位定義：指示此資源的主要指令碼檔案的檔案路徑（如果有）。此檔案路徑應始終以“.gs”副檔名結尾 - 執行時將嘗試新增或替換“.gs”副檔名，如果檔案路徑具有其他副檔名。
- 型別: 字串。
- 欄位定義：指示要載入為此資源的主要類的指令碼類名稱（如果有）。此類從此資源的主要指令碼檔案載入。
- 型別：kuid 引數和相應名稱作為鍵的列表。
- 欄位定義：指令碼資源的鍵值表，在編譯此資源的指令碼檔案時，將搜尋這些指令碼資源以進行指令碼包含。鍵（變數，因此不是標籤）當前未使用，但必須是唯一的；該值指示要包含的資源的 KUID。
script-include-table 容器是 KIND TrainzBaseSpec 派生的任何資源（簡而言之，所有資源）都可以使用的頂級config.txt 檔案條目。此容器允許資源直接包含另一個資源的指令碼，從父資源的指令碼檔案中使用N3V TrainzScript 的Script_Include_Directive。
- 相關
extensions 容器是使用特定命名約定的自定義標籤或子容器的列表。
此容器是指令碼資源名稱及其 kuid 的簡單鍵值表，在編譯資源的指令碼檔案時，將搜尋這些指令碼資源以進行指令碼包含。鍵或標籤名稱當前未使用（即為佔位符引數）進行搜尋；該值指示要包含的資源的 KUID。能夠搜尋和識別鍵名稱是內容建立者請求的功能，因此建議使用指令碼檔名而不是數字虛擬標籤名作為最佳實踐，因為它比 kuid 引用傳達的資訊更多。
通常最好將此類引用限制為 KIND 庫 資源，但這不是強制性的，任何資源都可以被引用。
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 container|自定義類別列表容器|custom-category-list tag|自定義類別列表標籤|custom-category-list string|自定義類別列表字串|Custom-category-list Container|custom-category-list 容器
- 型別： ASCII 字串陣列容器。
- 欄位定義： 用分號 (;) 分隔的自定義類別識別符號列表。每個 自定義類別識別符號 應該是一個簡短的（例如 3-6 個字元）字母數字標記。字串中不應存在其他字元（包括空格）。
- 這些自定義類別用於使指令碼能夠快速找到特定類別的資產。強烈建議謹慎引入新的自定義類別識別符號。
- 自定義類別列表 標籤值最多可以有 64 個字元。除非存在只能透過自定義類別列表方法滿足的現有特定指令碼要求，否則應將此標籤留空。
- 最小版本： V3.5 及更高版本
- 型別： 成員組容器，它將 佔位符引數 和 資產組 kuids 配對在一起。
- 欄位定義： KIND_Asset-group 資產列表，該資產屬於這些資產。有關如何使用以及何時使用此資產的詳細資訊，請參閱 kind KIND Asset-group 文件。
容器包含 KIND Asset-group KUID 的常規列表。此包含是一個宣告，表明此後，特別是在搜尋操作（包括指令碼介面和 TrainzUtil）中，此資產將被視為每個列出的資產組的成員。
如果未為給定的“成員組”容器指定任何條目，或者如果資產省略了“成員組”容器，那麼模擬器軟體可能會根據資產的 Config.txt 檔案指定一些預設資產組。確切的行為可能在模擬器的不同版本之間有所不同，但是當前的邏輯在 此處 描述。
- 以下標籤對於任何資產都不是強制性的，許多資產將它們留空。
- 從歷史上看，識別和許可標籤從 Trainz 0.9（Beta）開始。
- 型別： UTF-8 多行字串。（程式設計師法令已棄用。）
- 欄位定義： 描述資產建立者希望如何使用該資產的許可證。最常見的是許可證宣告，禁止在任何付費路線、依賴資產（例如火車部件，如轉向架、聯軸器等）或重製中使用受版權保護的資產，包括在任何付費運營的網站上分發資產。（從理論上講，即使對於 DLS 也是如此。FCT 費用用於更快的訪問和無限下載，而不是訪問資產。）
- DLS 上的大多數資產都是對被稱為 知識共享署名 - 相同方式共享 (CC-BY-SA) 的許可證的措辭不當的版本，類似於此以及其他維基百科專案。
- 許可證 標籤的含義模稜兩可，N3V 不推薦使用它，但它的出現早於 N3V 的管理 6-7 年。
- 上傳到 下載站 或提供用於包含到遊戲中的內容可能受特定再分配合同或許可協議的約束，這些協議優先於此欄位中的任何文字。許可證欄位不提供本地化支援。許可證欄位的文字未經 Auran 或 N3V 驗證或強制執行，並且可能具有法律約束力，也可能不具有法律約束力。
- 另一方面，Planet Auran 的歷史表明，如果有人透過將他人內容用作自己的內容來侵犯版權，可能會導致從 Auran 網站迅速被禁止以及永久封鎖的下載站特權等。此外，社群會嚴厲打擊其他使用者侵犯他人的版權的行為，並且會迴避侵權者並忽略允許保留在 DLS 上的任何資產。
- 總而言之，嘗試攀登陡峭的內容建立學習曲線（每個人都希望有更多內容建立者！）的 Trainzer 接受甚至縱容 實驗和更改資產，但如果資產有依賴部分，特別是網格、指令碼、紋理，這些都是智慧財產權——在上傳你的作品之前，請獲得使用屬於他人的部分的許可。
|
|
- 型別： UTF-8 字串。（已棄用，有利於可更新的 Planet Auran 資料庫。）
- 欄位定義： 作者的姓名或標識。不推薦使用此欄位，因為歸屬可以以程式設計方式確定。
- 注意英國的拼寫，北美的拼寫 'organization' 也適用！
- 型別： UTF-8 字串。（已棄用，有利於可更新的 Planet Auran 資料庫。）
- 欄位定義： 負責建立此資產的組織的名稱或標識。不推薦使用此欄位，因為歸屬可以以程式設計方式確定。
聯絡電子郵件標籤
[edit | edit source]- 型別： 字串，電子郵件地址。 （已棄用，建議使用可更新的 Planet Auran 資料庫。）
- 欄位定義： 此資產建立者的聯絡電子郵件地址。 不建議使用此欄位，因為歸屬可以透過程式設計方式確定，並且聯絡方式可以註冊到建立者的 Auran 帳戶 Planet Auran 帳戶 ，在那裡可以根據需要限制或更新。
contact-website 標籤
[edit | edit source]- 型別： URL 字串。 （已棄用，建議使用可更新的 Planet Auran 資料庫。）
- 欄位定義： 此資產建立者的聯絡網站。 不建議使用此欄位，因為歸屬可以透過程式設計方式確定，並且 [聯絡方式] 可以註冊到建立者的 Auran 帳戶 Planet Auran 帳戶 ，在那裡可以根據需要限制或更新。
已過時標籤
[edit | edit source] |
|
- 在最初的彙編之後，在舊版本的資料模型中發現的一些常用但現在已過時的標籤已在下面新增，例如在許多橋樑資產中發現的 bendy 及其下面的朋友。
|
|
- 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 時代資產的主要資料夾名稱，並且通常是 CM 在開啟檔案進行編輯時開啟的資料夾的名稱； 在今天這樣的早期資料模型資產中，通常會發現 asset-name 也用於早期 Trainz 時代的子資料夾系統，為火車車資產提供了子資料夾名稱“asset-name_art”、“asset-name_body”、“asset-name_shadow”。 在修復此類資產時，大多數情況下可以將值替換為 SAR ，該值從資原始檔複製貼上下來。 此替換通常會正確定義和連結車身、陰影和藝術作品的資產子資料夾，因為早期方案中的檔名基於 asset-name 標籤。
bendy 標籤
[edit | edit source]- 範圍： 在 軌道或橋樑資產 中找到，早於 v2.9 標準，當時樣條線物件經歷了重大變化，成為統一的資料模型定義，放棄了混合中的一些先前型別，而所有樣條線物件都統一在 kind track 下。
casts-shadow 標籤
[edit | edit source]- 參見上面的 bendy，已棄用/過時的前 TS2009 遺留 kind track 標籤。
name 和 name-XX 標籤
[edit | edit source]- 'name' 和 'name-XX' 是較早資料模型形式的較長 username 和 username-XX 標籤，XX 代表非英語語言翻譯的英文“name 標籤”（或今天的“username 標籤”）的 ISO 兩字母后綴； “XX” 形式與 description-XX 一樣，是“本地化”支援其他語言使用者友好值的一部分。
- 在最古老的 Trainz 時代（v1.0-v2.4）資產中將 name 和 name-XX 替換為 username 和 username-XX，或者如果 username(s) 存在，則直接刪除。
- 如果資產具有 trainz-build v2.7 及更高版本，則 name-XX 會導致錯誤。 有趣的是，即使在 TS12 這樣的晚期版本中，name-XX 標籤也會在 Surveyor 工具的搜尋列表中顯示為資產名稱，如果不存在，則會顯示 TrainzBaseSpec。
|
|
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 的放置和選擇工具中驗證資產。 在 TS09 中被廢棄，TS09 使用較短的 category-era 標籤 字串陣列 在單行中，而不是使用多個帶“-nn”字尾的標籤-值對。
- 字串陣列中的空格會導致錯誤；所有值必須以“s”結尾，幷包含四位數字，例如 1880s；1950s；2010s（這可能非常適合某些型別的女性服裝，這些服裝會流行起來然後又過時！）。遺憾的是，目前無法定義範圍，但使用者社群已經提出了此要求。
- 替換為字串陣列型別的 category-era tag，日期程式碼之間不包含空格和分號；這些程式碼以完整的四位數年代數字字尾為“s”（小寫字母 s）給出。
- 已被 category-region 標籤 取代
- 型別 category-region-nn — V1.3–v2.8 —在幾乎所有值得本地化的資產中都有歷史記錄。這些已被 category-region 標籤中的 兩個字母的列舉 ISO 國家程式碼的“字串陣列” 取代。
- 替換為字串陣列型別的 category-region，兩個字元國家程式碼之間不包含空格和分號，這些程式碼在引用的標籤部分中列舉；這些程式碼以兩個大寫字母表示，包含 列舉 程式碼，程式碼之間用“;”分隔符分隔，但最後一個程式碼之前的末尾引號除外。
- 字串陣列中的任何 空格 都會導致讀取錯誤和錯誤資訊，包括結尾引號之前的空格。
- region —TBS V1.3–v2.8 中作為內建過濾器和地圖資產自定義本地化識別符號（kuid）的有效部分；現在，唯一合法的標籤使用方式是在 kind map（佈局）資產中。
- 作為以前的過濾器修飾符，該標籤在幾乎所有資產中都有歷史記錄，但它在機車車輛、場景、樣條線資產、軌道型別（包括隧道和橋樑）以及具有某種程度的本地化的路邊資產中尤為普遍。
- 地圖資產仍然保留關鍵字 Region，該關鍵字在 Map 配置檔案中定義，但使用方式相反，即作為 kind region kuid 引用。因此，Region 在 Map 中是必需的，並且自 TS2012 以來，就像標籤型別一樣，在大量曾經作為 TRS 系列版本 Surveyor 工具視窗中的“分組資料”和“快速過濾器”出現的資產中是非法的。
- 在 TRS2009 之後，任何 region 標籤到文字字串都已過時，因為在程式設計師看來，他們用 Pick List 替換了 Surveyor 工具中“型別和區域”字串值的 粗略過濾 組選擇器。這兩個標籤都有一些優點和缺點，並且都可追溯到 Trainz 0.9 Beta 版本。
- 參見上面的 bendy，已棄用/過時，是 TS2009 之前版本的 kind track 資產模式控制標籤。
thumbnail 標籤是 thumbnails container 的早期單檢視實現（在上面也簡要介紹了）。Trainz 的早期 N3V 之前版本會找到一個 .jpg 檔案，最好是大小為 240x180 畫素，位於主資產根資料夾或 asset-name_art 或 asset-name_body 資料夾中，並將其用於在 CMP 和 DLS 中顯示資產（如果上傳）。自 TRS2006 開始，該標籤已棄用，因為 thumbnails container 在 v2.0（TRS2004-SP0）中引入。在舊的已修復的資產中，如果 TBV 保持在 v2.4 以下，則縮圖通常仍然可以在較新的 CM 中使用，前提是它位於 _art 子資料夾中，並且資產名稱與使用者名稱匹配。
- type — V1.3–v2.8 —以前的過濾器修飾符，在幾乎所有資產中都有歷史記錄，但在機車車輛、場景、樣條線、軌道型別（包括隧道和橋樑）以及路邊資產中尤為普遍。
- type 標籤與“region 標籤”一樣，在 Trainz 0.9—TC3 版本中用作“Surveyor 中的組過濾器”，與 region 結合使用，可以提供更小的資產選擇（工具組）。自 TS2009 以來，已刪除了這些本地可點選過濾器，取而代之的是一個新的、更繁瑣的過濾器。這些過濾器使工具選擇變得快速簡單，而不是在工具選項卡之間切換時變得緩慢並暫停——如今的 TANE 之前版本在工具選項卡之間來回切換時，通常會因重新載入整個選擇列表而不堪重負。
- type 和 region 都預設設定為“All”，提供了與 TS09 及其後版本中工具提供的相同的大型列表。
- ↑ 資產 提交（TANE 的提交）是將內容納入資料庫並將其在 DB 索引中交叉引用以使其可以在執行時模組中訪問的過程和程式。
- ↑ 驗證資產的一種方法是，除了這些值之外，還可以將 TBV 降至 2.5-3.7 範圍，看看這些資訊是否消失。您可能需要在幾次嘗試中將其降低到足夠低的範圍，反之亦然，在較舊的 TBV 中無法識別的較新關鍵字可能會給出不同的錯誤資訊。不要害怕嘗試——即使失敗也能夠積累知識和經驗，而且您不會破壞任何東西！如果是這樣，您可以確信，只需提供一個值就是解決問題的方法。通常，某些現代需求只需要關鍵字對，因此在標籤後面新增一個空白行或在標籤後面新增一個空的方括號，就可以滿足這些需求，而錯誤測試則過於嚴格。
- ↑ 注意：此列表在 N3V TrainzOnline Wiki 上進行了“wiki 化”，這意味著單詞“KIND”之後的第一個字母已大寫，而 config.txt 檔案中的實際資料標籤名稱全部為小寫文字。該 wiki 在很多術語中也使用雙引號，我們將避免在這裡使用這種做法。
- ↑ “kind consist” 並不經常直接看到，它只存在於選單和內容管理器列表中。
- ↑ obsolete-table 必須謹慎使用，最常見於 Auran 編寫的資產中。該表用較新的版本替換了較舊的 kuid，大多數內容建立者都正確地使用 kuid 的 Kuid2 形式來取代較舊的版本。相比之下，N3V 過度使用了 obsolete-table 用於新版本“升級”的內建資產，這會導致很多混亂，並且無法獲得預期看到的內容。（例如，許多不錯的 'Flip-trees' 在 TS10 和 TS12 中被 Speedtrees 取代，這影響了許多路線，而 Speedtrees 在這些路線中是建立者不想要的或不想要的。在安裝過程中，這也會導致缺少依賴項，直到找到包含 obsolete-table 的資產。
• 此外，Assets.tdx 資料庫索引中只支援每個 kuid 的一個 obsolete 條目，用 Kuid2 版本替換 kuid 會導致問題（即您會看到哪個？）。
• obsolete-table 的一個很好的用途是升級使用特定部件（尤其是轉向架）的一系列資產。新增一組要替換為較新良好轉向架的 kuid 可以透過一次編輯來顯著改善路線或場景的外觀（前提是轉向架例如是相容的，並且大小合適！）。 - ↑ 最近將一個過時的資源匯入 TANE 的經驗表明，至少有五個替代 kuids 替代了那個糟糕的 Flip-tree 資源。隨著 Speedtrees 引入帶來的混亂以及 TANE 透過積極追求最新合適的資源進行的大改， ContentManager 現在容忍了多個不同 kuids 的資源替代同一個 kuid。作為良好實踐，僅在絕對必要時才使用過時表格... 例如，在您要上傳到 DLS 或在網站上自行釋出的依賴資源中替換不需要的付費資源。
- ↑ 關於類別時代標籤範圍：已知有效的安全策略。其他“未來十年”值應該在依賴它們之前進行測試。
- ↑ 許多容器在列表中使用虛擬/佔位符名稱。這些可以是描述性詞語，只要它們不包含空格字元即可。在短語構成的名稱中使用下劃線或句點可以保持可讀性並極大地提高畫質晰度。例如，一輛貨運車廂可能裝載 45 種合法產品型別。這些將在依賴關係容器中列出。使用 Coal、granite、crushed_limestone 等可以使維護和更改表格變得更容易。Jes Sayin，自 1976 年起擔任程式設計師
- ↑ 在第二個縮圖容器示例中，有一個額外的 512x512 大小的影像。DLS 將使用哪個影像尚不清楚。也可以包含更大的影像大小，透過電子郵件聊天，T:ANE 可能支援一個大型影像尺寸，該尺寸將在預覽操作或 DLS 列表中找到用途。N3V Games 通常不會發布此類資訊。
- ↑ 早期的做法可以追溯到 Trainz 1.x，即在執行時選單中使用關鍵字/標籤“thumb”和帶引號的路徑規範引用 240x180 的縮圖影像。藝術資料夾包含一個 512x512 的帶有 alpha 遮罩的 tga（通常是 bmp 檔案，但格式正確的 tga 可以用作自遮罩）以及 64x128 的選單圖示影像及其控制的 texture.txt 檔案。
- ↑ 在 2014-2015 年冬季與前版本經理 James Moody 的私人電子郵件對話中，關於此主題的要點是，DLS 上傳驗證軟體可能已經過修改，以強制執行適當的縮圖容器。
- ↑ 關於類別時代-nn 與類別時代標籤值：' TRS 將接受任何形式的類別時代資料；但 TS2009-SP0 及更高版本從以前合法的關鍵字-值對中建立了錯誤，並試圖強制內容建立者更改程式設計師故意破壞的所有資源。後來，DLS 上傳軟體強制執行了轉換，但這要好得多，因為第一個操作花費了很多人力小時來修復不必要的錯誤，這些錯誤應該在驗證舊的 Trainz 構建資源時透過軟體預過濾傳遞自動實現。這些操作實際上保證了舊資源下載將有錯誤。這是 N3V 程式設計師做過的最愚蠢、最傲慢的事情之一，而 Auran 更經驗豐富的軟體人員絕不會如此輕率地對待社群的時間成本。
參考文獻
[edit | edit source]- 此頁面的主體內容來自 N3V TrainzOnline Wiki，來自 KIND_TrainzBaseSpec。增強資訊由 Yesterdayz-Trainz 使用者組成員新增。
腳註
[edit | edit source]- ↑ N3V 的 KIND_TrainzBaseSpec，作為未經增強的源頁面，缺少此處找到的歷史資訊（標籤）；訪問日期：2014 年夏季
- ↑ a b "Trainz-build" 標籤 直接連結
- ↑ 根據 fabartus，2014 年夏季；很可能是新增此示例的同一天。
- ↑ Christoph Bergman，N3V Games 首席程式設計師，又名“Windwalkr”，KIND TrainzBaseSpec 歷史記錄 頁面。
|
此參考頁面改編自 TrainzOnline Wiki，根據 CC-BY-SA 3.0 許可證。此頁面可能會包含比 同一主題的源頁面 更多文字解釋、闡述、歷史記錄和/或示例。 TrainzOnline Wiki 在很大程度上由程式設計師或知識淵博的 內容建立者 維護，並且可能包含有關當前 trainz-build 程式碼 標準的更新資訊，這些標準隨著軟體功能的新增而有所變化。 |