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 的管理层和所有者应该感到羞愧。