Trainz/AM&C/內容建立者 Plus

Trainz 資產維護和建立

TOC | 開始 | 有趣 | AM&C | 建立 | 書內參考文獻 | ORP 參考文獻:  • 索引 • 容器 • 種類 • 標籤 | 附錄  • 版本

詞彙表

HKeys-CM

HKeys-DVR

HKeys-SUR

HKeys-WIN

滑鼠使用

符號

內容建立者 Plus

內容建立者 Plus（或在論壇上更常稱為 CCP）是一個資產建立和編輯工具，設想為嚴格的語法執行器；一個與“內容管理器 Plus— (CMP) 一起在 2005 年秋季的 TRS2006 中引入的軟體模組。與每個版本自己的 CM 版本一樣，每個版本都有自己的 CCP，能夠處理或強制 Trainz 資料模型的進展；通常版本到版本，這些只是資料組織方式和期望的呈現方式的輕微演變變化。

每個 CCP 都是由 CM/CMP 右鍵點選（選擇並執行）彈出選單直接啟動的，直到 2012 年釋出的 TS2009-SP4。隨著 TR06 的 CMP 在多年中逐步升級到 TS12 的 CM 3.7，每個新的 CM 對其接受的舊資產翻譯到有效（執行時）資料模型中的標籤和容器變得更加挑剔。實際上，某些先前的做法和預設理解變得非法，幾乎總是沒有必要地——而這種自願的 N3V 程式實踐，實際上，產生了錯誤內容訊息，因為新的 CM 正在改變規則... 當僅僅遵守舊的做法的預設資料定義仍然是可行的時候。

-->證據是普遍存在和易於測試的：只需做一個小的改變，比如將網格表安裝到舊資產並更新 trainz-build 值（TBV）到下一個版本的本機最小 TBV——實際上，這種小的改變是“資料型別升級”，儘管相對於資產渲染的功能而言，實際上對執行時的影響為零，因此肉眼無法察覺。它可能會對資產的 GUI 獲取和載入資產到可預渲染記憶體的計時產生非常非常小的影響，但一旦進入執行時資產列表，該資產的二進位制形式將按需以相同的方式渲染，而與版本無關。大多數此類更改是美觀的，或者資料放置（例如，標籤或標籤功能成為容器內的引數而不是配置的主體）——正如“修復舊資產”的經驗通常會證明的那樣。它們是試圖在讀取和儲存執行時版本時儘可能快地獲得一個不必要的理想，而這個理想在何時何地進行這樣的解釋是可以的，也應該進行這樣的解釋。

具體來說，CCP 是一個文字處理語法檢查器和檔案/資料夾測試工具，它試圖使用最新的資料首選項來強制執行理想的資料配置。CCP 的長期效益是它強制嚴格遵守最新的可接受資料模型（即最高 TBV 標籤和最新的資料結構 Auran/N3V 的程式設計師優先選擇 在該版本支援的技術範圍內釋出的顯式 TBV 因此適用於測試資產 作為定義可接受編碼的高階要求在 config.txt 檔案的資料中。當 N3V 引入 Trainz 生命週期策略並加強了對資產上傳的故障測試時，這個問題就加劇了——故障測試要求手動將舊資料結構消除到新的 TBV 實踐中，就像每個 CCP 版本一樣，但絕大多數此類更改都是無關緊要的，名稱更改、將資料翻譯成法語、義大利語或阿爾巴尼亞語等等。幾年來，CM 和 DLS 要求為資產製作縮圖，但只有那些使用 texture.txt 檔案方法制作的縮圖才能保留在 DLS 版本中... 整個過程充斥著不必要的強制要求，造成了衝突，並給資產建立者——Trainz 社群的最有價值成員——帶來了不必要的時間開銷！

因此，這些更可取的“更現代”的安排被用來 定義 CCP 因此嚴格的故障測試標準。 ) 在 Trainz 演變的那個時代。這是一個更嚴格和更窄的測試障礙和“可接受性解釋”的應用，因為它應用了所有累計的更改，直到該版本。這與內容管理器的故障測試對列出的TBV的變體作出響應透過應用基於宣告的trainz-build的 TBV 標準的適當的舊測試和格式解釋來完成。問題在於所有 CCP 變體都假設當前的最低 TBV 技術水平，並且一個對人類操作員來說僅僅是重要的小改變，例如更改名稱、類別-類引數或描述說明，需要升級所有資料結構，以便 CCP 允許資產重新安裝（即提交到資料庫）。因此，對於資產的正常維護，CCP 相對來說是無用的，而且令人惱火，因為它需要額外的時間來符合它認為必要的標準，正如所指出的，這些標準是理想的，在面對舊時代的預設行為和實踐時，它們沒有任何執行時效果！這並不是說 CCP 是無用的。它是一個非常好的工具，可以幫助新的內容利用新的功能並獲得不熟悉的資料組合或名稱的正確語法。再次說明，正如所指出的，這些通常是控制功能的資料標籤和值，這些功能在舊的資料模型中無法實現，這就是它們被新增的原因！所以 CCP 很快退化為一個硬核資料建立工具，普通 Trainzer 很少使用它。

事實是，這種結合的處理可能是 N3V Games 最大的錯誤。由於不足和無法解釋的原因，程式設計師決定強迫“風格改變”，這些“風格改變”本質上是化妝品和無關緊要的，可以透過使用者社群的翻譯過程來處理，並給內容建立者帶來幾乎持續地發展他們幾年以前就已擱置的（如果他們保留了任何原始檔案的話）產品的負擔。更簡單、對所有人更好的是，採用那些適應不同 TBV 的標籤、位置和預設值的混合的例程，允許功能完備的數字模型在資產提交過程中的預處理步驟中自動更新到 CCP 所期望的標準。

這絕對不會使任何版權失效，因為建立者的原始檔案是完整的，它們只是被儲存到資料庫中，並進行了額外的相對直接的微小處理以進行更改替換——一個壓縮的 .chump 檔案（現在是 TANE 的加密 .tzarc）由歷史方法建立，無論如何，原始的未更新的和版權原始檔案將作為備份保留！簡單、高效，並且不會給使用者社群帶來負擔。版本蠕變是由要求所有上傳的內容都通過當前 TBV（不僅僅是其自身功能使用所要求的必要 TBV 水平，新的標籤及其值）稽核造成的，這阻礙了 DLS 的升級，或者消除了其資產庫中缺失的依賴關係。N3V 和 Auran 的管理層和所有者應該感到羞愧。