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
 |
|