Trainz/refs/TrainzBaseSpec
(重定向自 Trainz/tags/username)
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 構建標籤值以及內容管理器或Content Creator Plus (CCP) 實用程式將分配一個預設值，但在處理它時會列出警告訊息。TrainzOnline 維基、這裡或舊的 TC3 時代 Content Creator's Guide (CCG) 中的許多標籤會提到一個預設值。
- 從 TRS2006 和 Trainz Classics (TC1&2) 開始，每個版本的內容管理器模組都會越來越多地施加預先承諾的錯誤測試[註釋 1]，並且每個模組都變得越來越堅定地警告這樣一個標籤在期望這樣的標籤資料對時沒有被定義。
在 TANE 之後的版本中，許多這些“昨天預設”的定義行今天反而會更頻繁地產生故障，要求明確的值定義，而過去這些值在載入時是預設的。 [註釋 2] 這是一種比舊時代好得多的煩惱，在舊時代，有缺陷的資源定義有時會導致臭名昭著的“藍色畫面宕機”，或者更常見的是將執行時軟體崩潰回桌面，導致編輯丟失，甚至可能需要重建資料庫。
所有 Trainz 定義的資料（內容）都有三個必需的元素：一個config.txt 檔案 用於組織資料，一個標識，表示一個kuid（僅使用者名稱是不行的，但是一個合法的資源可以在沒有名稱的情況下建立！）以及最後，一個合法定義的種類標籤。種類負責，是管絃樂隊的指揮，是排長或 CEO 指揮——為在之後處理的所有內容設定要求。簡而言之，種類值——一個小的、精選的、嚴格定義的會員制團體——告訴 Trainz 軟體在我們要建立的虛擬世界中渲染和顯示什麼，以及如何（或在何處）查詢使這些資源部分在該 config.txt 檔案中連結在一起的其他部分。
下面列出的每個子類都被認為是將TrainzBaseSpec 作為其資料“父類”。 [註釋 3] 下面列出的幾個種類，那些帶下劃線的，是遺留種類，早於TS2009 版本中對Trainz 資料模型 的更改（即 2008 年底以來），N3V 程式設計師只是逐漸（增量式）地施加了變化。
目前，有關基於這些遺留種類的資源修復的詳細資訊可以在 N3V Trainz 維基TrainzOnline 網站 的Content Creator's Guide 部分找到，其中包含遺留種類的示例。強烈建議所有Trainz 下載站 使用者或任何考慮建立內容的人仔細閱讀 CCG。從瞭解舊內容是如何定義的歷史背景中獲得的見解可以與 TrainzOnline 對相同資料型別的當前報道進行對比和比較，因為通常這種“過去與現在”的對比可以為修復、更改和自定義資源提供寶貴的見解。更重要的是，CCG 中的文字是專業製作的，並且更加贅述——它通常會讓你瞭解如果這樣或那樣地更改會產生的擴充套件效果，而 Trainz 維基卻沒有提供這些資訊。TrainzOnline 上釋出的 CCG 是TC1&2/TC3 版本——這是幾本印刷手冊的最後一次出版，這些手冊可以追溯到 1999 年的Trainz；TC3 CCG 包含來自 TRS2004/TRS2006 和UTC 資料模型的經過修改的 Enginespecs 機車資源，需要進行適當的更新。
TBS 標準定義
[編輯原始碼]這些標籤和容器是標準定義，幾乎所有資源中都會用到。一些標籤是可選的，內容建立者可以根據自己的選擇來定義。標籤是關鍵字，並且有一個唯一的分配的 鍵值 或容器，例如 字串陣列 或 '{' ... '}' 繫結封閉的標籤值對或子容器。（在 Trainz 配置檔案中宣告的所有內容都是成對的，即使 '{' ... '}' 被認為是 一個 鍵值。
- 容器是 '鍵' 和 '鍵值' 對的集合 以及 TBS 中的 '上層容器'（與子容器相反，例如縮圖容器中的那些）通常以 '-table' 為字尾。
| 種類 | "'字串值'" |
| trainz-build | '浮點數', 1 位小數 |
| kuid | <Kuid 編碼值> |
| 使用者名稱 | 使用者名稱 "'字串值'" |
| 使用者名稱-XX | 使用者名稱-XX "'字串值'" |
| 描述 | 描述 "'字串值'" |
| 描述-XX | 描述-XX "'字串值'" |
| kuid-table (容器) { 依賴項列表 |
一個鍵值表，列出了此資源依賴的所有資源。 |
| obsolete-table (容器) { } |
kuids 列出了此資源替換的資源（使其過時） 通常為空（空）[注 5] |
| string-table (容器) { } |
資源中使用的字串和訊息的鍵值列表 通常為空，在路線和會話中很大。 |
| string-table (容器) { 非英語 語言文字 } |
翻譯字串列表 匹配到 強制性的英語 string-table |
| category-region 標籤 列舉 程式碼 | category-region "'字串陣列'" |
| category-class 標籤 | category-class "'列舉 字串值'" |
| category-era 標籤 | category-era "'受限字串陣列'" 年代 |
| category-keyword "'字串陣列'" 最大長度為 64 位元組 | category-keyword 標籤 自然語言搜尋關鍵字 (替換型別、地區) |
| 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 | "作者/組的網站網址 '字串值'" |
| member-of-groups (容器) { } |
此資源所屬的 KIND 資源組 資源列表。 |
TrainzBaseSpec 在 config.txt 檔案 中支援以下標籤。 ∅:
- 型別: 字串。
- 欄位定義: 此 config.txt 檔案 所代表的資源型別。請參見索引 種類 和列表: 這裡（上面）
- KUID
- 'Koolthingz Unique IDentifier'. Trainz 系統軟體為資源分配的 唯一資料庫參考號，也擴充套件到在 KUID2 形式中跟蹤多個版本。Trainz 可升級性和資源模組化設計的核心，因為每個資源都有自己唯一的 kuid 程式碼，因此可以在新資源中指定一個元件（轉向架）或整個火車車廂，並選擇性地替換新資源中的任一個（重新蒙皮或修改卡車）。
- 基本 KUID 格式: '<kuid:wwwwww:xxxxxx>'，其中 wwwwww 是 作者的 '唯一 Trainz 身份'，xxxxxx 代表作者分配的 模型識別程式碼。
 |
|
- 大多數 Trainz 資源在其 kuid-table 中指定了一個依賴項列表，其他元件資源是由軟體套件的各個部分組裝在一起，在 kuid-table 容器 中形成一個可渲染和可用的資源。
- 在許多資源的核心，特定的標籤可以透過 kuid 引用 來定義，並使用引用的資源作為一部分。 事實上，這就是重新蒙皮的實現方式，並且可以使用資源中的網格，儘管更現代的做法建議將這種引用指向網格庫資源。
- KUID2
- KUID 格式的更新和更新跟蹤修改版本，它允許指定版本號。
<kuid:xxx:yyy>等同於<kuid2:xxx:yyy:0>（零修訂或版本零，表示原始版本）- 這允許資料項（Trainz 資源）攜帶資源的固有版本程式碼。這通常不會與 CM Trainz-build 程式碼 相匹配，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 的程式設計師團隊看來，無論前臺如何炒作營銷名稱 (比如 Trainz UTC，是最終的什麼東西... 真的嗎？。 come'on man！Seriously!!?)，TRS2004 版本都是第二款 Trainz 產品。
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 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 版本進行猜測，通常會解析為 1.3 的 TBV 值。
- 型別: UTF-8 字串，資源的使用者名稱，強制性規範。
- 欄位定義: 此資源的英文人機可讀名稱。
在 TC1&2 (v2.7) 之後的 trainz-builds 中，使用者名稱在編輯資源時也成為作業系統資料夾名稱，並且資原始檔名被忽略，而以前它在 v2-6 配置檔案中具有優先順序。根據 N3V games 的 TBS 標準，此欄位絕不包含非英語文字，除非資源名稱是專有名詞 (例如地名) 且沒有英語本地化變體。此值是每個人通常搜尋和記住的資料，因此建議使用清晰的名稱。
 |
|
- 型別: UTF-8 字串，使用者名稱標籤 的替代語言版本。
- 欄位定義: (其中XX 被替換為適當的 本地化程式碼，用於表示該語言。) 此資源的本地化人機可讀名稱。此欄位類似於使用者名稱欄位，只是表示非英語語言環境。資源中可能存在多個username-XX 標籤，每個支援的語言環境一個。如果在給定終端使用者系統上沒有適當的“username-XX”標籤來表示此資源，則使用英文使用者名稱標籤。
- 型別: UTF-8 多行字串，提供資源的清晰語言描述。
- 欄位定義: 此資源的英文人機可讀描述性摘要。
該描述在內容管理器“資源詳細資訊”窗格中可見，用於闡明資源名稱、提供規格，通常還包含一些歷史資訊。
N3V 的 Chris Bergmann 表示，此欄位應保留為簡短的 (1-2 段) 說明資源的簡短說明，並應透過info-url 頁面提供擴充套件詳細資訊，但會容忍相當長的文字塊。有些人使用文字塊的底部作為版本更改記錄。
此欄位必須由英文描述性文字組成，儘管文字可能像其他地方解釋的那樣引用非英語專有名詞。其他語言翻譯或源文字應放置在許多可能的替代語言本地化標籤中的一個 (參見 description-xx 標籤)。
- 型別: UTF-8 多行字串，描述標籤。
- 欄位定義: (其中XX 被替換為適當的 本地化程式碼，用於表示該語言。) 此資源的本地化人機可讀描述性摘要。此欄位類似於描述欄位，只是表示非英語語言環境。資源中可能存在多個description-XX 標籤，每個支援的語言環境一個。如果在給定終端使用者系統上沒有適當的“description-XX”標籤來表示此資源，則使用英文描述標籤。
- 型別: UTF-8 字串列表容器，字串表容器 (s)。
- 欄位定義: 英文字串的鍵值列表。每個鍵都是一個有意義的指令碼識別符號，對映到二進位制資料並被二進位制資料引用。每個值都是一個英文字串。英文字串可能包含或引用非英語專有名詞作為識別符號。非英語母語作者建立的資源仍然必須建立無後綴的 string-table 容器 (如果需要)。軟體只連結到並引用 string-table 容器中的名稱和值，而不會使用字尾，這必然會讓西班牙語、法語、德語、捷克語、荷蘭語... 日語作者感到沮喪。換句話說，帶字尾的字串表純粹是為了翻譯目的而存在的，這在以非英語語言編寫的地圖時會產生問題——沒有 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。
- 型別：UTF-8 字串列表容器，本地化字串表，每個字尾對應於除英語以外的語言。
- 欄位定義：（其中XX被替換為相應的本地化程式碼，用於表示正在使用的語言。）此欄位類似於string-table欄位，但表示非英語區域設定。
英語字串表（無後綴）是強制性的，其他本地化語言是可選的，由資產作者決定。許多提交給 DLS 並在 Trainz 版本捆綁的路線中使用的資產通常會被翻譯，並有一套完整的本地化翻譯，用於 description-XX 和 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 槽，這將建立一個需要自身舊版本的迴圈定義！）
- 類似地，某個資產不能列為其自身的依賴項。[另一方面，這已經得到過驗證（例如，在 TSxx CMs 中作為已成功提交的無故障資產被見證），在安裝之間使用 GSARS 移植地圖和會話以更改 kuids，以便重疊不會覆蓋已經在目標安裝中使用相同 kuids 的資產，而不會出現錯誤訊息。] 至於它是否也起作用，需要比我更勇敢或更愚蠢的人來驗證！——Fabartus，編。
- 格式(所有值均為<kuid:aaaaa.bbbbb>格式)
kuid-table {
0 Kuid-1
1 Kuid-2
3 Kuid-3
... kuid-ii
N-1 Kuid-N
}
|
|
- 這些引數是虛擬引數這一事實的一個非常有用的利用方式是將複雜滾動庫存資產中產品的 kuids 配對。一輛貨車可能包含各種各樣的產品... 獲得許可將你的作者 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 新增到載荷和允許的產品隊列表條目中的位置。（不客氣，但這確實是一個更改名稱的好理由！保持事情井井有條几乎是製作資產的全部戰鬥！）
- 型別：KUID 列表容器，與 Kuid-table 容器 格式相同。
- 欄位定義：一個“佔位符鍵—鍵-值”資產列表，這些資產被此資產標記為已過時。任何嘗試載入此列表中的任何資產都將導致改為載入此資產。
- 此外：兩個資產都標記第三個資產為已過時是非法的，除非這兩個資產中的一個也標記另一個為已過時。[註釋 6]
- 迴圈過時引用是非法的。
- 此資產的所有低編號 KUID2 版本都隱含為已過時，無需包含在此列表中。同時，較新的改進資產具有較高的 Kuid2，並且它的其中一個前身永遠不應該將相同的前身（如原始版本！）列入“中間”中間前身—因為這些值用作替代條目表，並且只有一個資產可以替換為早期版本。（陣列只儲存一個值，不能用兩個值替換一個！）
- 將此資產的較高編號 KUID2 版本標記為已過時是非法的，因為這會建立一個隱式迴圈引用。
- 此列表中引用的資產必須與此資產具有相同的建立者，才能使資產透過 DLS 上傳流程進行稽核和接受，此限制不適用於您的本地版本，例如，它可能用於用一個圖形上更令人愉悅且更新的版本替換火車車上的所有舊紙輪 kuids。
- 用途：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"（大多數第一世界國家）
- 用途：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-2010s[註釋 7]
- 此資產的唯一意義是對其他人類來說，即此資產在指定的時代範圍內被認為是有效的且適當地相關的，並且 Content Manager 將接受指定適用年份的搜尋過濾器。
- 示例
category-era "1920s;1930s;1940s;1950s"
- 用途：CM 和 Surveyor 中的過濾器（搜尋條件）
- 型別：縮圖容器。
- 欄位定義：在整個遊戲環境中（包括在遊戲中、在 Content Manager 中以及在 Download Station 上）用於在 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"
}
}
另一個常見的尺寸是 Railyard 和測量員資產選擇 API 中使用的 128x64“圖示”，它應該有一個 Alphamask 或非常淺的背景。許多較舊的沒有使用 jpg 檔案，而是在“_art”子資料夾中列出了 .tga 檔案（Targa True Color）（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]。
- 型別：URL 字串。
- 欄位定義：一個指向線上資產描述、資產說明（幫助）或 TrainzOnline wiki 上其他幫助頁面的連結，用於從嵌入式專用 N3V 瀏覽器中使用。URL 必須解析到 Trainz 線上安全區 內的站點。目前，嵌入式瀏覽器接受三個域名
auran.com
ts2009.com
ts2010.com
此外，建議使用自定義 Trainz 短連結 格式，而不是直接連結到這些域名，以防備未來站點佈局可能發生的更改。“短連結”是 Trainz 特定的 URL，透過允許內容建立者引用 N3V 網站上的特定頁面而不依賴於特定的網頁佈局，從而幫助將內容的未來證明。短連結用於遊戲內使用，例如資訊 URL 連結，並且僅在嵌入式 Web 瀏覽器中有效，而不在任何外部 Web 瀏覽器中有效。在存在此標籤的地方，遊戲內按鈕將允許使用者在不離開遊戲環境的情況下檢視資產描述或幫助。
這在駕駛員中可能非常有價值，可以用來訪問路線地圖、指南或任務說明或澄清。
建議在任何情況下都使用通用組頁面來表示整個類別的資產，只要這些資產提供類似的功能，但在外觀上存在細微差異即可。這減少了建立、維護和本地化此類文件的時間成本。
- 型別：ASCII 字串。
- 欄位定義：必需產品許可權的列表，以分號 (;) 分隔。如果本地安裝沒有所需的產權，則某些遊戲系統可能無法載入該資產。
- 型別：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”副檔名，如果路徑具有其他副檔名。
- 型別: 字串。
- 欄位定義：指示要載入的指令碼類名稱，作為此資產的主類，如果有的話。此類從此資產的主指令碼檔案載入。
- 型別：kuid 引數列表及其對應的名稱作為鍵。
- 欄位定義：一個鍵值表，其中包含在編譯此資產指令碼檔案時搜尋指令碼包含的指令碼化資產。鍵（一個變數，因此不是一個標籤）目前未使用，但必須是唯一的；值表示要包含的資產的 KUID。
指令碼包含表容器 是 KIND TrainzBaseSpec 派生的任何資產（簡而言之，所有資產）可用的頂級 config.txt 檔案 條目。此容器允許資產直接 包含另一個資產的指令碼 來自父資產的指令碼檔案，使用 N3V TrainzScript 的 Script_Include_Directive。
- 相關
擴充套件容器是具有特定命名約定的自定義標籤或子容器列表。
此容器是指令碼化資產名稱及其 kuids 的簡單鍵值表，在編譯資產指令碼檔案時搜尋這些資產以進行指令碼包含。鍵或標籤名稱目前未使用（即，是一個 佔位符引數）在搜尋中；值表示要包含的資產的 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 container
- 型別: ASCII 字串陣列容器。
- 欄位定義: 自定義類別識別符號列表，用分號 (;) 分隔。每個 自定義類別識別符號 應該是簡短的（例如，3-6 個字元）字母數字標記。字串中不應存在其他字元（包括空格）。
- 這些自定義類別用於使指令碼能夠快速定位特定類別的資產。強烈建議謹慎引入新的自定義類別識別符號。
- custom-category-list 標籤值總共不超過 64 個字元。除非存在只能透過自定義類別列表方法實現的現有特定指令碼要求，否則應將此標籤留空。
- 最低版本: V3.5 及以上
- 型別: 成員組容器 成對的 佔位符引數 和 資產組 KUID。
- 欄位定義: 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 費用是為了更快地訪問和無限次下載，而不是為了訪問資產。）
- DLS 上的大多數資產都是 帶署名的知識共享署名-相同方式共享（CC-BY-SA）的措辭不當的版本，如本維基百科和其他維基媒體專案。
- 許可標籤的含義模稜兩可，N3V 不建議使用它，但它的存在早於 N3V 的管理 6-7 年。
- 上傳到 下載站 或用於包含到遊戲中的內容可能受特定的重新分發合同或許可協議的約束，該協議取代此欄位中的任何文字。許可欄位不提供本地化支援。許可欄位的文字未經 Auran 或 N3V 驗證或強制執行，可能對終端使用者具有法律約束力也可能沒有法律約束力。
- 另一方面，Planet Auran 的歷史表明，任何透過使用他人的內容作為自己的內容來侵犯版權的人，都可能被 Auran 網站迅速禁止，並永久遮蔽下載站的許可權等。此外，社群將嚴厲打擊其他使用者侵犯他人版權的行為，並回避違規者，並忽略 DLS 上允許保留的任何資產。
- 總之，實驗和修改資產是 Trainzer 嘗試克服陡峭的內容建立學習曲線（每個人都希望有更多內容建立者！）的一種公認甚至默許的方式，但如果資產有依賴部件，尤其是網格、指令碼、紋理，這些是智慧財產權——在上傳您的作品之前，請獲得使用屬於他人的那些部分的許可。
|
|
- 型別: UTF-8 字串。（被可更新的 Planet Auran 資料庫 棄用。）
- 欄位定義: 作者姓名或標記。不建議使用此欄位，因為屬性可以透過程式設計確定。
- 注意英國拼寫，北美拼寫“organization”也適用！
- 型別: UTF-8 字串。（被可更新的 Planet Auran 資料庫 棄用。）
- 欄位定義: 負責建立此資產的組織的名稱或標記。不建議使用此欄位，因為屬性可以透過程式設計確定。
- 型別: 字串，電子郵件地址。（被可更新的 Planet Auran 資料庫 棄用。）
- 欄位定義: 此資產建立者的聯絡電子郵件地址。不建議使用此欄位，因為屬性可以透過程式設計確定，並且聯絡資訊可以針對建立者的 Auran 帳戶 Planet Auran 帳戶 註冊，在那裡可以根據需要限制或更新。
- 型別: URL 字串。（被可更新的 Planet Auran 資料庫 棄用。）
- 欄位定義: 此資產建立者的聯絡網站。不建議使用此欄位，因為屬性可以透過程式設計確定，並且 [聯絡資訊] 可以針對建立者的 Auran 帳戶 Planet Auran 帳戶 註冊，在那裡可以根據需要限制或更新。
|
|
- 在初始編譯之後，一些在舊版資料模型中發現的常見但現在已過時的標籤已新增到下面，例如，在許多橋樑資產中發現的 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 Trainz 時代資產的主要資料夾名稱，並且通常是 CM 開啟檔案進行編輯時開啟的資料夾的名稱；在這樣的早期資料模型資產中，人們通常會發現 asset-name 也被用於早期 Trainz 時代的資料子資料夾系統，給子資料夾命名為 '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 之前的 legacy 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）資產中用 username 和 username-XX 替換 name 和 name-XX，或者如果存在 username，只需刪除。
- 如果資產的 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 中驗證在 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 關鍵字，該關鍵字是在地圖配置中定義的，其用途相反——作為 kind region kuid 引用。因此，Region 在地圖中是必需的，並且從 TS2012 開始，就像標籤型別一樣，在曾經出現過該標籤的眾多資產中是違法的，這些資產曾經將該標籤用作 TRS 系列版本 Surveyor 工具視窗的“分組資料” “快速過濾器”。
- 在 TRS2009 之後，任何 region 標籤到文字字串都是過時的，因為在程式設計師的思維中，他們用 Pick List 替換了 Surveyor 工具中 'type and region' 字串值的粗略過濾分組選擇器。這兩個標籤都有一些優點和缺點，它們都可追溯到 Trainz 0.9 Beta 版本。
縮圖標籤是縮圖容器（上面也有簡要介紹）的早期單檢視實現。早期預-N3V 程式設計師版本的 Trainz 會在主資產根目錄或資產名稱_art 或資產名稱_body 資料夾中查詢一個 .jpg 檔案（最好大小為 240x180 畫素），並將其用於在 CMP 和 DLS 中顯示資產（如果上傳了）。該標籤在 TRS2006 期間已棄用，因為縮圖容器是從 v2.0（TRS2004-SP0）開始引入的。在較舊的已修復資產中，如果TBV 保持在 v2.4 以下，只要縮圖在 _art 子資料夾中且資產名稱與使用者名稱匹配，縮圖通常仍然可以在較新的 CM 中正常工作。
- type — V1.3–v2.8 — 以前的一個過濾器修飾符，在歷史上幾乎所有資產中都存在，但在滾動庫存、景觀、脊椎、軌道型別（包括隧道和橋樑）和軌道旁資產中尤為普遍。
- 型別標籤與“區域標籤”一樣，在 Trainz 0.9—TC3 版本中作為“Surveyor 中的組過濾器”使用，它與區域結合在一起，提供了更小的資產選擇（工具組）。自從TS2009 去除了這些本地可點選過濾器的功能和用途，轉而採用了一種新的、更繁瑣的過濾器。這使得工具選擇變得快速而簡單，而不是在工具選項卡之間切換時變得緩慢並暫停——如今的預-TANE 版本在工具選項卡之間來回切換時，往往會因為重新載入整個選擇列表而顯得不堪重負。
- 型別和區域都預設設定為“全部”，與 TS09 及以後版本中工具提供的超級列表相同。
- ↑ 資產提交（TANE 的提交）是將內容整合到資料庫中並將其交叉引用到資料庫索引中的過程和步驟，以便在執行時模組中訪問它。
- ↑ 驗證資產的一種方法是，除了這樣的值之外，一切正常，將 TBV 降低到 2.5-3.7 範圍，看看這些訊息是否消失。您可能需要降低它，進行多次嘗試，直到足夠低，反之亦然，在較舊的 TBV 中無法識別的較新的關鍵字可能會給出不同的錯誤訊息。不要失敗嘗試，即使失敗，也會產生知識和經驗，而且您不會破壞任何東西！如果是這樣，您可以確信，僅提供一個值就是問題的解決方案。通常，一些現代需求只需要關鍵字對，因此在標籤後面加一個空白行或在標籤後面加一對空花括號（對於容器來說）就可以滿足需求，而錯誤測試則過於嚴格。
- ↑ 注意：此列表在 N3V TrainzOnline Wiki 上已“維基化”，這意味著在“KIND”一詞後面，首字母已大寫，而 config.txt 檔案中的實際資料標籤名稱是全小寫文字。該維基還使用雙引號來表示許多術語，這種做法我們將在本文中避免。
- ↑ “kind consist” 並不經常直接看到，它只存在於選單和內容管理器列表中。
- ↑ 過時表必須謹慎使用，最常出現在 Auran 創作的資產中。該表用較新的版本替換了較舊的 KUID，大多數內容建立者正確地使用kuid 的 Kuid2 形式來取代較舊的版本。相比之下，N3V 過度使用過時表來更新新版本“升級”的內建資產，這會導致很多混亂，並且無法獲得預期的結果。（例如，許多漂亮的“翻轉樹”在 TS10 和 TS12 中被淘汰，轉而採用加速樹，這影響了許多路線，因為路線建立者並不需要也不想要加速樹。在不同的安裝程式中，這也導致依賴項缺失，直到找到包含過時表的資產。 • 此外，Assets.tdx 資料庫索引中每個 KUID 只支援一個過時條目，用 Kuid2 版本過時 KUID 會導致問題（即，您會看到哪個？）。 • 過時表的絕佳用途之一是使用特定部件升級一系列資產，尤其是轉向架。新增一個混合的 KUID 集，用新的好的轉向架替換它們，可以顯著改善路線或會話的外觀，只需進行一次編輯（前提是轉向架，例如，相容且尺寸合適！）。
- ↑ 最近將一個已過時的資產引入 TANE 的經驗表明，至少有五個備用 KUID 過時了那個可憐的翻轉樹資產。似乎隨著加速樹的引入所帶來的混亂，以及 TANE 在積極尋求最合適的更新資產方面所進行的全面改革，ContentManager 程序現在容忍多個不同 KUID 的資產來過時同一個 KUID。作為一個好的做法，只有在絕對必要時才使用過時表……例如，用您想上傳到 DLS 或在網站上自行釋出的依賴資產中不想要的付費資產來取代它。
- ↑ 關於類別時代的標籤範圍：安全遊戲，已知有效。其他“未來十年”值應在依賴此類值之前進行測試。
- ↑ 許多容器在列表中使用虛擬/佔位符名稱。這些可以是描述性詞語，只要它們不包含空格字元即可。在短語構造的名稱中使用下劃線或句點可以保持可讀性，並顯著提高畫質晰度。例如，一輛貨運火車車廂可能運輸 45 種合法產品型別。這些將在依賴項容器中列出。使用 Coal、granite、crushed_limestone 等可以使維護和更改表更加容易。Jes Sayin 作為程式設計師自 '76 年以來
- ↑ 在第二個縮圖容器示例中，有一個第二個 512x512 大小的影像，一個額外的影像。DLS 使用哪個影像尚不清楚。也可以包含更大的影像尺寸，透過電子郵件聊天，T:ANE 可能支援一個更大的影像尺寸，它將在預覽操作或 DLS 列表中找到用途。N3V Games 通常不會透露此類資訊。
- ↑ 早期的做法可以追溯到 Trainz 1.x，使用關鍵詞/標籤“thumb”，在引號中包含一個路徑規範引用，指向用於執行時選單的 240x180 縮圖影像。art 資料夾包含一個帶有 alpha 遮罩的 512x512 tga（通常為 bmp 檔案，但格式正確的 tga 可以用作自 alpha 遮罩），以及 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，作為未經修改的源頁面，缺少此處找到的歷史資訊（標籤）；accessdate=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 程式碼 標準的更新資訊，這些標準隨著軟體功能的新增而不斷變化。 |