Trainz/refs/TrainzBaseSpec
KIND TrainzBaseSpec 為所有 Trainz 資源型別在所有 config.txt ini 檔案 中提供基礎定義。TBS 提供了許多“標準標籤”,這些標籤對(至少,在法律上可以被定義)所有 Trainz 資源都適用,無論其型別[1]。
- 其中一些是強制性的,因為它們決定了資產的進一步處理以及 config.txt 檔案和其資料夾中資產資料的解釋。
- 但是,大多數是可選的,在大多數子資產中可以省略使用該標籤的定義行。
父類
[edit | edit source]- 無。對於所有由事實上的父容器定義的內容(即所有 Trainz 數字模型所需的 config.txt 檔案)來說,它是有效的,並且大多數情況下都是必要的。KIND TrainzBaseSpec (TBS) 是一個根類,其他 Trainz 資產類都是從它派生的。
- 之所以說它們是派生的,是因為它們繼承了處理屬性(指令)和由其中列出的引數定義的值,其中最關鍵的是 kind 標籤的值。該列舉詞決定了資產的特定 種類宣告和要求,這些宣告和要求被新增到該資產配置檔案中 TBS 的定義中。其他關鍵的 TBS 定義資料也非常重要和有用,例如資產的名稱、Kuid 識別符號和版本、Trainz 生成值 (TBV) 以及其他具有廣泛可變的定義需求、適用性和範圍的資料,例如 string-table、obsolete-table、kuid-table 和縮圖,這些都是情況性的。字串值,即使是資產名稱和描述,在實踐中也通常是完全不必要的,可以完全省略。
- 當宣告一種種類時,該種類將成為父類,要求並規定必須在該類中滿足的必要資料對,此外還要滿足 TBS 中列出的那些資料對。
- 對於該資產種類的某些情況,某些引數可以保持未定義,尤其是針對較舊的 Trainz 生成標籤值的常見做法,以及針對這些情況,內容管理器或 內容建立者 Plus (CCP) 實用程式將分配預設值,但在處理它時會列出警告訊息。TrainzOnline Wiki、這裡或舊的 TC3 時代 內容建立者指南 (CCG) 中的許多標籤都會提到預設值。
- 從 TRS2006 和 Trainz Classics (TC1&2) 開始,每個版本的 Content Manager 模組都越來越多地強加了預提交錯誤測試[note 1],並且每個模組都越來越堅決地提醒使用者,當它期望存在這樣一個標籤-資料對時,它還沒有定義過這樣一個標籤。
在 TANE 之後版本中,許多這些“昨天預設”的定義行今天將更經常地生成錯誤,要求明確的值定義,而過去載入時這些值是預設的。[note 2]與過去時代資產定義錯誤有時會導致臭名昭著的“藍色畫面宕機”或更常見的是導致執行時軟體崩潰到桌面,從而導致編輯內容丟失,並且可能需要重建資料庫相比,這是一個更好的煩惱。
子類
[edit | edit source]
所有 Trainz 定義的資料(內容)都有三個必需的元素:一個 config.txt 檔案 用於組織資料,一個標識,即一個 kuid(只有使用者名稱是沒用的,但一個合法的資產可以在沒有名稱的情況下建立!),最後,一個合法定義的種類標籤。種類是負責人,是樂隊的指揮,是排長或 CEO 指揮方向——為所有後續處理的內容設定要求。簡而言之,種類的值,一個小而緊密的成員制群體——告訴 Trainz 軟體在虛擬世界中要渲染和顯示什麼,以及如何(或在哪裡)找到將這些資產部分連結在一起的配置檔案中需要的其他部分。
下面列出的每個子類都被認為擁有 TrainzBaseSpec 作為它們的“父類”資料。[note 3]下面列出的一些種類(帶下劃線的那些)是遺留種類,早於 TS2009 版本中對 Trainz 資料模型 的更改(即自 2008 年後期以來),N3V 程式設計師只對這些更改進行了逐步(增量)的更改。
目前,可以在 N3V Trainz Wiki 的 內容建立者指南 部分找到有關修復基於這些遺留種類的資產的詳細資訊,該網站的地址是 TrainzOnline 網站,並提供一些具有啟發性的 遺留種類示例。強烈建議 Trainz 下載站 的所有使用者或任何考慮建立內容的使用者閱讀 CCG。通過了解舊內容是如何定義的背景歷史,可以將其與 TrainzOnline 對相同資料型別的當前覆蓋範圍進行對比和比較,因為這種過去與現在的對比往往可以為修復、更改和定製資產提供寶貴的見解。更重要的是,CCG 在 TrainzOnline 上釋出的內容是 TC1&2/TC3 版本——是自 1999 年的 Trainz 以來印刷的幾本小冊子中的最後一個版本;TC3 CCG 包含來自 TRS2004/TRS2006 和 UTC 資料模型的已更改的 Enginespecs 機車資產,需要進行適當更新。
表格 I,TBS 標準定義
[edit | edit source]TBS 標準定義
[edit source]這些標籤和容器是標準定義,幾乎所有資產中都可能存在。 一些標籤是可選的,內容建立者可以選擇不定義它們。 標籤是關鍵詞,並且具有單個分配的 _鍵值_ 或容器,例如 _字串陣列_ 或 '{' ... '}' 繫結封閉的標籤值對或子容器。(Trainz 配置檔案中宣告的所有內容都是成對出現的,即使 '{' ... '}' 也被認為是 _一個 鍵值。_
- 容器是 _'key' 和 'key-value' 對的集合_ 以及 _TBS 中的 '上層容器'(與子容器相對,例如縮圖容器中的子容器)通常以 '-table' 結尾。_
| kind | "_'string-value'_" |
| trainz-build | 'float',一位小數 |
| kuid | <Kuid 編碼值> |
| username | username "_'string-value'_" |
| username-XX | username-XX "_'string-value'_" |
| description | description "_'string-value'_" |
| description-XX | description-XX "_'string-value'_" |
| kuid-table (容器) { 依賴項列表 |
一個鍵值表,列出該資產所依賴的所有資產。 |
| obsolete-table (容器) { } |
kuids 列出此資產替換(使過時)的資產 通常沒有(空)[note 5] |
| string-table (容器) { } |
資產中使用的字串和訊息的鍵值列表 通常為空,僅在路線和場景中很大。 |
| string-table (容器[s]) { 非英語 語言文字 } |
翻譯字串列表,匹配 onto 強制性英語 string-table |
| category-region tag 列舉 程式碼 | category-region "_'string-array'_" |
| category-class tag | category-class "_'列舉 string-value'_" |
| category-era tag | category-era "_'constrained string-array'_" 年代 |
| category-keyword "_'string-array'_" 最大長度為 64 位元組 | category-keyword tag 自然語言搜尋關鍵詞 (替換型別,區域) |
| custom-category-list "_'string-array'_" |
指令碼介面功能 |
| must-have-product-rights "_'string-value'_" |
DRM 字串陣列 |
| must-not-have-product-rights "_'string-value'_" |
DRM 字串陣列 |
| privileges (容器) { } |
更多 DRM |
| thumbnails (容器) { } |
縮圖容器 |
| script (檔名) | "_'string-value'_" |
| class (指令碼資產類) | "_'string-value'_",必須與 script 規範類同步。 |
| script-include-table { } |
(列出庫指令碼的容器) |
| extensions (容器) { } |
資產使用的正式指令碼擴充套件 |
| license "_'string-value'_" | 資產建立者的版權宣告 |
| author | "身份 _'string-value'_" |
| organisation | "第三方組身份 _'string-value'_" |
| contact-email | "電子郵件地址 _'string-value'_" |
| contact-website | "作者/組的網站網址 _'string-value'_" |
| member-of-groups (容器) { } |
此資產所屬的 KIND Asset-group 資產列表。 |
支援的標籤
[edit | edit source]TrainzBaseSpec 在 config.txt 檔案 中支援以下標籤。 ∅:
kind 標籤
[edit | edit source]- _型別:_ 字串。
- _欄位定義:_ 此 config.txt 檔案 所代表的資產型別。 請參閱索引 Kinds 和列表:此處(上方)
kuid 標籤
[edit | edit source]- KUID
- _ 'Koolthingz Unique IDentifier'._ Trainz 系統軟體的 _資產唯一資料庫參考號_,也擴充套件到 KUID2 格式以跟蹤多個版本。 Trainz 可升級性和資產模組化設計的核心,因為每個資產都有自己的唯一 kuid 程式碼,因此可以指定元件(轉向架)或來自其他資產的整個火車車廂,並在新資產中選擇性地替換兩者(重新蒙皮或修改卡車)。
- 基本 KUID 格式:'<kuid:wwwwww:xxxxxx>',其中 wwwwww 是 _作者的_ 'Trainz 唯一身份',而 xxxxxx 代表作者分配的 模型識別程式碼。
|
- 大多數 Trainz 資產在它們的 kuid-table 中指定一個依賴項列表——其他元件資產,這些資產由軟體套件的各個部分組裝起來,以構成 kuid-table 容器 中的可渲染和可用的資產。
- 在許多資產的核心,特定的標籤可以透過 _kuid 引用定義,並使用引用資產作為一部分。_ 事實上,這就是重新蒙皮的實現方式,並且可以使用資產中的網格,儘管更現代的實踐建議將此類引用指向網格庫資產。
- KUID2
- KUID 格式的更新和更新跟蹤修改版本,它允許指定版本號。 A
<kuid:xxx:yyy>與<kuid2:xxx:yyy:0>相同(零修訂或版本零,_表示原始版本_)- 這允許資料項(Trainz 資產)攜帶資產的固有版本程式碼。 這通常不會與 CM Trainz-build 程式碼(識別軟體技術級別)匹配,但表示以前的版本歷史記錄。
- 在資料庫中同時擁有這兩個資產的情況下,具有較高字尾程式碼的 KUID2 資產會覆蓋或替換較舊的資產。 擁有早期版本不是必需的,但 CM 會將丟失的修訂鏈列為丟失的依賴項,對於那些對 CM 中該功能的汙染感到反感的人來說這是一個軟體錯誤,或者程式設計師保留了這個“功能”,無論如何,都會降低使用 CM 來識別使用者缺少哪些內容的實用性,並導致使用者花費時間手動弄清楚什麼是真正的東西。
- 主要內容:trainz-build 標籤,縮寫:TB & TBV (TB-value)∅
- 型別:帶有小數點的小數,由 N3V [2] 列舉,以跟蹤和識別與演化軟體的技術水平相對應的各種資料型別。
- 範圍:1.0–4.3,直接對應('對映onto3rd' Trainz 1.0—TANE-SP1+hf2; 預計此值會隨著每次新的主要軟體升級而增加 0.1,向上攀升。
每個合法值必須與釋出的 Trainz 版本號 嚴格匹配,但以下情況除外:
- 分配給 V1.4 的 TBV 或版本值是 Auran 的 Paintshed 版本,這是一個重繪工具,也適用於 Microsoft Trainz Simulator (MSTS),並且也作為 TRS2004 的輔助軟體模組的構建值出現;特別是它的 ContentManager.exe 實用程式。
- 1.7 和 2.0 之間的差距要麼是外國語言版本,要麼是 Auran 在經過幾個小時的挖掘和研究後更可能的情況,因為在構建最初 Trainz 的程式設計師團隊眼中,TRS2004 版本是第二個 Trainz 產品,無論前臺如何炒作營銷名稱(比如 Trainz UTC,是終極任何東西…… 真的嗎?。拜託!真的嗎!?)
- 從 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 在基於 Windows 和 Mac 的作業系統之間平滑遞增的過程。
注意:熱修復 不會更改版本號。
- 欄位定義:此資產構建(和存檔)到的檔案格式版本(不一定與資產使用技術水平有關),而是對應於透過在 Content Creator Plus 中建立資產分配的資產級別,與在 CM 的標題欄中找到的級別相同。
- 程式設計師建議此數字通常應設定為正在建立和測試資產的 Trainz 安裝的 Trainz 版本號。Content Creator 社群則試圖將此數字設定為儘可能低的數字,以便在新資產下載時提供儘可能廣泛的使用者範圍。優秀的 內容建立者 會在對應版本的裸機安裝(無新增內容)上進行測試,並驗證生成的 cdp 是否包含所有相關材料。
- 某些資產種類根據其trainz-build 版本標籤的解析方式會有很大的不同。注意:trainz-build 標籤 是必須的。如果未指定,Trainz 將根據 config.txt_file 的內容嘗試以原始方式猜測舊版本 Trainz,這通常會解析為 TBV 的 1.3 值。
- 型別:UTF-8 字串,資產的使用者名稱,必須指定。
- 欄位定義:此資產的英文可見名稱。
在 TC1&2(v2.7)之後 trainz-build 中,使用者名稱也成為編輯資產時作業系統資料夾名稱,而資產檔名將被忽略,而在 v2-6 配置檔案中,資產檔名優先。根據 N3V games 的 TBS 標準,此欄位絕不包含非英文文字,除非資產名稱是專有名詞(例如地名)且沒有英文字地化變體。此值是每個人通常搜尋和記住的資料,因此建議保持清晰的名稱。
|
- 型別:UTF-8 字串,使用者名稱標籤 的其他語言版本。
- 欄位定義:(其中XX 被替換為表示該語言的適當 本地化程式碼。)此資產的本地化可見名稱。此欄位類似於使用者名稱欄位,但表示非英文區域設定。資產中可能存在多個username-XX 標籤,每個支援的區域設定一個。如果不存在合適的 'username-XX' 標籤來在給定的終端使用者系統上表示此資產,則使用英文使用者名稱標籤代替。
- 型別:UTF-8 多行字串,提供對資產的清晰語言描述。
- 欄位定義:此資產的英文可見描述性摘要。
描述在 Content Manager 的“資產詳細資訊”窗格中可見,用於闡明資產名稱,提供規格,以及經常提供一些歷史資訊。
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)支援,這些字串錶帶有與 description 和 username 關鍵詞/標籤的國際化字尾相匹配的本地化程式碼字尾(XX),但這些語言鍵控的字串表容器在左側條目中始終具有相同的鍵值。
- 這些左側鍵或標籤既用作“本地索引關鍵詞”,也用作“語言之間的等效表”。
- 左側列將始終包含內容建立者賦予“特殊”名稱的物件,例如訊號、軌道標記和工業、交叉口等的名稱,這些物件可能被引用,並將在駕駛員和測量員模組的“查詢工具”(CTRL+F ) 函式小程式中出現。
- 相反,索引側也不會列出預設的名稱,例如無數的交叉口,在構建路線地圖時,它們會自動透過隨機數索引(即毫無意義的雜亂。如果重要,路線構建 CC 將命名它!),但會自動包括潛在的臨時資產,例如火車車的預設名稱。如果重新命名,這些名稱將取代其對應的預設名稱。
- 它的主要用途是用於那些旨在與指令碼引用互動並接受可變屬性的物件,例如火車站、工業所需的或準備運出的產品數量,或者由互動式火車車(滾動工業到指令碼)和其他可配置資產(如通用廣告牌風格的標誌)攜帶的,該標誌透過少量的高度調整和角度扭轉可以放置在庫存建築或工業的正面,以在建築物上放置不同的商業名稱。換句話說,這是一種可配置的場景。
- 總的來說,在路線地圖或佈局中,這些 LHS 名稱對應於地圖資產上命名的物件,這也是大多數字符串表出現的地方(從字面上看,在一個大型路線kind 地圖中,成千上萬的條目被填充)。
- 在某些資產中,該預設名稱連線到軟體指令碼,因此字串表變得特別重要,而不是平淡無奇。(見下文)
- 在每種型別的資產中,使用字串表型別始終是合法的,就像 description 標籤、trainz-build 和 kind 標籤一樣。與它們不同的是,它不必存在或被定義,也不是強制性的。封裝在字串表容器中的值除非程式碼預期它們的結合,否則不會有任何功能或影響。
- 在其他資產中,再次以假設的可程式設計商業標誌為例,如果字串表要與軟體互動,則需要賦予它一個預設名稱。所有地圖可放置資產都可以命名或重新命名,但“特殊名稱”必須與指令碼和字串表索引值匹配。大多數可配置資產定義一個介面變數,該變數用於替換預設名稱作為指令碼引用的索引或查詢表,以及資產的二進位制資料。其他變數也可能在可程式設計資產中定義。這些變數可能被指令碼引用,但正是索引值使其進入地圖或會話字串表,當需要駕駛員或會話建立者的可變性時,這一切才能協同工作。
- 相反,如果沒有系統軟體知道索引中命名的專案的所在位置,則物件的指令碼可能不會有任何觸發、條件檢查或更新能力。這是 2000 年代的 Trainz 1.0 中物件的特徵,而不是 2003 年釋出的 TRS2004 之後更現代的 Trainz 鐵路模擬器。(我們已經走過了漫長的道路!)
- 有些資產只能作為一個組一起工作。在這種情況下,在地圖或會話層中命名每個資產使它們能夠一起運作。例如,考慮一個帶有五條軌道的公路平交道,其中兩條軌道偏離交叉口,形成所謂的“菱形交叉口”。如何設定訊號,以便任何鐵路交通都關閉公路閘門,或者使用菱形交叉口禁止其他火車透過正在透過交叉口的火車?道路和鐵路訊號、道岔和閘門都必須協同工作。某些“ATLS 系統”資產及其指令碼透過字串表結合在一起,可以使這個複雜的系統正常運作。
- 請參閱 string-table-XX 以獲取更多資訊。
string-table-XX 容器
[edit | edit source]- 型別: UTF-8 字串列表容器,本地化字串表,每個字尾對應於除英語以外的語言。
- 欄位定義:(其中XX被替換為代表的語言的適當本地化程式碼。)此欄位類似於string-table欄位,但表示非英語區域設定。
英文字串表(沒有後綴)是強制性的,其他本地化語言是可選的,由資產作者決定。許多提交給 DLS 的資產,以及隨後用於與 Trainz 版本捆綁在一起的路線,通常會翻譯並擁有完整的一套本地化翻譯,用於 description-XX 和字串表。特別是,與版本捆綁在一起的路線和會話在每次零售版本中都會被專業翻譯成多種語言。
請注意,字串表的左側列是相同的,因為它是一個對映的符號表,並索引到二進位制資料中,例如網格、會話或路線檔案。只有使用名稱,即兩個元素中的右側或資料元素,才是本地化的,並由執行時本地化軟體替換。如果需要,這些名稱可以手動編輯,以便更易於使用者理解,即使在英文字串表中也是如此。索引或左側引用列語法在任何情況下都不能更改,因此在更改資料列中的名稱時要小心使用全域性 SAR 規範。
一個資產中可能存在多個string-table-XX標籤,每個支援的語言一個。每個標籤都應該包含一個字串列表,這些字串列表與string-table列表中的鍵相同,但值不同。如果在給定終端使用者系統上不存在適當的“string-table-XX”標籤來表示此資產,或者該列表中缺少適當的字串,則將引用英文string-table容器。
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 中只有一個替換 kuid 槽位,這將建立一個迴圈定義,要求自身較舊的版本!)
- 類似地,一個資源不能被列為它自己的依賴項。[OTOH,這已經經歷過(即在 TSxx CMs 中見證了成功提交的無錯誤資源)將地圖和會話在安裝之間移植,使用 GSARS 更改 kuid,以便重疊不會覆蓋已經在目標安裝上使用相同 kuid 的資源,而不會看到錯誤訊息。] 是否有效,還需要比我更勇敢或更愚蠢的人來驗證!--Fabartus, ed.
- 格式 (所有值均為 <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 新增到裝載和允許的產品隊列表條目中。(歡迎你,但這正是更改名稱的好理由!保持條理是製作資源的幾乎全部戰鬥!)
obsolete-table container
[edit | edit source]- 型別: KUID 列表容器,與 Kuid-table 容器 格式相同。
- 欄位定義:由該資源廢棄的資源的“佔位符鍵-鍵值”列表。嘗試載入此列表中的任何資源將導致載入此資源。
- 此外:兩個資源都標記第三個資源為過時是非法的,除非兩個資源中一個也標記另一個為過時。[註釋 6]
- 迴圈過時引用是非法的。
- 所有低編號 KUID2 版本的該資源都被隱含地標記為過時,不需要包含在該列表中。同時,較新的改進資源(具有更高的 Kuid2)及其前任之一絕不應該將同一前任(例如原始版本!)列為“中間”的前任—因為這些值用作替代條目表,只有一個資源可以替代早期版本。(陣列只儲存一個值,不能將兩個替換為一個!)
- 標記該資源的更高編號 KUID2 版本為過時是非法的,因為這會建立一個隱式的迴圈引用。
- 此列表中引用的資源必須與該資源具有相同的建立者,才能透過 DLS 上傳流程進行稽核和接受,此限制不適用於本地版本,例如,它可以用於將一大組 Traincars 上的所有舊紙質車輪 kuid 替換為一個圖形效果更好、更新的 kuid。
category-region 標籤
[edit | edit source]- 目的:在 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"(大多數第一世界國家)
category-class tag
[edit | edit source]- 目的:在 CM 和 Surveyor 中進行過濾(搜尋條件);根據 KIND 聲明確定 CM 軟體如何處理資源,以及 Surveyor 在哪裡列出它。
- 型別: 列舉字串。
- 欄位定義:單個 2-3 個字元的 類別類別 程式碼,用於描述此內容項。類別類別標籤用於提供超出資源種類隱含內容的額外的人工子分類。每個 Trainz 資源的類別類別標籤有助於描述資源在遊戲中的“意圖”,而不是資源的內部結構。
|
請注意,許多類別類別程式碼僅與特定資源種類相關—類別類別程式碼不應用於不合適的種類資源。
- 示例
| category-class "XBG" | 貨車—來自 PRR 60' | |
| category-class "BR" | 鐵路(非功能性場景)—可能是建築物 | |
| category-class "BIN" | 具有產品處理功能的工業資源 |
category-era tag
[edit | edit source]- 每個年代程式碼代表一個十年,由四位數字組成,然後必須以 's' 結尾
(例如“1990s;2000s;2010s”),從而建立一個列舉的軟體標記(值),它必須與指定的合法 年代程式碼 完全匹配。 - 字串中不應包含其他字元(包括空格等),包括(尤其是在字串末尾)在結束雙引號字元之前。
- 允許的年份範圍是 1800-2010s[註釋 7]
- 該資源的唯一意義是對其他人來說,該資源在指定的年代範圍內被認為是有效的且相關的,並且 內容管理器 將接受指定適用年份的搜尋過濾器。
- 示例
category-era "1920s;1930s;1940s;1950s"
縮圖容器
[edit | edit source]- 目的:在 CM 和 Surveyor 中進行過濾(搜尋條件)
- 型別: 縮圖容器.
- 欄位定義:在整個遊戲環境(包括在遊戲內、在 內容管理器 中以及在 下載站 上)中用於在二維預覽框、列表和圖示形式中表示該資源的縮圖。每個資料集都包含在子容器中(通常)使用 佔位符引數 作為鍵名稱或標籤。[註釋 8] 約定使這些數字從 0 開始,但值可以是任何可以作為 字串 評估的非空文字值。(參見下面的第二個示例)
- 一個真實的示例
- (來自資源修復編輯[3])
thumbnails {
0 {
width 240
height 180
image "$Screenshot (240)(kuid 68787 25222).jpg"
}
1 {
width 512
height 512
image "$Screenshot (512)(kuid 68787 25222).jpg"
}
}
另一個常見的大小是 火車場 和測量員資源選擇 API 中使用的 128x64“圖示”,它應該具有 Alpha 遮罩 或非常淺的背景。許多舊版本沒有使用 jpg 檔案,而是將 .tga 檔案(Targa True Color)列在一個名為 _art 的子資料夾中(Trainz 1.0-TC3 約定:_art、_body 和 _shadow 是由早期 Trainz 資料模型要求指定的三個子資料夾,稱為“資原始檔名字尾”(過時的標籤-<值> 對),看起來像下面的[註釋 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 的一個熱修復程式中被放棄,因為使用者社群中有很多抱怨。
• 如果缺少縮圖容器的資源(即使具有過時的縮圖標籤)後來在新構建的內建路線或會話中被選中,該資源通常將作為沒有影像的專案進行分發——如果紋理.txt 或 config.txt 縮圖容器沒有正確引用,它們將被剔除[註釋 11]。
- 型別: URL 字串。
- 欄位定義:指向資源線上描述、資源說明(幫助)或 TrainzOnline wiki 上其他幫助頁面的連結,用於在嵌入式專用 N3V 瀏覽器中使用。URL 必須解析到 Trainz Online 安全區域 內的網站。目前,嵌入式瀏覽器接受三個域
auran.com
ts2009.com
ts2010.com
此外,建議使用自定義的 Trainz 短 URL 格式,而不是直接連結到這些域,以防未來網站佈局發生變化。'短 URL' 是 Trainz 特定的 URL,它可以幫助未來內容保持安全性,允許內容建立者引用 N3V 網站上的某些頁面,而無需依賴特定的網站佈局。短 URL 適用於遊戲內使用,例如 info-url 連結,並且僅在嵌入式網頁瀏覽器中有效,而不是在任何外部網頁瀏覽器中有效。如果存在此標籤,則遊戲內按鈕將允許使用者檢視資源描述或幫助,而無需離開遊戲環境。
這在駕駛員中非常寶貴,用於訪問路線圖、指南或會話說明或澄清。
建議在任何情況下,如果資源提供類似的功能但外觀略有不同,則使用通用組頁面來表示整類資源。這減少了建立、維護和本地化此類文件的時間成本。
- 型別: 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。
- 相關
擴充套件容器是具有特定命名約定的自定義標籤或子容器的列表。
此容器是指令碼資源名稱及其 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 字串。
- 欄位定義: 一系列用分號 (;) 分隔的自然語言關鍵詞。字串中不應存在其他字元(包括空格或無關的標點符號)。這些關鍵詞構成了資產關鍵詞搜尋的基礎。資產的 使用者名稱 不必在 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 容器
- 型別: ASCII 字串陣列容器。
- 欄位定義: 一系列用分號 (;) 分隔的自定義類別識別符號。每個 自定義類別識別符號 應為一個簡短的(例如 3-6 個字元)字母數字標記。字串中不應存在其他字元(包括空格)。
- 這些自定義類別用於使指令碼能夠快速定位特定類別的資產。強烈建議謹慎引入新的自定義類別識別符號。
- custom-category-list 標籤值總共不超過 64 個字元。除非存在只能透過自定義類別列表方法滿足的現有特定指令碼要求,否則應將此標籤留空。
- 最小構建: V3.5 及更高版本
- 型別: Member-of-groups 容器,配對 佔位符引數 和 資產組 kuids 的列表。
- 欄位定義: 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 年。
- 上傳到 下載站 或提供用於包含到遊戲中的內容可能受特定再分發合同或許可協議的約束,該協議優先於此欄位中的任何文字。許可證欄位不提供本地化支援。許可證欄位的文字未經 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 及其下面的朋友。
|
- resource-name、name 和 name-XX — V1.3–v2.8 — 歷史上在幾乎所有 v1.3-v2.0 資源中都有發現。雖然 “resource-name” 在 v2.8 之前一直被保留,並且沒有引起任何抱怨,但在 v2.5 之後便不再建議使用;因此,在 v1.5 之後,資源的 config.txt 檔案中唯一需要的、想要的或被認可的名稱是 username-XX 變數。
資源名稱是 Trainz 1.x--TRS2004 Trainz 時代的主要資料夾名稱,並且在開啟檔案進行編輯時,CM 通常會開啟的資料夾名稱;在今天這樣的早期資料模型資源中,通常會發現資源名稱也用於早期 Trainz 時代的子資料夾系統,為火車車廂資源提供子資料夾名稱“resource-name_art”、“resource-name_body”、“resource-name_shadow”。在修復此類資源時,通常可以使用從資原始檔複製和貼上的模板中的 SAR 來替換該值。此替換通常可以正確定義和連結資源的子資料夾,以包含主體、陰影和藝術作品,因為在早期方案中,檔名是基於資源名稱標籤的。
- '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 的放置和選擇工具中列出的資源。在 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 在 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 以下,那麼縮圖通常仍然可以在更新的 CMs 中工作,前提是它位於 _art 子資料夾中,並且資源名稱與使用者名稱匹配。
- type — V1.3–v2.8 — 以前的過濾器修飾符,歷史上存在於幾乎所有資源中,但它在機車車輛、風景、樣條線、軌道型別(包括隧道和橋樑)以及路邊資源中尤為普遍。
- type 標籤與 “region 標籤” 一樣,在 Trainz 0.9—TC3 版本中 用作 “Surveyor 中的組過濾器”,它與 region 相結合,提供了更小的資源選擇 (工具組)。從 TS2009 開始,它刪除了這些本地可點選過濾器的功能和使用,轉而使用一個新的更繁瑣的過濾器。這些使工具選擇變得快速和簡單,而不是在工具選項卡之間切換時變得緩慢和暫停——如今的 TANE 之前的版本在工具選項卡之間來回切換時,常常因為重新載入整個選擇列表而感到不堪重負。
- type 和 region 都預設設定為 “All”,提供了與 TS09 及以後版本中的工具相同的超大列表。
- ↑ 資源 提交 (TANE 的提交) 是將內容合併到資料庫中並將其交叉引用到 DB 索引中的過程和步驟,以便它可以在執行時模組中被訪問。
- ↑ 驗證資源的一種方法是,除了這些值之外,其他方面都正常,方法是將 TBV 降低到 2.5-3.7 範圍,看看這些訊息是否消失。您可能需要降低幾次嘗試,直到足夠低,反之亦然,在較舊的 TBV 中無法識別的較新關鍵字可能會產生不同的錯誤訊息。不要害怕嘗試——即使失敗,也會帶來知識和經驗,而且您不會破壞任何東西!如果是這樣,您可以放心地認為提供值是問題解決方案。通常,一些現代需求只需要關鍵字對,因此標籤後面的空行或標籤後面的一組空花括號將滿足需求,而錯誤測試則過於嚴格。
- ↑ 注意: 此列表在 N3V TrainzOnline Wiki 上進行了 “wiki 化”,這意味著在 “KIND” 這個詞後面,第一個字母已改為大寫,而 config.txt 檔案中的實際資料標籤名稱是 全部小寫 文字。該維基還使用了一些詞語中的雙引號,這是一個習慣,我們將在本文中避免使用。
- ↑ 'kind consist' 並不常直接看到,它只存在於選單和內容管理器列表中。
- ↑ 必須謹慎使用 obsolete-table,它最常出現在 Auran 編寫的資源中。該表將舊的 kuid 替換為新的,大多數內容建立者正確地使用 kuid 的 Kuid2 形式來替代舊版本。相比之下,N3V 過度使用 obsolete-table 來升級新版本 “升級” 的內建資源,這會導致很多困惑,以及無法獲得預期看到的內容。(例如,許多漂亮的 'Flip-trees' 在 TS10 和 TS12 中被 Speedtrees 所取代,這影響了許多路線,在這些路線中,Speedtrees 並不被建立者 需要 也不被 想要。在所有安裝中,這也導致依賴項缺失,直到找到包含 obsolete-table 的資源。
• 此外,Assets.tdx 資料庫索引中每個 kuid 僅支援一個 obsolete 條目,使用 Kuid2 版本來過時化 kuid 會導致問題 (即,您將看到哪個?)
• obsolete-table 的一個絕佳用途是使用特定部件升級一系列資源,尤其是轉向架。新增一系列 kuid 以替換為較新的好的轉向架,可以透過單次編輯顯著改善路線或場景的外觀 (前提是轉向架,例如,與之相容,並且尺寸正確!) - ↑ 最近將一個過時資源引入 TANE 的經驗表明,至少有五個替代 kuid 使那個可憐的 Flip-tree 資源 過時。看來,由於 Speedtrees 的引入以及 TANE 積極追求最適合更新資源的混亂,內容管理器程序現在容忍多個不同 kuid 資源過時同一個 kuid。作為良好的做法,僅在絕對必要時使用 obsolete-table... 例如,在您要上傳到 DLS 或自行釋出到網站的依賴資源中,使用 obsolete-table 來替代不需要的付費資源。
- ↑ 關於 category-era 標籤範圍:安全的做法,已知有效。其他 “未來年代” 值應在依賴這些值之前進行測試。
- ↑ 許多容器在列表中使用虛擬/佔位符名稱。這些可以是描述性詞語,只要它們不包含空格字元即可。在短語構造的名稱中使用下劃線或句點可以保持可讀性並大大提高畫質晰度。例如,一輛貨運火車車廂可能裝載 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 上傳稽核軟體可能已經改變,以強制執行適當的縮圖容器。
- ↑ 關於 category-era-nn 與 category-era 標籤值: TRS 會接受任何一種形式的 category-era 資料;但 TS2009-SP0 及更高版本從以前合法的關鍵字-值對中建立了錯誤,並試圖強制內容建立者更改所有程式設計師故意破壞的資產。後來 DLS 上傳軟體強制執行了轉換,但這更可以接受,因為第一個動作讓許多人浪費了大量時間來修復那些不必要的錯誤,這些錯誤本應該在稽核舊的 trainz-build 資產時在軟體預過濾器傳遞中自動實施。這些操作實際上保證了舊的資產下載會存在錯誤。這是 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 程式碼 標準的更新和更準確的資訊,這些標準隨著軟體功能的新增而有所變化。 |

