Trainz/refs/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）以及其他定義、適用性和範圍變化很大的資料，例如字串表、過時表、kuid 表和縮圖影像都是具體情況而定的。即使是資源名稱和描述之類的字串值，在實踐中也往往完全沒有必要，並且可以完全省略。
- 當宣告一種種類時，該種類就成為父類，除了 TBS 中列出的那些資料外，還需要並規定必須在類中滿足必要的成對資料。
- 某些引數可以在資源種類的特定情況下保持未定義，尤其是在舊版 Trainz 版本標籤值中很常見，對於這些引數，內容管理器或Content Creator Plus（CCP）實用程式會分配一個預設值，但在處理時會顯示警告訊息。TrainzOnline 維基、此處或舊版TC3 時代內容建立者指南（CCG）中的許多標籤會提到一個預設值。
- 從 TRS2006 和 Trainz Classics（TC1&2）開始，每個版本的 Content Manager 模組都強加了越來越多的預提交錯誤測試[註釋 1]，並且每個版本都變得越來越堅持在期望這樣的標籤-資料對時警告尚未定義這樣的標籤。
在 TANE 之後的版本中，許多這些“昨天是預設值”的定義行今天反而會更常生成錯誤，要求在過去載入時是預設值時提供明確的值定義。[註釋 2]與過去資源定義錯誤有時會導致臭名昭著的“藍色畫面宕機”或更常見的情況是，使執行時軟體崩潰回桌面，導致編輯內容丟失，並可能需要重建資料庫相比，這是一種更好的惱人情況。
所有 Trainz 定義的資料（內容）都包含三個必需元素：一個config.txt 檔案 用於組織資料，一個標識，即kuid（僅使用者名稱是不夠的，但是可以建立合法的資源而無需名稱！）以及最後，一個合法定義的 kind 標籤。kind 負責指揮，是樂隊的指揮，是排長或 CEO 指示——為後續處理的所有內容設定要求。簡而言之，kind 的值，一個小型、精選、嚴格定義的僅限成員的組——告訴 Trainz 軟體在建立的虛擬世界中渲染和顯示什麼，以及如何在（或在哪裡）找到在該 config.txt 檔案中將資源的這些部分連結在一起所需的其他部分。
以下每個子類都被認為具有TrainzBaseSpec 作為其資料“父類”。[註釋 3]下面列出的一些種類，帶下劃線的那些是過時的種類，早於TS2009 版本中對Trainz 資料模型的更改（即 2008 年後期以來），N3V 程式設計師自那以後只強加了漸進的（增量的）更改。
目前，有關基於這些過時種類修復資源的詳細資訊可以在 N3V Trainz 維基TrainzOnline 網站此處的內容建立者指南部分找到，並提供了有啟發性的過時種類的示例此處。強烈建議Trainz 下載站的任何使用者或任何考慮建立內容的使用者仔細閱讀 CCG。可以將對舊內容定義方式的背景歷史的理解與 TrainzOnline 對相同資料型別的當前覆蓋範圍進行對比和比較，因為這種過去與現在的對比通常可以提供有價值的見解，用於修復、更改和自定義資源。更重要的是，CCG 中的文字是專業製作的，並且更具同義反復性——它通常會讓你瞭解如果更改這一點或那一點會導致的擴充套件影響，而 Trainz 維基則沒有提供這些資訊。TrainzOnline 上提供的 CCG 是TC1&2/TC3 版本——這是自 1999 年Trainz以來的幾本印刷小冊子的最後一個出版版本；TC3 CCG 包含來自 TRS2004/TRS2006 和UTC資料模型的已更改的 Enginespecs 機車資源，需要正確更新。
TBS 標準定義
[編輯原始碼]這些標籤和容器是標準定義，幾乎所有資源中都可能找到。某些標籤是可選的，內容建立者可以根據自己的選擇不定義它們。標籤是關鍵字，並分配單個鍵值或容器，例如字串陣列或'{' ... '}' 繫結封閉的標籤值對或子容器。（Trainz 配置檔案中宣告的所有內容都是成對的，即使 '{' ... '}' 也被視為一個“鍵值”。
- 容器是“鍵”和“鍵值”對的集合以及TBS 中的“上層容器”（與縮圖容器內的子容器相對）通常以“-table”作為字尾。
| kind | "'字串值'" |
| trainz-build | 'float'，一位小數 |
| kuid | <Kuid 編碼值> |
| username | username "'字串值'" |
| username-XX | username-XX "'字串值'" |
| description | description "'字串值'" |
| description-XX | description-XX "'字串值'" |
| kuid-table (容器) { 依賴項列表 |
一個鍵值表，列出此資源依賴的所有資源。 |
| obsolete-table (容器) { } |
此資源替換（使之過時）的 kuid 列表 通常為空（空）[註釋 5] |
| string-table (容器) { } |
資源中使用的字串和訊息的鍵值列表 通常為空，僅在路線和場景中較大。 |
| string-table (容器[s]) { 非英語 語言文字} |
翻譯字串列表匹配到強制的英語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 程式碼（標識軟體技術級別）不匹配，但指示以前的版本歷史記錄。
- 如果資料庫中同時存在這兩個資源，則具有較高字尾程式碼的 KUID2 資源將覆蓋或替換舊資源。擁有早期版本不是必需的，但CM 會將缺少的修訂鏈列為缺少的依賴項，對於那些討厭 CM 中該功能被汙染的人來說，這是一個軟體錯誤，或者程式設計師保留了該功能，無論如何都會降低使用 CM 來識別使用者缺少什麼的效用，並導致使用者花費時間手動找出什麼是真正的什麼。
- 主要涵蓋範圍：trainz-build 標籤，縮寫：TB & TBV (TB 值)∅
- 型別：一位小數浮點數，由 N3V[2]列舉，用於跟蹤和識別與軟體演進的技術水平相對應的資料型別。
- 範圍：1.0–4.3，直接對應（'對映到3rd' Trainz 1.0—TANE-SP1+hf2；此值預計會隨著每次新的主要軟體升級而逐步增加 0.1。
每個合法值必須完全匹配已釋出的 Trainz 版本號，但以下情況除外
- 分配 V1.4 的TBV 或版本值為 Auran 的Paintshed 釋出版，這是一種也適用於Microsoft Trainz Simulator (MSTS) 的重製工具，並且也作為 TRS2004 輔助軟體模組的構建值出現；具體來說，它是ContentManager.exe 實用程式。
- 1.7 和 2.0 之間的差距可能是外語版本，或者正如在經過數小時的挖掘和研究後更有可能的那樣，Auran 未使用，因為在構建原始 Trainz 的程式設計師團隊看來，無論前臺如何炒作營銷名稱（例如 Trainz UTC，是最終的任何東西……真的嗎？。拜託！真的！！？），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）遞增 0.1。
- 從 v2.0（TRS2004）開始，Trainz-build 標籤數值已透過 23 個步驟增加，這些步驟雖然不是單調的，但卻是連續的，因為 Trainz TS09-sp3—TS09-sp4 共享一些Trainz-build[2]值；也就是說，在 TS2009 和 TS2010 的聯合開發和釋出時代，有一些共同的 TBV 重疊。
- 此外，N3V 進軍 Macintosh 計算機領域打斷了基於 Windows 的 Trainz 版本 TBV 的平滑遞增，TBV 3.4、3.5、3.6、3.7 和 3.8 在基於 Windows 和 Mac 的作業系統之間交織。
注意：熱修復不會更改版本號。
- 欄位定義：此資源構建（和存檔）到的檔案格式版本，不一定與資源使用的技術級別有任何關係，但對應於在Content Creator Plus中建立資源時分配的資源級別——與在CM的標題欄中找到的級別相同。
- 程式設計師建議此數字通常應設定為正在建立和測試資源的 Trainz 安裝的 Trainz 版本號。相比之下，內容建立者社群試圖將此數字設定得儘可能低，以便在下載時為新資源提供儘可能廣泛的受眾/使用者範圍。更好的內容建立者會將其在相應版本的裸機安裝（無附加內容）上進行測試，並驗證生成的 cdp 是否包含所有相關材料。
- 某些資源型別根據其trainz-build版本標籤的解析方式存在顯著差異。注意：trainz-build 標籤是強制性的。如果未指定，Trainz 將基於config.txt 檔案的內容嘗試進行基本猜測以確定舊版 Trainz 版本，這通常會將 TBV 解析為 1.3 的值。
- 型別：UTF-8 字串，資源的使用者名稱，強制性規範。
- 欄位定義：此資源的英文人類可視名稱。
在 TC1&2（v2.7）之後的 trainz-build 中，當編輯資源時，使用者名稱也成為作業系統資料夾名稱，並且忽略資原始檔名，而在 v2-6 配置檔案中，它具有優先順序。根據 N3V 遊戲的 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 字串列表容器，字串表容器。
- 欄位定義：一個英文字串的鍵值對列表。每個鍵都是一個有意義的指令碼識別符號，對映到二進位制資料並由其引用。每個值都是一個英文字串。英文字串可以包含或引用非英文專有名詞作為識別符號。非英語母語作者編寫的資源，如果需要，仍然必須建立一個沒有後綴的字串表容器。軟體僅連結到字串表容器中沒有後綴的名稱和值，並引用它們，這會讓西班牙語、法語、德語、捷克語、荷蘭語……日語作者感到惱火。換句話說，帶字尾的字串表僅用於翻譯目的，這在使用非英語編寫地圖時會帶來問題——沒有 string-table-en 可以提供反向翻譯的表格。同樣，username-en 和 description-en 也是如此。所有這三者都缺乏表現出一種過時且漫不經心的傲慢和對世界動態的漠不關心。
其他語言由類似的字串表（例如 string-table-XX）支援，帶有一個本地化程式碼字尾 (XX)，該字尾與描述和使用者名稱關鍵字/標籤的國際化字尾匹配，但這些語言鍵控字串表容器的左側條目始終具有相同的鍵值。
- 這些左側的鍵或標籤既用作“本地索引關鍵字”，也用作“語言之間的等價表”。
- 左側列始終包含內容建立者賦予“特殊”名稱的物件，例如訊號、軌道標記和行業、連線點等的名稱，這些名稱可能會被引用，並顯示在駕駛員和測量員模組的“查詢公用設施”（CTRL+F ) 功能小程式中。
- 相反，索引側也不會列出預設的名稱，例如在構建路線圖時由隨機數字自動索引的大量連線點（即無意義的雜亂。如果重要，路線構建 CC 將命名它！），但會自動包含潛在的臨時資產，例如火車車的預設名稱。如果重新命名，這些名稱將取代其相應的預設名稱。
- 其主要用途是針對那些旨在與指令碼引用互動並採用可變屬性的物件，例如火車站或行業所需或準備發貨的產品數量，或互動式火車車（對指令碼而言是移動的行業）和其他可配置資產，例如簡單的通用廣告牌樣式標誌，透過稍微調整高度和角度，可以放置在庫存建築或行業的正面，以便在建築物上放置不同的商業名稱。換句話說，這是一種可配置的場景。
- 總體而言，在路線圖或佈局中，這些左側的名稱對應於地圖資產上的命名物件，並且大多數字符串表都在這裡可見（從字面上看，由大型路線種類地圖中的數千個條目填充）。
- 在某些資產中，該預設名稱已連線到軟體指令碼，因此字串表變得特別重要，而不是枯燥乏味。（見下文）
- 在任何型別的資產中使用字串表型別始終是合法的，就像描述標籤和 trainz-build 和 kind 標籤一樣。與這些不同，它不必存在或定義，並且絕不是強制性的。除非程式碼期望它們的結合，否則封裝在字串表容器中的值沒有任何功能或效果。
- 在其他資產中，再次以那個假設的可程式設計商業標誌為例，如果該字串表要與軟體互動，則必須為其提供預設名稱。所有地圖可放置資產都可以命名或重新命名，但“特殊名稱”必須與指令碼和字串表索引值匹配。大多數可配置資產定義了一個介面變數，該變數用於替換預設名稱作為索引或查詢表引用的指令碼以及資產的二進位制資料。其他變數也可能在可程式設計資產中定義。指令碼可以引用這些變數中的每一個，但正是索引值使它進入地圖或會話字串表，從而使所有內容在需要駕駛員或會話建立者可變性時協同工作。
- 相反，如果系統軟體不知道索引中命名的專案的位置，則物件的指令碼可能不會觸發、進行條件檢查或能夠更新。這是 2000 年代Trainz 1.0中物件的特徵，而不是 2003 年釋出的TRS2004之後的更現代的 Trainz 鐵路模擬器。（從那時起，我們已經走了很長一段路了！）
- 有一些資產只能作為一個組一起工作。在這種情況下，在對映或會話層中命名每個資產可以使它們一起工作。例如，考慮一個有五條軌道的公路平交道，其中兩條軌道位於連線點之外，並與直通軌道形成所謂的“菱形交叉”。如何設定訊號以使任何鐵路交通關閉公路閘門，或者如何使用菱形交叉禁止其他火車透過正在穿越交叉的火車？道路和鐵路訊號以及道岔和閘門都必須協調工作。某些“ATLS 系統”資產及其指令碼與字串表的結合可以使該複雜系統發揮作用。
- 請參閱字串表-XX 以獲取更多資訊。
- 型別：UTF-8 字串列表容器，本地化的字串表，每個字尾對應於英語以外的語言。
- 欄位定義：（其中XX替換為表示的語言的相應本地化程式碼。）此欄位類似於字串表欄位，但表示非英語語言環境。
英語字串表（無後綴）是強制性的，其他本地化語言是資產作者的可選內容。許多提交到 DLS 然後也用於與 Trainz 版本捆綁的路線的資產通常會被翻譯，並具有描述-XX 和字串表的一整套本地化翻譯。特別是，與版本捆綁的路線和會話在每次零售版本釋出時都會進行專業翻譯成多種語言。
請注意，字串表的左側列是相同的，因為它是一個對映的符號表，並索引到二進位制資料（例如網格、會話或路線檔案）。只有使用名稱，即兩個元素的右側或資料元素才是本地化的，並由執行時本地化軟體替換。如果需要，可以手動編輯這些名稱以獲得更友好的名稱，即使是在英語字串表中也是如此。索引或左側引用列語法不得以任何方式更改，因此在資料列中更改名稱時，請注意全域性 SAR 規範。
資產中可能存在多個字串表-XX標籤，每個支援的語言一個。每個都應包含一個字串列表，該列表與字串表列表中的鍵相同，但值不同。如果不存在相應的“字串表-XX”標籤來表示給定終端使用者系統上的此資產，或者該列表中缺少相應的字串，則改為引用英語字串表容器。
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 插槽，這將建立一個需要自身舊版本的迴圈定義！）
- 同樣，資產不能列為其自身的依賴項。[另一方面，這已經發生過（即在 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配對。一輛貨車可能包含各種各樣的產品……獲得許可權將你的作者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中的過濾器（搜尋條件）
- 型別：列舉字串或字串陣列。
- 欄位定義：以分號（';'）分隔的兩個字元category-region 標籤程式碼列表。字串中不應存在其他字元（包括空格等）。此資產被認為與每個指定的區域相關——這對於kind 火車和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中的過濾器（搜尋條件）；確定CM軟體如何根據KIND宣告處理資產，以及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]
- 此資產的唯一含義是針對其他人，即此資產被認為在指定的時代範圍內有效且相關，並且內容管理器將接受指定適用年份的搜尋過濾器。
- 示例
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真彩色）（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的一個修復程式中被取消，原因是在使用者社群中收到了許多投訴。
• 如果缺少縮圖容器的資產（即使使用過時的thumb標籤）後來在新的內建路線或會話中被選中，該資產通常將作為沒有影像的專案分發——如果texture.txt或config.txt縮圖容器沒有正確引用，它們將被剝離[註釋 11]。
- 型別：URL 字串。
- 欄位定義：指向資產線上描述、資產說明（幫助）或TrainzOnline wiki上的其他幫助頁面的連結，旨在從嵌入式特殊用途N3V瀏覽器中使用。URL必須解析到Trainz 線上安全區域內的站點。目前，嵌入式瀏覽器可接受三個域名
auran.com
ts2009.com
ts2010.com
此外，建議使用自定義的Trainz短網址格式，而不是直接連結到這些域名，以使URL免受未來網站佈局可能發生的變化的影響。“短網址”是Trainz專用的URL，透過允許內容建立者引用N3V網站上的特定頁面，而無需依賴特定的網頁佈局，從而幫助保護內容免受未來變化的影響。短網址旨在用於遊戲內，例如資訊URL連結，並且僅在嵌入式網頁瀏覽器中有效，在任何外部網頁瀏覽器中均無效。在出現此標籤的地方，遊戲內會提供按鈕，允許使用者在不離開遊戲環境的情況下檢視資源描述或幫助。
這對於在Driver中訪問路線地圖、指南或關卡說明或澄清可能非常有價值。
建議在任何情況下，如果資源提供類似的功能但外觀略有不同，都使用通用組頁面來表示整類資源。這減少了建立、維護和本地化此類文件的時間成本。
- 型別：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直接包含另一個資源的指令碼，這些指令碼來自父資源的指令碼檔案。
- 相關
擴充套件容器是具有特定命名約定的自定義標籤或子容器列表。
此容器是指令碼資源名稱及其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、聖達菲和AT&SF、B&O、切西、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個字元。除非存在只能透過custom-category-list方法滿足的特定指令碼需求，否則應將此標籤留空。
- 最低版本：V3.5及以上
- 型別：Member-of-groups容器配對的佔位符引數和資產組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上的大多數資產都是對所謂的知識共享署名-相同方式共享3.0未移植許可證（CC-BY-SA）的措辭不佳的版本，例如此版本和其他維基百科維基專案。
- license標籤的含義模稜兩可，N3V不建議使用它，但它的出現早於N3V的管理6-7年。
- 上傳到下載站或提供用於包含到遊戲中的內容可能受特定再分發合同或許可協議的約束，該協議優先於此欄位中的任何文字。license欄位不提供本地化支援。Auran或N3V不會驗證或執行license欄位的文字，並且可能對終端使用者具有或不具有法律約束力。
- 另一方面，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變體。
在Trainz 1.x--TRS2004 Trainz時代，Asset-name是資源的主要資料夾名稱，並且通常是CM開啟檔案進行編輯時開啟的資料夾的名稱；在當今此類早期資料模型資源中，通常會發現asset-name也用於早期Trainz時代的資料子資料夾系統，從而為子資料夾命名為'asset-name_art'、'asset-name_body'、'asset-name_shadow'（在火車車廂資源中）。在修復此類資源時，大多數情況下，該值可以用SAR替換，該SAR是從資原始檔複製並貼上下來的樣板程式碼。此替換通常會正確定義和連結資源的子資料夾（用於主體、陰影和圖稿），因為早期方案中的檔名基於asset-name標籤。
- 範圍：在v2.9標準之前的軌道或橋樑資源中發現，當時樣條線物件經歷了很大的變化，轉向統一的資料模型定義，放棄了混合中的一些以前的KIND，有利於所有樣條線物件在kind track下統一。
- 見上文bendy，已棄用/過時的TS2009之前的舊版kind track標籤。
- '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，則會顯示TrainzBaseSpec。
|
|
- 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 — V1.3–v2.8 —在幾乎所有值得註明位置的資源的歷史記錄中發現。這些已被category-region標籤中的“兩個字母列舉的ISO國家程式碼的字串陣列”取代。
- 將字串陣列型別的 category-region 替換為不包含空格和分號的兩個字元國家程式碼列舉，這些程式碼在引用的標籤部分中列出；這些程式碼以兩個大寫字母的形式給出，構成 列舉 程式碼，程式碼之間用分號“;”分隔，但最後一個程式碼前不使用分號，直到末尾的結束引號。
- 字串陣列中的任何 空格 都會導致讀取錯誤和故障訊息，包括末尾引號前的空格。
- region —TBS V1.3–v2.8 版本中有效的部分，用作內建過濾器和地圖資產自定義本地化識別符號 (kuid)；現在唯一合法的標籤用途是在 kind map（佈局）資產中。
- 作為以前的過濾器修飾符，該標籤在歷史上幾乎所有資產中都存在，但在滾動庫存、風景、樣條線資產、軌道型別（包括隧道和橋樑）以及具有一定程度本地化的軌道旁資產中尤為普遍。
- 地圖資產仍然保留關鍵字 Region，該關鍵字在 Map 配置檔案中定義，用途相反——成為 kind region kuid 引用。因此，Region 在 Maps 中是必需的，並且從 TS2012 開始，與標籤型別一樣，在大量曾經用作 TRS 系列版本 Surveyor 工具視窗的“分組資料” “快速過濾器” 的資產中是非法的。
- TRS2009 之後，任何將 region 標籤應用於文字字串的操作都已過時，因為在程式設計師看來，他們用 Pick List 替換了 Surveyor 工具中“型別和區域”字串值的粗略過濾組選擇器。這兩個標籤都有一些優點和缺點，並且都追溯到 Trainz 0.9 Beta 版本。
- 參見上面的 bendy，已棄用/過時的 TS2009 之前的 kind track 資產模式控制標籤。
thumbnail 標籤是 thumbnails 容器 的早期單檢視實現（上面也簡要介紹過）。Trainz 的早期 N3V 之前的程式設計師版本會在主資產根資料夾或 asset-name_art 或 asset-name_body 資料夾中查詢 .jpg 檔案，最好大小為 240x180 畫素，並將其用於在 CMP 和 DLS 中顯示資產（如果已上傳）。該標籤在 TRS2006 期間被棄用，因為 thumbnails 容器是在 v2.0（TRS2004-SP0）中引入的。在 TBV 保持在 v2.4 以下的舊修復資產中，如果縮圖位於 _art 子資料夾中並且資產名稱與使用者名稱匹配，則縮圖通常仍會在更新的 CM 中工作。
- type — V1.3–v2.8 —以前的過濾器修飾符，歷史上幾乎存在於所有資產中，但在滾動庫存、風景、樣條線、軌道型別（包括隧道和橋樑）以及軌道旁資產中尤為普遍。
- type 標籤與“region 標籤”一樣，在 Trainz 0.9—TC3 版本中用作“Surveyor 中的組過濾器”，它與 region 結合，提供了更小的資產選擇（工具組）。從 TS2009 開始，取消了這些本地可點選過濾器，取而代之的是一個新的、更繁瑣的過濾器。這些使工具選擇變得快速簡單，而不是在工具選項卡之間切換時變得緩慢和暫停——如今的 TANE 之前的版本在工具選項卡之間來回切換時，經常會因重新載入整個選擇列表而不堪重負。
- type 和 region 都預設為“全部”，提供了與 TS09 及其後版本中的工具相同的超大型列表。
- ↑ 資產 提交（TANE 的提交）是將內容整合到資料庫並將其在 DB 索引中交叉引用以便可以在執行時模組中訪問它的過程和步驟。
- ↑ 驗證資產的一種方法是除了這些值之外還可以正常工作，方法是將 TBV 降低到 2.5-3.7 範圍，看看這些訊息是否消失。您可能需要分幾次嘗試降低它，直到足夠低，反之亦然，在較舊的 TBV 中無法識別的較新的關鍵字可能會給出不同的錯誤訊息。但不要害怕嘗試——即使這樣失敗也會產生知識和經驗，而且您不會破壞任何東西！如果是這樣，您可以確信僅僅提供一個值就是問題的解決方案。通常，一些現代需求僅僅需要關鍵字對，因此在標籤後面新增一個空行或在容器後面的標籤後面新增一組空的捲曲括號將滿足需求，而錯誤測試過於嚴格。
- ↑ 注意：此列表在 N3V TrainzOnline Wiki 上進行了“維基化”，這意味著在“KIND”一詞之後首字母已大寫，而 config.txt 檔案中的實際資料標籤名稱為全部小寫文字。該維基還使用雙引號來表示很多術語，這種做法我們將在本文中避免。
- ↑ “kind consist” 並不經常直接看到，它某種程度上只存在於選單和內容管理器列表中。
- ↑ 必須謹慎使用過時表，它最常出現在 Auran 編寫的資產中。該表用更新的 kuid 替換舊的 kuid，大多數內容建立者正確地使用 kuid 的 Kuid2 形式來取代舊版本。相比之下，N3V 過度使用過時表來更新新發布的內建資產，這會導致很多混淆，並且無法獲得預期看到的內容。（例如，許多漂亮的 'Flip-trees' 在 TS10 和 TS12 中被棄用，轉而使用 Speedtrees，這影響了許多建立者不希望也不需要的 Speedtrees 的路線。在安裝過程中，這也會導致依賴項丟失，直到可以找到包含過時表的資產。
• 此外，Assets.tdx 資料庫索引中每個 kuid 只支援一個過時條目，並且用 Kuid2 版本替換 kuid 會導致問題（即您會看到哪個？）。
• 過時表的一個很好的用途是使用特定部件（尤其是轉向架）升級一系列資產。新增要替換為更新的良好轉向架的 kuid 組合可以顯著改善路線或會話的外觀（前提是轉向架（例如）相容且尺寸正確！） - ↑ 最近使用匯入到 TANE 的已棄用資產的經驗表明，至少有五個備用 kuid 使該可憐的 Flip-tree 資產 過時。看來，隨著 speedtrees 引入造成的混淆以及 TANE 及其對最新適當資產的積極追求所帶來的全面改革，現在內容管理器流程中容忍了多個不同 kuid 的資產使同一 kuid 過時。作為一種良好的實踐，僅在絕對必要時才使用過時表……例如，在您要上傳到 DLS 或在網站上自行釋出的依賴資產中取代不需要的付費資產。
- ↑ 關於 category 時代的標籤範圍：安全的操作，已知有效。其他“未來十年”的值應在依賴此類值之前進行測試。
- ↑ 許多容器在列表中使用虛擬/佔位符名稱。這些可以是描述性單詞，只要它們不包含空格字元即可。在短語構造的名稱中使用下劃線或句點可以極大地提高可讀性和清晰度。例如，一輛貨運火車車廂可能承載 45 種合法產品型別。這些將在依賴項容器中列出。使用 Coal、granite、crushed_limestone 等可以更容易地維護和更改表。自 76 年起擔任程式設計師的 Jes Sayin
- ↑ 在第二個 thumbnails 容器示例中，還有一個 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 上傳審查軟體可能已更改為強制執行正確的 thumbnails 容器。
- ↑ 關於 category-era-nn 與 category-era 標籤值： TRS 可以接受這兩種形式的 category-era 資料；但是 TS2009-SP0 及其以上版本會從之前合法的關鍵詞-值對中產生錯誤，並試圖強制內容創作者更改程式設計師故意破壞的所有資源。後來，DLS 上傳軟體強制進行了轉換，但這要更容易接受，因為第一個操作導致許多人花費了大量時間來修復那些不必要的錯誤，這些錯誤應該在軟體預過濾過程中，在審查舊版 Trainz 資源時自動實現。這些操作實際上保證了舊版資源下載會出現錯誤。這是 N3V 程式設計師做過的最愚蠢、最傲慢的事情之一，而 Auran 更經驗豐富的軟體人員絕不會如此輕率地對待社群的時間成本。
- 此頁面主體內容摘自 N3V TrainzOnline Wiki 的 KIND_TrainzBaseSpec。增強資訊由 Yesterdayz-Trainz 使用者組成員新增。
- ↑ 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 程式碼 標準的更新資訊，這些標準隨著軟體功能的新增而發生變化的趨勢。 |