Trainz/refs/TrainzBaseSpec
KIND TrainzBaseSpec 為所有 Trainz 資產型別的所有 config.txt ini 檔案 提供基礎定義。TBS 提供了一些“標準標籤”，這些標籤對所有 Trainz 資產（或者至少，可以在法律上定義）都是通用的[1]。
- 其中一些是強制性的，因為它們決定了對資產的進一步處理以及對 config.txt 檔案和其資料夾中資產資料的解釋。
- 但是，大多數是可選的，大多數子資產中可以省略使用該標籤的定義行。
- 沒有。所有 Trainz 數字模型都需要的有效且大部分都是必要的，實際上是由父容器定義的，即所有 Trainz 數字模型都需要config.txt 檔案。KIND TrainzBaseSpec (TBS) 是一個根類，其他 Trainz 資產類都是從它派生出來的。
- 據說它們是派生的，因為它們繼承了其中列出的引數定義的處理屬性（指令）和值，其中最重要的是 kind 標籤的值。這個列舉詞決定了資產的特定 kind 宣告和要求，這些宣告和要求將被新增到該資產配置檔案中 TBS 的定義中。其他關鍵的 TBS 定義資料也很重要且實用，例如資產的名稱、Kuid 識別符號和版本、Trainz 構建值 (TBV) 以及其他具有廣泛可變定義需求、適用性和範圍的資料，例如 _string-table、obsolete-table、kuid-table_ 和縮圖影像都是偶然的。字串值，即使是資產名稱和描述，在實踐中通常是完全不必要的，也是完全可以省略的。
- 當宣告一個 kind 時，該 kind 成為父類，除了 TBS 中列出的那些之外，還需要和規定必須在類中滿足的必要資料對。
- 在某些情況下，某些引數可能在資產 kind 的情況下保持未定義，特別是針對較舊的歷史 Trainz 構建標籤值的常見做法，對於這些值，Content Manager 或 Content Creator Plus (CCP) 實用程式會分配一個預設值，但在處理它時會列出警告訊息。TrainzOnline wiki 中的許多標籤，這裡，或者較舊的 TC3 時代 Content Creator's Guide (CCG) 會提到一個預設值。
- 從 TRS2006 和 Trainz Classics (TC1&2) 開始，每個版本的 Content Manager 模組都會施加越來越多的預先承諾錯誤測試[note 1]，並且每個版本在警告此類標籤未被定義時變得越來越堅定——它期望存在此類標籤資料對。
在 TANE 後釋出的版本中，許多這些“昨天預設”的定義行今天會更頻繁地生成錯誤，要求明確的值定義，而這些定義在過去的載入中是預設的[note 2]。與過去時代相比，這是一種更可取的煩惱，當時錯誤的資產定義有時會導致臭名昭著的“**藍色畫面宕機**”或更常見的情況是，將執行時軟體崩潰回桌面，導致編輯丟失，並且可能需要重建資料庫。
子類
[edit | edit source]
所有 Trainz 定義的資料（內容）都有三個必需的元素：一個 config.txt 檔案 來組織資料，一個標識，這意味著一個 kuid（單獨的使用者名稱對你毫無用處，然而，即使沒有名稱，也可以建立合法的資產！）最後，一個合法的定義的 kind 標籤。kind 是負責人，是管絃樂隊的指揮，是排長或 CEO 發出指示——為所有在之後處理的內容設定要求。簡而言之，kinds 的值，一個精心定義的成員專用的小型選擇組——告訴 Trainz 軟體在建立的虛擬世界中渲染和顯示什麼，以及如何在該 config.txt 檔案中找到連線這些資產部分所需的其餘部分。
下面的每個子類都被認為具有 TrainzBaseSpec 作為其資料的“父類”[note 3]。下面列出的一些 kind，那些帶下劃線的 kind，是早於 Trainz 資料模型 在 TS2009 版本釋出（即自 2008 年末以來）更改的遺留 kind，N3V 程式設計師只對其進行了逐漸（增量）的更改。
目前可以在 N3V Trainz Wiki TrainzOnline 網站這裡 的 Content Creator's Guide 部分中找到有關基於這些遺留 kind 修復資產的詳細資訊，其中包含 遺留 Kind 的示例。強烈建議所有使用 Trainz Download Station 或考慮建立內容的使用者閱讀 CCG。從瞭解舊內容定義方式的背景歷史中獲得的見解，然後可以與 TrainzOnline 對相同資料型別的當前覆蓋範圍進行對比和比較，因為這種當時與現在的對比通常會提供寶貴的見解，以修復、更改和定製資產。更重要的是，CCG 中的寫作是由專業人員製作的，並且更加贅述——它經常會讓你瞭解如果改變這一點或那一點的擴充套件效果，而 Trainz Wiki 卻沒有提供。放在 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 (容器[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 | "作者/組的網頁 URL '字串值'" |
| 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 標籤
[edit | edit source]- 主要涵蓋：trainz-build 標籤，縮寫：TB & TBV (TB-value)∅
- 型別： 一個小數點浮點數，由 N3V[2]列舉，用於跟蹤和識別與演化軟體的技術水平相對應的各種資料型別。
- 範圍： 1.0–4.3，直接對應（'對映onto3rd' Trainz 1.0—TANE-SP1+hf2；預計此值將隨著每次重大軟體升級而向上增長 0.1。
每個合法值必須與釋出的 Trainz 版本號 完全匹配，但以下情況除外
- 分配給 V1.4 的TBV 或版本值是 Auran 的Paintshed 釋出版本，它是一個適用於Microsoft Trainz Simulator (MSTS) 的重新繪製工具，並且也作為 TRS2004 輔助軟體模組的構建值出現；具體來說，它是 ContentManager.exe 實用程式。
- 1.7 和 2.0 之間的差距要麼是外語版本，要麼更可能的是，正如經過幾個小時的挖掘和研究後所顯示的那樣，Auran 沒有使用它，因為在構建最初 Trainz 的程式設計師團隊看來，TRS2004 版本是第二個 Trainz 產品，無論前臺如何宣傳營銷名稱（例如 Trainz UTC，是終極的任何東西……真的嗎？拜託！真的嗎！？）。
- 從 v2.0 (TRS2004) 開始，Trainz-build 標籤數值已經透過 23 個步驟遞增，這些步驟是連續但非單調的，因為 Trainz TS09-sp3—TS09-sp4 共享一些Trainz-build[2] 值；也就是說，在 TS2009 和 TS2010 的聯合開發時代和版本中，有一些 TBV 是重疊的。
- 此外，N3V 進軍 Mac 電腦領域，打斷了基於 Windows 的 Trainz 版本的 TBV 3.4、3.5、3.6、3.7 和 3.8 的平穩遞增，這些 TBV 在基於 Windows 和 Mac 的作業系統之間交織在一起。
注意：熱修復 不會更改版本號。
- 欄位定義： 此資產構建（並存檔）的的檔案格式版本，不一定與資產使用的技術水平相關，而是與在Content Creator Plus 中建立資產時分配的資產級別相對應，與在 CM 的標題欄中找到的值相同。
- 程式設計師建議此數字通常應該設定為建立和測試資產的 Trainz 安裝版本的 Trainz 版本號。相反，Content Creator 社群試圖將此數字設定得儘可能低，以便新資產在下載時擁有儘可能廣泛的受眾/使用者範圍。更好的內容創作者將在裸機安裝（沒有新增任何內容）的對應版本上進行測試，並驗證生成的 cdp 是否包含所有相關材料。
- 某些資產型別根據其trainz-build 版本標籤進行的解析方式存在顯著差異。注意：trainz-build 標籤 是強制性的。如果未指定，Trainz 將根據config.txt_file 的內容，嘗試以原始方式猜測 Trainz 版本，通常會解析為 TBV 的 1.3 值。
使用者名稱標籤
[edit | edit source]- 型別： UTF-8 字串，資產的使用者名稱，必須指定。
- 欄位定義： 此資產的英文人機可讀名稱。
在 TC1&2（v2.7）之後的 trainz-builds 中，使用者名稱在編輯資產時也成為作業系統資料夾名稱，並且會忽略資產檔名，而在 v2-6 配置檔案中，它優先於資產檔名。根據 N3V games 的 TBS 標準，此欄位絕不應包含非英文文字，除非資產名稱是專有名詞（例如，地名），並且沒有英文字地化變體。此值是每個人通常搜尋和記住的，因此建議使用清晰的名稱。
 |
