Trainz/AM&C/Content Creator Plus

Trainz 資產維護與建立

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

術語表

HKeys-CM

HKeys-DVR

HKeys-SUR

HKeys-WIN

滑鼠使用

註釋

Content Creator Plus

Content Creator Plus （或在論壇中更常見的是 CCP）是一個資產建立和編輯工具，其目標是嚴格執行語法；這是一個軟體模組，與 'Content Manager 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 進化的那段時期。 這是一個更嚴格、更狹窄的測試障礙和“可接受性解釋”的應用，因為它應用了該版本之前的所有累積更改。 這與Content Manager 的故障測試完全不同，後者根據列出的 TBV 的變化，透過應用基於宣告的 trainz-build 的 TBV 標準的適當的舊測試和格式解釋來做出反應。 問題是，所有 CCP 變體都假設當前的最小 TBV 技術水平，而一項僅對人工操作者而言很重要的微小更改，例如更改名稱、類別-類引數 或描述說明，需要升級所有資料結構以允許 CCP 重新安裝資產（即提交到資料庫）。 因此，對於資產的正常維護，CCP 相對無用且令人煩惱，因為它需要額外的時間來符合其認為必要的標準，正如所指出的，這些標準是理想的，在面對舊時代預設行為和做法時沒有任何執行時影響！ 這並不是說 CCP 無用。 它是一個出色的工具，可以幫助利用新功能的新內容利用並獲得不熟悉的資料組合或名稱的正確語法。 再次，正如所指出的，這些通常是控制功能的資料標籤和值，這些功能在舊的資料模型中無法實現，這就是它們被新增的原因！ 因此，CCP 迅速演變成一個硬核資料建立工具，普通 Trainzer 的使用率很低。

事實是，這種組合處理可能是 N3V Games 最大的錯誤。 出於不足和無法解釋的原因，程式設計師決定強行插入實際上是外觀和無關緊要的“樣式更改”，這些更改本可以透過社群的翻譯過程來處理，並讓內容創作者承擔幾乎不斷地改進一個已經擱置的工作產品的負擔，如果他們保留了任何原始檔案的話，這些檔案是幾年前的。 更簡單、對所有人都有益的做法是，利用能夠適應不同 TBV 標籤、位置和預設值的例程，允許完全可用的數字模型在資產提交期間作為預處理步驟自動更新到 CCP 所期望的標準。

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