Trainz/AM&C/Content Creator Plus

Trainz 資源維護和建立

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

術語表

HKeys-CM

HKeys-DVR

HKeys-SUR

HKeys-WIN

滑鼠使用

符號

內容創作增強版

內容創作增強版（或在論壇中更常被稱為CCP）是一個資源建立和編輯工具，其目標是嚴格執行語法；一個軟體模組，與“內容管理器增強版—— (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 獲取和載入到預渲染記憶體中的時間產生非常非常小的影響，但一旦進入執行時資源列表，該資源的二進位制形式將按需以相同的方式呈現，無論版本如何。大多數此類更改都是美觀的，或者資料放置（例如，標籤或標籤功能成為容器內的引數，而不是配置檔案主體）——正如“修復舊資源”的經驗通常會證明的那樣。它們是試圖在讀取和儲存 RUN-TIME 版本時儘可能快地獲得不必要的理想，而忽略了這些解釋何時何地可以而且應該發生的錯誤。

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

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

事實是，這種綜合處理可能是 N3V Games 最大的錯誤。由於不足和無法解釋的原因，程式設計師決定強制執行實際上是美觀和不重要的“樣式更改”，這些更改本來可以透過使用者社群的翻譯過程來處理，而給內容建立者帶來了幾乎需要不斷演進已擱置的成果的負擔，如果他們保留了任何原始檔案的話，這些檔案是在幾年前建立的。更簡單、對所有人都有益的做法是採用適應不同 TBV 標籤混合、放置和預設值的例程，允許完全功能的數字模型在資源提交期間作為預處理步驟自動更新到 CCP 所期望的標準。

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