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 wiki、此處或較舊的 TC3 時代 Content Creator's Guide (CCG 將會提及一個預設值。
- 從 TRS2006 和 Trainz Classics (TC1&2) 開始，每個版本的 Content Manager 模組都會施加越來越多的預先承諾錯誤測試[note 1]，並且每個模組都越來越堅定地警告這樣的標籤在它期望這樣的標籤資料對時沒有被定義。
在 TANE 之後的版本中，許多在昨天“預設”的定義行，今天更常會生成錯誤，要求明確的值定義，而這些值在過去的載入中是預設的[note 2]。與過去那種錯誤的資產定義有時會引起臭名昭著的“藍色畫面宕機”或更常見的是將執行時軟體崩潰回桌面，導致編輯丟失，甚至可能需要重建資料庫相比，這是一個更令人愉快的煩惱。
所有 Trainz 定義的資料（內容）都包含三個必需的元素：一個config.txt 檔案 用於組織資料，一個身份，也就是一個kuid（僅使用者名稱不起作用，但是，即使沒有名稱，也可以建立合法的資產！）最後，一個合法定義的型別標籤。型別是負責人，指揮家，排長或 CEO，給出指示——為在處理之後發生的所有事情設定要求。簡而言之，型別的價值，一個緊密定義的成員專用小組，告訴 Trainz 軟體在虛擬世界中要渲染和顯示什麼，以及如何（或在何處）查詢將這些資產部分連結在一起的 config.txt 檔案中所需的其餘部分。
下面的每個子類都被認為具有TrainzBaseSpec 作為其資料“父類”。[note 3] 下面列出的幾種型別，那些帶有下劃線的型別，是過時的型別，早於 TS2009 版本（即 2008 年後期）中對 Trainz 資料模型 的更改，N3V 程式設計師只施加了漸進的（增量的）更改。
目前可以在 N3V Trainz Wiki 的 Content Creator's Guide 部分找到基於這些過時型別的資產修復的詳細資訊，並提供具有啟發性的 TrainzOnline 網站上的內容 過時型別的示例。建議 Trainz 下載站 的任何使用者或任何考慮建立內容的人仔細閱讀 CCG。從瞭解舊內容如何定義的背景歷史中獲得的見解，可以與 TrainzOnline 對相同資料型別的當前覆蓋範圍進行對比和比較，因為通常這種過去與現在的對比提供了修復、修改和自定義資產的寶貴見解。更重要的是，CCG 在 TrainzOnline 上釋出的內容是 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 表 (容器) { 依賴項列表 |
一個鍵值表，列出此資產所依賴的所有資產。 |
| 已廢棄表 (容器) { } |
kuids 列出此資產替換的（已廢棄的）資產 通常為空（空）[注 5] |
| 字串表 (容器) { } |
資產中使用的字串和訊息的鍵值列表 通常為空，僅在路線和會話中較大。 |
| 字串表 (容器) { 非英語 語言文字 } |
翻譯後的字串列表，與強制性的英文 字串表 匹配 |
| 類別-區域標籤 列舉 程式碼 | 類別-區域 "_'字串陣列'_" |
| 類別-類別標籤 | 類別-類別 "_'列舉 字串值'_" |
| 類別-年代標籤 | 類別-年代 "_'約束字串陣列'_" 年代 |
| 類別-關鍵字 "_'字串陣列'_" 最大長度為 64 位元組 | 類別-關鍵字標籤 自然語言搜尋關鍵字 (替換型別、區域) |
| 自定義類別列表 "_'字串陣列'_" |
指令碼介面功能 |
| 必須擁有的產品權利 "_'字串值'_" |
DRM 字串陣列 |
| 不得擁有的產品權利 "_'字串值'_" |
DRM 字串陣列 |
| 許可權 (容器) { } |
更多 DRM |
| 縮圖 (容器) { } |
縮圖容器 |
| 指令碼 (檔名) | "_'字串值'_" |
| 類 (指令碼資產類) | "_'字串值'_"，必須與 指令碼 規範類同步。 |
| 指令碼包含表 { } |
(列出庫指令碼的容器) |
| 擴充套件 (容器) { } |
資產也使用的正式指令碼擴充套件 |
| 許可證 "_'字串值'_" | 資產建立者的版權宣告 |
| 作者 | "身份 _'字串值'_" |
| 組織 | "第三方組身份 _'字串值'_" |
| 聯絡電子郵件 | "電子郵件地址 _'字串值'_" |
| 聯絡網站 | "作者/組的網站 URL _'字串值'_" |
| 成員組 (容器) { } |
此資產所屬的 KIND 資產組 資產列表。 |
TrainzBaseSpec 在 config.txt 檔案 中支援以下標籤。 ∅:
- _型別:_ 字串。
- _欄位定義:_ 此 config.txt 檔案 所代表的資產型別。 請參閱索引 型別 和列表：這裡（上面）
- 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 構建程式碼匹配，但會指示先前版本的歷史記錄。
- 在資料庫中同時存在這兩個資源的情況下，在 KUID2 中具有更高字尾程式碼的資源會覆蓋或替換舊的資源。擁有早期版本不是必需的，但CM 會將缺失的修訂鏈列為缺失的依賴項，對於那些反感 CM 中該功能被汙染或被程式設計師保留為“功能”的人來說，這是一個軟體錯誤，無論如何都降低了使用 CM 識別使用者缺少什麼內容的實用性，並導致使用者花費時間手動找出什麼是真正的什麼。
trainz-build 標籤
[edit | edit source]- 主要內容：trainz-build 標籤，縮寫：TB & TBV (TB 值)∅
- 型別： 由 N3V [2] 列舉的一個小數點浮點數，用於跟蹤和識別與演化軟體的技術水平相對應的資料型別。
- 範圍： 1.0–4.3 直接對應（對映onto3rd' Trainz 1.0—TANE-SP1+hf2；預計該值將隨著每次新的主要軟體升級而逐漸增加，每次增加 0.1。）
每個合法值必須與已釋出的 Trainz 版本號 完全匹配，但以下情況除外
- 分配給 V1.4 的TBV 或版本值為 Auran 的Paintshed 版本，這是一個也適用於Microsoft Trainz Simulator (MSTS) 的重新制作工具，並且也作為 TRS2004 的輔助軟體模組的構建值出現；具體來說，是 ContentManager.exe 實用程式。
- 1.7 和 2.0 之間的差距要麼是外語版本，要麼是 Auran 經過幾個小時的挖掘和研究後似乎更不可能，因為在構建最初 Trainz 的程式設計師團隊的腦海中，TRS2004 版本是第二個 Trainz 產品，無論前臺如何宣傳營銷名稱（比如 Trainz UTC，是最終的任何東西...... 真的嗎？。來吧，夥計！真的嗎！？）
- 從 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 版本號。相反，內容建立者社群試圖將此編號設定為儘可能低，以便在下載時為新資源提供儘可能廣泛的受眾/使用者範圍。更好的內容建立者會在裸機安裝（沒有新增內容）的相應版本上進行測試，並驗證生成的 cdp 包含所有相關材料。
- 某些資源型別會根據其trainz-build 版本標籤以顯著不同的方式進行解析。注意：trainz-build 標籤 是強制性的。如果沒有指定，Trainz 將嘗試根據config.txt 檔案 的內容猜測舊版 Trainz 版本，這通常會解析為 1.3 的 TBV 值。
使用者名稱標籤
[edit | edit source]- 型別： UTF-8 字串，資源的使用者名稱，必需的規範。
- 欄位定義： 此資源的英文人可見名稱。
在 TC1&2 之後的 trainz-build 版本（v2.7）中，使用者名稱在編輯資源時也成為作業系統資料夾名稱，而資原始檔名被忽略，而它在 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 標籤）。
- 型別：UTF-8 多行字串，描述標籤。
- 欄位定義：（其中XX 被替換為表示所代表語言的適當 本地化程式碼。）此資產的本地化人類可見的描述性摘要。此欄位類似於description 欄位，只是表示非英語區域設定。資產中可能存在多個description-XX 標籤，每個支援的區域設定一個。如果不存在適當的 'description-XX' 標籤來在給定的終端使用者系統上表示此資產，則使用英文description 標籤。
- 型別：UTF-8 字串列表容器，String-table 容器。
- 欄位定義：英文字串的鍵值列表。每個鍵都是一個有意義的指令碼識別符號，對映到二進位制資料並被二進位制資料引用。每個值都是一個英文字串。英文字串可能包含或引用非英語專有名詞作為識別符號。非英語母語作者編寫的資產仍然需要建立一個沒有後綴的 string-table 容器（如果有需要）。軟體只連結到並引用 string-table 容器中沒有後綴的名稱和值，這肯定會讓西班牙語、法語、德語、捷克語、荷蘭語... 日本語作者非常不爽。換句話說，帶字尾的 string-table 僅僅是為了翻譯目的，當地圖是用非英語語言編寫時，就會產生問題——沒有 string-table-en 來提供反向翻譯的表格。同樣，username-en 和 description-en 也是如此。這三者的缺失都體現了一種過時的、傲慢無禮的，對世界動態的不敏感。
其他語言透過類似的 string-table（例如 string-table-XX）支援，帶有與 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，使所有內容在需要驅動程式或會話建立者可變性時協同工作。
- 相反，如果沒有系統軟體知道索引中命名專案的地址，那麼該物件的指令碼可能沒有任何觸發、條件檢查或更新能力。這是 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 表中包含一級依賴項 - 具有自身依賴關係的子資源或部件資源將在該子資源的驗證和資料庫提交中處理。
- 迴圈依賴是非法的。
- 如果資源也被標記為此資源的舊版本，則不能將其列為依賴項。（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 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]
- 此資源的唯一含義是對其他人來說，即此資源在指定的年代範圍內被認為是有效的和適當相關的，並且內容管理器 將接受指定適用年份的搜尋過濾器。
- 示例
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 True Color）（Trainz 1.0 - TC3 慣例：_art、_body 和 _shadow 是早期 Trainz 資料模型需求規定的三個子資料夾，名為 “asset-filename_suffix”（過時的標籤 -
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 Online 安全區域 中的站點。目前，嵌入式瀏覽器可接受三個域
auran.com
ts2009.com
ts2010.com
此外，不要直接連結到這些域，建議使用自定義 Trainz 短 URL 格式來為 URL 提供未來防護，以防將來站點佈局發生更改。“短 URL” 是 Trainz 特定的 URL，它透過允許內容建立者引用 N3V 網站上的特定頁面來幫助保護內容免受未來影響，而無需依賴特定的網站佈局。短 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 容器 是任何資產都可以使用的頂級 config.txt 檔案 條目，該資產從 KIND TrainzBaseSpec 派生（簡而言之，所有資產）。此容器允許資產直接 包含另一個資產的指令碼 從父資產的指令碼檔案使用 N3V TrainzScript 的 Script_Include_Directive。
- 相關
擴充套件容器是使用特定命名約定的自定義標籤或子容器的列表。
此容器是一個簡單的鍵值表，包含指令碼化資產的名稱及其 KUID。在編譯資產的指令碼檔案時，會搜尋這些 KUID 以查詢指令碼包含檔案。鍵或標籤名稱目前未使用（即為 佔位符引數）用於搜尋；值表示要包含的資產的 KUID。能夠搜尋和識別鍵名是內容建立者要求的功能，因此建議使用指令碼檔名而不是數字虛擬標籤名作為最佳實踐，因為它比 KUID 引用傳達的資訊更多。
S-I-T 容器驗證
[edit | edit source]通常最好將此類引用限制為 KIND 庫 資產，但這不是強制性的，可以引用任何資產。
S-I-T 容器示例
[edit | edit source]script-include-table {
a-key <kuid:nnnn:nnnnn>
enginespec <kuid2:www:xxxxx:yy>
anim-doors <kuid:tttt:uuuuuu>
}
extensions 容器
[edit | edit source]- 型別: 擴充套件容器.
- 欄位定義: 一組擴充套件屬性，為指令碼提供超出為該資產型別定義的 Config.txt 檔案 規範的額外資訊。在建立新的擴充套件時，應注意遵守擴充套件命名指南；在為現有擴充套件提供資料時，應注意遵守擴充套件建立者的指南。Auran 保留根據擴充套件建立者的指南，在稍後日期對 擴充套件容器 中的特定條目新增驗證的權利。
較新且不太常見
[edit | edit source]以下關鍵詞是相對較新的發展，在較舊的資產中將沒有類似物或存在。
category-keyword 標籤
[edit | edit source]- 型別: 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 tag|Custom-category-list 標籤|custom-category-list string|Custom-category-list 字串|Custom-category-list 容器|custom-category-list 容器
custom-category-list
[edit | edit source]- 型別: ascii 字串陣列容器。
- 欄位定義: 用分號 (;) 分隔的自定義類別識別符號列表。每個 自定義類別識別符號 應為一個簡短的（例如，3-6 個字元）字母數字標記。字串中不應包含其他字元（包括空格）。
- 這些自定義類別用於使指令碼能夠快速定位某些類別的資產。強烈建議謹慎引入新的自定義類別識別符號。
- custom-category-list 標籤值總共不應超過 64 個字元。除非存在只能透過 custom-category-list 方法滿足的現有特定指令碼要求，否則應將此標籤留空。
member-of-groups 容器
[edit | edit source]- 最小版本: 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 檔案指定一些預設資產組。確切的行為可能會在模擬器的不同版本之間發生變化，但是當前的邏輯在 這裡 進行描述。
可選的已棄用標籤
[edit | edit source]- 以下標籤對於任何資產都不強制性，許多資產將其留空。
- 從歷史上看，識別和許可標籤從 Trainz 0.9 (Beta) 開始。
license
[edit | edit source]- 型別: UTF-8 多行字串。(由程式設計師命令棄用。)
- 欄位定義: 許可證描述了資產建立者希望如何使用此資產。最常看到的是許可證宣告，禁止在任何付費路線、依賴資產（例如，轉向架、聯軸器等火車部件）或重新制作中使用受版權保護的資產，包括在任何收費運營的網站上分發資產。（理論上，這對於 DLS 也是正確的。FCT 費用用於更快的訪問和無限下載，而不是訪問資產。）
- DLS 上的大多數資產都是 知識共享署名-相同方式共享 (CC-BY-SA) 的糟糕版本，例如此版本和其他維基百科維基專案。
- license 標籤的含義不明確，N3V 不建議使用它，但它的存在早於 N3V 的管理 6-7 年。
- 上傳到 下載站 或提供用於包含在遊戲中的內容可能受特定再分發合同或許可協議的約束，該協議取代了此欄位中的任何文字。許可證欄位不提供本地化支援。許可證欄位的文字不會由 Auran 或 N3V 驗證或執行，並且可能對終端使用者具有法律約束力，也可能不具有法律約束力。
- 另一方面，Planet Auran 的歷史表明，有人透過將其他人的內容作為自己的內容來侵犯版權，可能會導致他們迅速被禁止使用 Auran 網站並喪失下載站許可權等，並被永久遮蔽。此外，社群將嚴厲打擊其他使用者侵犯他人的版權行為，並回避違反者並忽略允許留在 DLS 上的任何資產。
- 總而言之，對於試圖克服陡峭的內容建立學習曲線（每個人都希望有更多內容建立者！）的 Trainzer 來說，試驗和修改資產是一種被接受甚至被認可的生活方式，但是如果資產有依賴部分，尤其是網格、指令碼、紋理，這些是智慧財產權——在上傳您的作品之前，請獲得使用屬於其他人的這些部分的許可。
|
|
author 標籤
[edit | edit source]- 型別: 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 是 Trainz 1.x--TRS2004 Trainz 時代資產的主要資料夾名稱，並且通常是 CM 在開啟檔案進行編輯時開啟的資料夾的名稱；在當今此類早期資料模型資產中，通常會發現 asset-name 也用於早期 Trainz 時代的子資料夾系統，在火車車廂資產中提供子資料夾名稱“asset-name_art”、“asset-name_body”、“asset-name_shadow”。 在修復此類資產時，通常可以使用資原始檔中的樣板程式碼複製和貼上的 SAR 替換該值。 此替換通常會正確定義和連結資產的子資料夾（用於車身、陰影和藝術作品），因為該早期方案中的檔名基於 asset-name 標籤。
- 範圍：在 軌道或橋樑資產 中找到，早於 v2.9 標準，當時樣條物件發生了很大的變化，轉變為統一的資料模型定義，放棄了混合中的一些先前種類，轉而支援所有樣條物件統一在 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(s) 存在，則直接刪除。
- 如果資產的 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' 結尾，並具有四位數字，s.a. 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，該關鍵字在 Map 配置檔案中被定義，但使用方式相反——成為一個 kind region kuid 引用。因此，Region 在 Maps 中是必需的，並且自 TS2012 以來，與標籤型別一樣，它在大量資產中都是非法的，這些資產曾經作為 TRS 系列版本 Surveyor 工具視窗的 '分組資料' '快速過濾器' 出現。
- 在 TRS2009 之後，任何 region 標籤到文字字串都已過時，因為在程式設計師看來，他們用 Pick List 取代了 Surveyor 工具中 '型別和區域' 字串值的 粗略過濾 分組選擇器。這兩個標籤都有一些優點和缺點，它們都可追溯到 Trainz 0.9 Beta 版本。
- 參見上面的 bendy，已棄用/過時的 TS2009 之前的 kind track 資產模式控制標籤。
thumbnail 標籤是 thumbnails container 的早期單檢視實現（上面簡要介紹了它）。Trainz 的早期 N3V 之前的程式設計師版本將在主資產根資料夾或資產名稱_art 或資產名稱_body 資料夾中找到一個 .jpg 檔案，該檔案最好大小為 240x180 畫素，並使用它在 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 及之後版本的工具提供的超大型列表相同。
- ↑ 資產 Committing（TANE 的提交）是將內容納入資料庫並將內容交叉引用到資料庫索引中的過程和步驟，以便在執行時模組中訪問這些內容。
- ↑ 驗證資產的一種方法是除了這些值之外，還將 TBV 降低到 2.5-3.7 範圍，看看這些訊息是否消失。你可能需要嘗試幾次才能降低到足夠低的範圍，反之亦然，較舊的 TBV 無法識別較新的關鍵字，可能會顯示不同的錯誤訊息。但不要害怕嘗試，即使在這種情況下失敗也能帶來知識和經驗，而且你不會破壞任何東西！如果是這樣，你可以確信，僅僅提供一個值就是解決問題的方案。通常，一些現代需求僅僅需要關鍵字對，因此在標籤後面新增一個空行或在標籤後面新增一組空的括號，就可以滿足需求，在這種情況中，錯誤測試會過於嚴格。
- ↑ 注： 此列表在 N3V TrainzOnline Wiki 中被 '維基化'，這意味著在 'KIND' 這個詞之後第一個字母被大寫，而 config.txt 檔案中的實際資料標籤名稱是 全部小寫 文字。該維基在很多術語中也使用雙引號，我們將在本文中避免使用雙引號。
- ↑ 'kind consist' 並不經常直接看到，它只存在於選單和內容管理器列表中。
- ↑ 必須謹慎使用 obsolete-table，它最常出現在 Auran 創作的資產中。該表格用更新的版本替換了舊的 kuid，大多數內容創作者正確地使用 kuid 的 Kuid2 形式來取代舊版本。相比之下，N3V 濫用 obsolete-table 來更新新發布的 '升級' 內建資產，這會導致很多混亂，而且無法獲得預期看到的資產。（例如，許多漂亮的 'Flip-trees' 在 TS10 和 TS12 中被 Speedtrees 取代，這影響了許多路線，在這些路線中，創作者並不希望也不需要 Speedtrees。在不同的安裝過程中，這也會導致丟失的依賴項，直到找到包含 obsolete-table 的資產。
- ↑ 最近將一個過時的資產匯入TANE的經驗表明，至少有五個備用kuid會取代那個糟糕的翻轉樹資產。由於speedtrees的引入和TANE的全面改革，它積極追求最更新的合適資產，現在ContentManager流程中允許存在多個不同kuid的資產來取代同一個kuid。作為一個良好的做法，只有在絕對必要時才使用obsolete-table...例如，在您想要上傳到DLS或在網站上自發布的依賴資產中，取代一個不想要的付費資產。
- ↑ 關於類別時代標籤範圍：已知可行的安全做法。其他“未來十年”的值在使用前應進行測試。
- ↑ 許多容器在列表中使用虛擬/佔位符名稱。這些可以是描述性詞語，只要它們不包含空格字元即可。在短語構造的名稱中使用下劃線或句點可以保持可讀性並顯著提高畫質晰度。例如，一個貨運火車車廂可能運載45種合法產品型別。這些將在依賴項容器中列出。使用Coal，granite，crushed_limestone等，可以更容易地維護和更改表格。Jes Sayin'自1976年起擔任程式設計師
- ↑ 在第二個縮圖容器示例中，有一個額外的第二個512x512大小的影像。DLS將使用哪個影像尚不清楚。也可以包含更大的影像尺寸，透過電子郵件聊天，T:ANE可能支援更大的影像尺寸，這將在預覽操作或DLS列表中使用。N3V Games通常不會發布此類資訊。
- ↑ 早期的做法可以追溯到Trainz 1.x，它使用關鍵字/標籤“thumb”以及帶引號的路徑規範引用指向執行時選單的240x180縮圖影像。藝術資料夾包含一個帶有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，作為未經增強的源頁面，缺少歷史資訊（標籤），可在以下位置找到；訪問日期=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 程式碼標準的更新資訊，這些標準隨著軟體功能的新增而有所變化。 |