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