|
username-XX 標籤
[edit | edit source]- 型別： UTF-8 字串，使用者名稱標籤 的替代語言版本。
- 欄位定義： （其中XX 被替換為相應的本地化程式碼，用於表示該語言。）此資產的本地化人機可讀名稱。此欄位與使用者名稱欄位類似，只是表示非英文區域設定。一個資產中可能存在多個username-XX 標籤，每個支援的區域設定一個。如果在給定終端使用者系統上沒有相應的“username-XX”標籤來表示此資產，則使用英文使用者名稱標籤。
描述標籤
[edit | edit source]- 型別： UTF-8 多行字串，提供對資產的清晰語言描述。
- 欄位定義： 此資產的英文人機可讀描述性摘要。
描述在內容管理器“資產詳細資訊”窗格中可見，用於澄清資產名稱，提供規格，通常還包括一些歷史資訊。
N3V 的 Chris Bergmann 表示，此欄位應保留為簡短的（1-2 段）描述資產的簡簡訊息，並透過info-url 頁面提供擴充套件的詳細資訊，但可以容忍相當長的文字塊。有些人使用塊的底部作為版本變更記錄。
此欄位必須由英文描述性文字組成，儘管文字可能引用非英文專有名詞，如其他地方所述。其他語言翻譯或源文字應放置在許多可能的替代語言本地化標籤中的一個（參見description-xx 標籤）。
description-XX 標籤
[edit | edit source]- 型別： UTF-8 多行字串，描述標籤.
- 欄位定義： （其中XX 被替換為相應的本地化程式碼，用於表示該語言。）此資產的本地化人機可讀描述性摘要。此欄位與描述欄位類似，只是表示非英文區域設定。一個資產中可能存在多個description-XX 標籤，每個支援的區域設定一個。如果在給定終端使用者系統上沒有相應的“description-XX”標籤來表示此資產，則使用英文描述標籤。
字串表容器
[edit | edit source]- 型別： UTF-8 字串列表容器，字串表容器.
- 欄位定義：一個鍵值對列表，包含**英文**字串。每個鍵都是一個有意義的指令碼識別符號，對映到二進位制資料並被其引用。每個值都是一個**英文**字串。英文字串可以包含或引用一個非英語專有名詞作為識別符號。由非英語母語人士創作的資源，如果需要，仍然必須建立沒有後綴的字串表容器。軟體只連結到字串表容器中的名稱和值並引用它們，而不新增字尾，這對於西班牙語、法語、德語、捷克語、荷蘭語……日語作者來說將是無盡的煩惱。換句話說，帶字尾的字串表僅僅用於翻譯目的，當地圖用非英語編寫時就會出現問題——沒有字串表-en 來提供反向翻譯的表格。同樣，使用者名稱-en 和描述-en 也是如此。這三者都缺乏表現出過時的傲慢和對世界動態的漠不關心。
其他語言由類似的字串表（例如字串表-XX）支援，這些字串錶帶有與描述和使用者名稱關鍵字/標籤的國際化字尾相匹配的本地化程式碼字尾 (XX)，但這些語言鍵入的字串表容器始終在左側條目中具有相同的鍵值。
- 這些左側鍵或標籤同時充當“本地索引關鍵字”和“語言之間的等效表”。
- 左側列始終包含內容建立者賦予“特殊”名稱的物件，例如訊號、軌跡標記和行業、連線點等名稱，這些名稱可能被引用，並且會出現在 Driver 和 Surveyor 模組的“查詢工具” (CTRL+F ) 功能小程式中。
- 相反，索引側也不會列出預設的名稱，例如眾多連線點的名稱，在構建路線圖時會透過隨機數自動索引（即無意義的混亂。如果重要，路線構建 CC 會命名它！），但會自動包含潛在的臨時資源，例如火車車的預設名稱。如果重新命名，這些名稱將取代其相應的預設名稱。
- 它的主要用途是用於那些設計用於與指令碼引用互動並具有可變屬性的物件，例如火車站或行業所需的或準備運送到行業的商品數量，或由互動式火車車（滾動行業到指令碼）和其他可配置資源（如通用的廣告牌式標誌）所攜帶，透過一些高度調整和角度扭轉，可以放置在庫存建築物或行業的正面，以在建築物上放置不同的企業名稱。換句話說，一些可配置的場景。
- 總體上，在路線圖或佈局中，這些左側名稱對應於地圖資源上的命名物件，這也是大多數字符串表出現的地方（從字面上看，它們被大型路線kind 地圖中的數千個條目填充）。
- 在某些資源中，該預設名稱被連線到軟體指令碼，因此字串表變得特別重要，而不是平淡無奇。（見下文）
- 在每種型別的資源中使用字串表型別都是合法的，就像描述標籤、trainz-build 和 kind 標籤一樣。與它們不同的是，它不必存在或定義，並且不是強制性的。除非程式碼期望它們的結合，否則封裝在字串表容器中的值沒有任何功能或效果。
- 在其他資源中，以那個假設的可程式設計商業標誌為例，如果字串表要與軟體互動，就必須給它一個預設名稱。所有地圖可放置資源都可以命名或重新命名，但“特殊名稱”必須與指令碼和字串表索引值匹配。大多數可配置資源定義了一個介面變數，該變數用於替換預設名稱作為指令碼引用的索引或查詢表，以及資源的二進位制資料。其他變數也可能在可程式設計資源中定義。這些變數都可以被指令碼引用，但正是索引值將其傳遞到地圖或會話字串表中，使得當需要 Driver 或會話建立者的可變性時，所有內容都能協同工作。
- 相反，如果系統軟體不知道索引中命名專案的地址，該物件的指令碼可能不會有任何觸發、條件檢查或更新能力。這是 2000 年代Trainz 1.0中物件的特徵，而不是 2003 年釋出的TRS2004以來的現代 Trainz 鐵路模擬器。（我們已經走了很長一段路了！）
- 有些資源只能作為一個組一起工作。在這種情況下，在 map 或會話層中命名每個資源可以使它們協同工作。例如，考慮一個有五個軌道的公路平交道，其中兩個軌道與連線點分離，形成所謂的 '菱形交叉口'，與直線軌道相連。如何設定訊號，以便任何鐵路交通都關閉公路道閘，或者如何使用菱形交叉口來禁止其他列車穿過正在穿越交叉口的列車？道路和鐵路訊號、道岔和道閘都需要協同工作。某些“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-table。大多數具有子元件的資源只有幾個。
- 其次，存在一個從內部關鍵字有時會被“自動定義”這一事實中產生的約定——僅僅被列為一個沒有名稱的數字，作為佔位符引數，偽關鍵字，可以是任何唯一值（通常是零索引的順序整數。[notes 1]）可以賦予它們名稱，也可以不賦予名稱，這取決於使用者或作者的偏好。
- 此表中的條目有兩個用途
首先：確保遊戲系統知道依賴關係，以便安裝和載入此資源將成功安裝和載入所有依賴關係，以及
其次：允許指令碼定位相關的子資源。 - 只有第一級依賴項要包含在 kuid-table 中——具有自身依賴項的子資源或部件資源將在該子資源的驗證和資料庫提交過程中處理。
- 迴圈依賴關係是非法的。
- 如果資源也被標記為此資源的過時版本，則該資源不能列為依賴項。（Trainz 資源索引（歷史上是 assets.tdx 檔案）中只有一個替換 kuid 槽位，這將建立一個需要自身舊版本的迴圈定義！）
- 同樣，資源不能列為它自己的依賴項。[另一方面，這在 TSxx CMs 中被體驗過（即被證明是成功提交的無錯誤資源），將地圖和會話移植到 GSARS 之間的安裝中，以更改 kuid，以便重疊不會覆蓋已在目標安裝中使用相同 kuid 的資源，而不會看到錯誤訊息。] 至於它是否起作用，這需要比我更勇敢或更愚蠢的人！--Fabartus，編輯。
- 格式 (所有值都是 <kuid:aaaaa.bbbbb> 格式)
kuid-table {
0 Kuid-1
1 Kuid-2
3 Kuid-3
... kuid-ii
N-1 Kuid-N
}
|
|
- 這些是虛擬引數，一個非常有用的利用方法是將複雜機車車輛資產中產品的 kuid 配對。一輛貨車可能包含各種產品……獲得授權將你的作者 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。
- 目的：在 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 個字元的 類別 - 類 程式碼。類別 - 類標籤用於提供超出資產種類隱含的人工子分類。每個 Trainz 資產的類別 - 類標籤有助於描述資產在遊戲中的“意圖”，而不是資產的內部結構。
|
|
注意，許多類別 - 類程式碼只與特定的資產種類相關——類別 - 類程式碼不得應用於不適當種類的資產。
- 示例
| 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 中過濾（搜尋條件）
- 型別：縮圖容器.
- 欄位定義：在整個遊戲環境（包括遊戲內、在 內容管理器 和 下載站 中）用於在二維預覽框、列表和圖示形式中表示此資產的縮圖（多個）。每個資料集都包含在一個子容器中（通常）使用 佔位符引數 作為鍵名或標籤。 [註釋 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"
}
}
另一個常見的尺寸是 128x64 的“圖示”，用於 Railyard 和測量師資產選擇 API，它應該有一個 Alphamask 或一個非常淺的背景。許多舊的沒有使用 jpg 檔案，而是將 .tga 檔案 (Targa True Color) 列在一個“_art”子資料夾中 (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 格式來實現 URL 的未來可擴充套件性，而不是直接連結到這些域。'短 URL' 是 Trainz 特定的 URL，它透過允許內容建立者引用 N3V 網站上的特定頁面而不依賴於特定的 Web 佈局來幫助實現未來可擴充套件性。短 URL 旨在用於遊戲內使用，例如 info-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。
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>
}
- 型別：Extensions 容器。
- 欄位定義： 一組擴充套件屬性，為指令碼提供超出此資產型別定義的Config.txt 檔案規範的附加資訊。建立新擴充套件時，應注意遵守擴充套件命名準則，並提供現有擴充套件的 資料時，應遵守擴充套件建立者的準則。Auran 保留根據擴充套件建立者的準則在稍後日期對擴充套件容器中特定條目的新增驗證的權利。
以下關鍵詞是比較新的發展，在較舊的資產中不會有類似物或存在。
- 型別： 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 容器
- 型別： 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 上的大多數資產都是使用類似於此和其他維基百科維基專案，被稱為知識共享署名-相同方式共享（CC-BY-SA）的糟糕版本。
- license 標籤的含義不明確，N3V 不建議使用它，但它的出現早於 N3V 的管理 6-7 年。
- 上傳到下載站 或提供用於包含在遊戲中的內容可能受特定再分發合同或許可協議的約束，該協議取代此欄位中的任何文字。license 欄位不提供本地化支援。license 欄位的文字未經 Auran 或 N3V 驗證或執行，可能具有法律約束力，也可能不具有法律約束力。
- 另一方面，Planet Auran 的歷史表明，有人透過將他人的內容當作自己的內容來侵犯版權，可能會導致迅速被禁止訪問 Auran 網站，並永久遮蔽下載站許可權等。此外，社群會嚴厲打擊其他使用者侵犯他人的版權行為，並回避違規者，並忽略任何允許留在 DLS 上的資產。
- 總之，實驗和更改資產對於試圖攀登陡峭的內容創作學習曲線的 Trainzer 來說是一種公認的，甚至是被認可的方式（每個人都希望有更多內容建立者！），但如果資產有依賴部分，尤其是網格、指令碼、紋理，這些都是智慧財產權——在上傳你的作品之前，請獲得使用屬於他人的這些部分的許可。
|
|
- 型別： UTF-8 字串。（已棄用，轉而使用可更新的Planet Auran 資料庫。）
- 欄位定義： 作者姓名或標記。不建議使用此欄位，因為可以透過程式設計方式確定署名。
- 注意英國拼寫，“organisation”，北美拼寫“organization”也可以！
- 型別： UTF-8 字串。（已棄用，建議使用可更新的 星球 Auran 資料庫。）
- 欄位定義： 負責建立此資產的組織的名稱或標識。不建議使用此欄位，因為歸屬權可以透過程式確定。
- 型別： 字串，電子郵件地址。（已棄用，建議使用可更新的 星球 Auran 資料庫。）
- 欄位定義： 此資產建立者的聯絡電子郵件地址。不建議使用此欄位，因為歸屬權可以透過程式確定，並且可以針對建立者的 Auran 帳戶星球 Auran 帳戶 註冊聯絡資訊，並在需要時進行限制或更新。
- 型別： URL 字串。（已棄用，建議使用可更新的 星球 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 是 Trainz 1.x--TRS2004 時代資產的主要資料夾名稱，並且在大多數情況下，也是 CM 開啟檔案以進行編輯時開啟的資料夾的名稱；在當今此類早期資料模型資產中，通常會發現 asset-name 也用於早期 Trainz 時代的資料子資料夾系統，在火車車廂資產中提供子資料夾名稱“asset-name_art”、“asset-name_body”、“asset-name_shadow”。在修復此類資產時，通常可以使用從資原始檔複製並貼上下來的 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) 資產中，將 name 和 name-XX 替換為 username 和 username-XX，或者如果存在 username，則直接刪除。
- 如果資產的 trainz-build 版本為 v2.7 或更高，則 name-XX 會導致錯誤。有趣的是，即使在 TS12 這樣晚的版本中，name-XX 標籤也會在 Surveyor 工具的搜尋列表中顯示為資產名稱，如果不存在，則顯示 TrainzBaseSpec。
|
|
- 由 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 標記 取代
- 型別 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 工具中 '型別和區域' 字串值的粗略過濾分組選擇器。這兩個標記都具有一些優點和缺點，並且都可以追溯到 Trainz 0.9 Beta 版本。
- 請參閱上面的 bendy，在 TS2009 之前的過時/已棄用的傳統 kind track 資產模式控制標記。
thumbnail 標記是 thumbnails 容器 的早期單檢視實現（上面也有簡要記錄）。Trainz 的早期 N3V 之前版本的程式設計師會找到一個 .jpg 檔案，最好大小為 240x180 畫素，該檔案位於主資產根資料夾、asset-name_art 資料夾或 asset-name_body 資料夾中，並將其用於在 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 都預設為 'All'，這與 TS09 及其後的版本中的工具所提供的一樣大的列表。
- ↑ 資產 提交（TANE 的提交）是將內容整合到資料庫並將其交叉引用到資料庫索引中的過程和步驟，以便可以在執行時模組中訪問它。
- ↑ 驗證資產的一種方法是，除了這些值之外，其他一切正常，方法是將 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 並非建立者想要或希望的。在所有安裝中，這還會導致依賴項丟失，直到找到包含過時表的資產。
• 此外，資產 .tdx 資料庫索引中只支援每個 kuid 一個過時條目，用 Kuid2 版本過時一個 kuid 會導致問題（即你會看到哪個？）
• 過時表的一個很好的用途是升級使用特定部件的系列資產，尤其是轉向架。新增一系列 kuid，以新的好轉向架替換它們，可以極大地改善路線或會話的外觀，只需進行一次編輯即可（前提是轉向架，例如，與之相容且尺寸正確！） - ↑ 最近將一個過時的資產引入 TANE 的經驗表明，至少有五個替代的 kuid 過時了那個糟糕的 Flip-tree 資產。看來，隨著 Speedtrees 引入造成的混亂以及 TANE 對最新合適資產的積極追求，內容管理器程序現在容忍多個不同 kuid 的資產過時同一個 kuid。作為一種良好的做法，僅在絕對必要時才使用過時表... 例如，在您想要上傳到 DLS 或在網站上自行釋出的依賴資產中，過時一個不想要的付費資產。
- ↑ 關於 category-era 標記範圍：安全有效的玩法。其他 '未來十年' 值應在依賴於這些值之前進行測試。
- ↑ 許多容器在列表中使用虛擬/佔位符名稱。這些可以是描述性詞語，只要它們不包含空格字元即可。在短語構建的名稱中使用下劃線或句點可以保持可讀性並顯著提高畫質晰度。例如，一輛貨運列車車廂可能裝載 45 種合法產品型別。這些將在依賴項容器中列出。使用 Coal、granite、crushed_limestone 等使表格的維護和更改更容易。Jes Sayin' 作為一名程式設計師自 1976 年起
- ↑ 在第二個縮圖容器示例中，還有一個第二個 512x512 大小的影像，額外的。DLS 將使用哪個尚不清楚。也可以包含更大的影像尺寸，並且透過電子郵件聊天，T:ANE 可能支援一個大的影像尺寸，該尺寸將在預覽操作或 DLS 列表中找到用途。N3V Games 通常不會傳送此類資訊。
- ↑ 早期的做法可以追溯到 Trainz 1.x，當時使用關鍵字/標籤“thumb”和引號中的路徑規範引用來引用執行時選單的 240x180 縮圖影像。art 資料夾包含一個 512x512 的 tga 檔案，其中包含一個 alpha 遮罩（通常是 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，作為未增強的源頁面，缺少此處找到的歷史資訊（標籤）；訪問日期 = 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 程式碼 標準的更新資訊，這些標準隨著軟體功能的新增而發生變化。 |