Trainz/refs/KUIDs 系譜 - 地面紋理
  |
此頁面 正在建設中 此處的內容可能會在短時間內發生重大變化。所有 Trainz 使用者和 Wikibooks 使用者，如果瞭解此主題，都歡迎提供幫助。 當頁面變得更加成熟時，您可以刪除此標記，並將其替換為 {{Trainz-stub}} 或使用章節存根模板（{{Trainz-sect-stub}}) 在未完成的章節上。 |
 |
Trainz 幾乎從一開始就使用了一種資料結構，該結構是在 Trainz 1.0 SP3 中引入的，即 已過時表格，以允許內容被資產的另一個（大概是更新更好的）版本所取代。到 Trainz UTC 形成時，KUID 和 KUID2 繼承系統被髮明出來，使這兩種方法都成為合法的替代方案。
使用已過時表格存在幾個問題——其中大部分問題源於 Auran/N3V 內部內容建立團隊過度使用這些表格來維護具有負作者索引的 KUID 識別符號。這種可疑的策略早已過時，本應在引入 KUID2 功能時就淘汰，KUID2 始終向前和向後指向相關資產版本的變化，並由此推斷出任何後續迭代。基礎 KUID 識別符號適用於相同的資產，因此父子關係始終是明確的，並且與已過時表格封閉的 KUID 不同（它們有自己的基礎 KUID，與舊的 KUID 沒有特定關係），共享相同基礎 KUID 識別符號的資產是可以預測的——新一代具有更高的字尾，而不是不同的（並且不可知的！）隨機 KUID。
從表面上看，這似乎是小事一樁，但在二十年來內容建立者實踐的倍增中，從絕對意義上講，斷開連線的下一代 KUID 的數量簡直驚人。在任何大量下載的路線中，絕大多數缺失的資產都會遇到這個問題，大約 50% 的未知 KUID 正是因為在本地內容管理器資料庫中同時存在這兩個資產之前，無法知道這兩個不同的基礎 KUID 識別符號之間存在關係。
N3V 幾乎始終如一地隨著每次主要零售版本（和主要 TBV 平臺）的釋出而提高迭代，也加劇了這個問題——同樣（根據差異二進位制比較），除了新 KUID 中的身份和修改後的已過時表格之外，基本元件檔案沒有特別重大的變化。
為了說明這個問題，考慮一個沒有碎石的“橋樑軌道”（實際上在從屬橋樑種類中關鍵字為“bridgetrack”！）的繼承，它被用作數十個甚至數百個橋樑中的連結資源資產（一些內容建立者建立自己的，其他內容建立者預設為 N3V 內建的，從而增加了問題的數量和規模！）。
- 此列表由 TANE 生成
- 透過請求“已過時”的 <kuid:-1:100673> 1 軌木溼的 所有版本——它是先前 TS10 迭代的內建替代品，並且情況變得更加混亂，因為 TANE 的 <kuid:-25:1062> TANE 1Trk Wood 實際上正在合併兩條不同的軌道線，一條是溼木，另一條與帶有多個內建碎石道砟的普通木軌道一致。
| 沒有識別符號的行專案報告為“未知”。 | |
|---|---|
<kuid:-25:1043> <kuid:-1:15> 1 track wood <kuid:-25:1055> <kuid:-25:1058> <kuid:-25:1002> <kuid:-25:197> 1 track wood US |
<kuid:-25:1061> <kuid:-25:196> 1 track wood damp <kuid:-1:100608> 1 track wood US <kuid:-1:100673> 1 track wood damp <kuid:-25:1062> TANE 1Trk Wood <kuid:-25:195> 1 track wood |
哪一個先出現，它們以什麼順序替換了之前的？當一個資產只知道其 KUID 表格和已過時表格中的內容，而這兩個表格都沒有在 CM 中顯示時，就會存在資訊差距，GUI 無法克服……它們不知道要使用哪個現有的 KUID 來替換 kuid 表格 中的舊編號。
為了完整起見，可以透過更改與 DLS 和 TS2012 之後的內容管理器的的資料通訊來緩解此問題。似乎有額外的資訊可用，可能在“連結 KUID 的側邊列表”中，TANE 和 TRS19 可以訪問這些資訊，但舊版內容管理器的設計並未報告或使用這些資訊。這在上面列表的報告內容中很明顯。TS12 返回的完全相同的“顯示資產版本”查詢的結果完全不同。
1 track wood damp,<kuid:-25:196> 1 track wood damp,<kuid:-1:100673> (Obsolete)
因此，我們可以得出結論，<kuid:-25:196> 取代了 TS09/TS10 時代的 <kuid:-1:100673>，僅此而已。當然不是說它的祖先是可追溯到 TBV 1.3 和 Trainz 1.0 的某個特定普遍存在的 KUID——這正是新下載的舊路線或橋樑可能列出的依賴項。砰，資訊差距，甚至對軟體也是如此。這引出了另一個相關問題。通常，替代資產會被分配相同的 Trainz 版本 (TBV)，這可能是為了擴大國際知名度和實用性，以便將新的語言組新增到標準版本資產佇列中。
- KUID（基礎 KUID）格式
<kuid : 作者 ID# : 基礎 KUID 索引 >- KUID2 格式
<kuid2 : 作者 ID# : 基礎 KUID 索引 : 版本字尾>
具體來說，最常見的 Auran“作者識別符號”KUID 部分跨越了二十年的增長，包括：{id#: -1, -3, -10, -12, -14, -16, -18, -25, -26, -101, -105 和最近很多 +523}；強調了程式碼最多的部分。
具有諷刺意味的是，測試和比較表明，Auran 系譜中大多數後續 KUID 都是圖形和實用意義上相同的資產，迭代變化主要集中在新增新的國際化資料名稱和描述（參見：username-XX 和 description-XX），當版本翻譯成其他語言時。
其他獨立創作者，“第三方內容”的原創者，由於使用過時的表格而不是世代KUID，導致廣泛的問題，他們是內容創作者中最古老的一批人，其中包括兩位最多產的蒸汽機車建模大師，paulhobbs和bdaneal，他們分別專注於英國和北美的蒸汽機車及車輛。不幸的是，通常情況下，定位一個特定的缺失KUID是存在問題的，許多KUID都隱藏在套件的未索引部分中。但是應該尋找並下載哪個套件呢？其他一些，特別是Paul Hobbs先生的一些關鍵依賴項，僅作為過去某個付費路線的一部分發布——現在已無法獲得，並且在路線替換中已被付費的“所謂升級”所取代，導致那些只想使用派生重製資產且缺少依賴項的可憐傢伙陷入困境。在這種情況下，或許是無法治癒的。[註釋 1]
對於後一種型別，似乎過度依賴私人的第三方網站來分發完整的資料集。他們中的許多機車特別是利用低多邊形，通常是不可見的網格作為錨定網格，提供方向和原點，座標系的軸線，以提供錨點，其他網格附加到這些錨點上。這種網格可以隨著部件的新增而有機地增長，或者具有在3D空間座標中移動的特定錨點。
對於這兩位大師所熟知的如此華麗的蒸汽機車來說，這種方法確實存在機械優勢：當某物（如凸出、笨重且擁有許多活動部件，每個部件都有自己的運動需要動畫）的單獨配置的部分，每個部分都有自己的運動需要動畫，單獨處理資料集使他們能夠在完成這樣的模型需要花費的幾個月時間裡，隨著每個子系統的進展逐步除錯每個部件。大多數Auran/N3V來源的模型很少有這種複雜程度，在大多數情況下，它們通常具有更平凡和簡單的任務。
<kuid:523:1463> TS09_53_Concrete <kuid2:523:1463:1> TS09_53_Concrete <kuid2:523:1464:1> TS09_54_Asphalt <kuid:523:1464> TS09_54_Asphalt <kuid2:523:1465:1> TS09_55_Asphalt <kuid:523:1465> TS09_55_Asphalt <kuid2:523:1466:1> TS09_56_Asphalt <kuid:523:1466> TS09_56_Asphalt <kuid:523:1467> TS09_57_Asphalt <kuid2:523:1467:1> TS09_57_Asphalt <kuid2:407941:1048:3> SeasonalGrass4 <kuid2:407941:1048:2> SeasonalGrass4 <kuid2:407941:1048:1> SeasonalGrass4 <kuid:407941:1048> SeasonalGrass4 <kuid2:407941:100040:1> SeasonalGrass8 <kuid:407941:100040> SeasonalGrass8 <kuid2:407941:100040:2> SeasonalGrass8 <kuid:407941:1044> SeasonalGravel2 <kuid2:407941:1044:1> SeasonalGravel2 <kuid2:407941:1044:2> SeasonalGravel2 <kuid2:407941:1044:3> SeasonalGravel2 <kuid2:407941:1043:2> SeasonalGravel4 <kuid2:407941:1043:1> SeasonalGravel4 <kuid:407941:1043> SeasonalGravel4 <kuid:-25:1291> hayfield
 |
|