跳转到内容

Trainz/类型

来自维基教科书,开放世界中的开放书籍
logo
Trainz 训练基础

Trainz 注释参考页面
目录 | 开始乐趣 | AM&C | 创作 | 书内参考 ORP 参考:  • 索引 • 容器 • 类型 • 标签 | 附录  • 版本
 术语表
 HKeys-CM
 HKeys-DVR
 HKeys-SUR
 HKeys-WIN
 鼠标使用
 符号

Kind 标签

[编辑 | 编辑源代码]
单击 此处快速导航到 KIND 的目录

所有定义 Trainz 资源 的元素(在 本地安装 数据库之外)都包含在 单个文件夹 中 - 资源文件夹资源源文件夹 - 其中任何一个都可以分别在打开资源进行编辑或构建时访问 - 这两者都涉及(可能许多种编辑)编辑和数据操作。

 

类型是在这些资源源文件夹中定义的特殊父数据形式,并且在文件夹中唯一的 config.txt 文件 中定义。Kind 标签的合法值受到严格约束。[注释 1] 每个配置都有一个类型,并且每个配置在包含本地定义的其他部分以构成该资源的目录中都有一个位置。因此,资源源文件夹也可以归类为比 Trainz 容器 的通用数据类型高一级,并且 每个类型都由 它们明确的唯一关键字 指定和控制,即 Kind 标签值。  

因此,每个 Kind 都表示 Trainz 资源定义层次结构中的一组基本的 Trainz 资源类型或资源类型数据类,这些类型是自定义的、自包含的。其中的 config.txt 文件 的作用是 定义唯一的 KIND 行的“资源类型”数据需求 以及根据 KIND 要求定义为必要(或可选)的这些内容,以及由 TBS 设置的其他强制性和可选资源数据定义 - 事实上,配置的作用是定义 父 KIND,将这些 TrainzBaseSpec 定义行需要的其他内容与 父 KIND 行(类型“名称”值)要求的定义行 合并以创建一个 类型为 KIND 的资源,如 在 TBS 中设置“类型“KIND 枚举类型名称””行所定义的
将这些计算机科学翻译成英文:每个“类型标签”都设置了 资源 的规则,以及提交到 Trainz 内容管理器进行 提交(现在奇怪地称为 提交,因为 TANE 内容管理器出现了)或 验证(错误检查和测试,在将资源提交(或提交)到数据库之前进行的步骤。 也是在上传到 DLS 之前进行的步骤。 每个类型都与一个源 config.txt 文件关联,通常是其最前面的几行之一[注释 2]。 一切都是 TAG--DATA 对的一部分。 有些是 TAG-Container,很多是 TAG-Value,但所有配置数据都是成对的。 容器中的子容器遵循相同的规则。 即使是数组数据元素 - 字符串、多个值、多个可能性(类别时代和类别区域) - 也在一行中定义为成对关系。 因此,容器是关键字标签,意味着期待“{”和“}”,并根据标签名称定义的规则处理它们之间的 data。

了解 KIND 的作用可以说仅略微不那么重要,因为它了解 TrainzBaseSpec 的作用以及两者无处不在的容器 config.txt 文件的作用。 这三者都将在某个时间点,为该案例,成为用户掌握以修复或创建资源最重要的数据元素。 幸运的是,每种类型的 Trainz 资源都有一个唯一的 KIND,因此这些可以根据需要或系统地逐一掌握,类似地,理解每个 容器 可以逐一进行。

事实上,这三个元素紧密相连,因为它们在资源 根文件夹 中协同工作,该文件夹 必须包含 配置,而配置反过来“必须”包含 TBS 中的类型标签 和其他强制性 TBS 支持定义,如 kuid用户名,以及从 TBS 行中定义和选择的 KIND,因此“必须”包含该 类型标签 所要求的那些定义,以及所有支持定义... 包括必需的容器和子容器。

在较小程度上,KIND 和 类别类标签 协同工作,告诉 内容管理器 软件资源的 config.txt 文件 中需要哪些其他关键字,哪些是可选的,哪些是无效的,而后面定义的目的是将 类别类 成员(正在定义的资源)添加到各种排序标准的组合中,这些排序标准对用户在 CM 的排序和选择操作中很有用。

在 Trainz 数据模型中定义资源


Trainz 类型是定义资源类型下最少数据结构的上层 容器,这些资源类型在一个唯一的标识 KUID 下。

层次结构和级别

[编辑 | 编辑源代码]

KIND 在 Trainz 模拟器中定义了属性,该属性与类别-类设置一起设置了信息所需字段,以使资产模型正确渲染。在非常真实的意义上,KIND 数据结构(对模型渲染和运行时模拟的需求相关联的不同类型数据分组)是 Trainz 中的第一级 容器 (尽管具有特殊名称“KIND”),并且几乎总是需要其他容器级数据组在 ini 文件中伴随它。这些是枚举的辅助容器和标签,KIND 标签和类别-类的枚举类型组合使用这些标签来确定必须为这种资产定义哪些其他数据元素,这可以被认为是子 KIND,因为所有类似资产都需要相同的数据元素被定义为好吧。

现在所有容器和类似容器的结构都占用 config.txt 文件,但区别仅仅在于 '容器定义的类型' 通常在几个不同的 KIND 定义的资产中具有范围(适用性)并代表一个共享属性(一个特性,例如转向架),而每个 KIND 对该类资产是唯一的。KIND 引擎和 KIND 货车都有转向架(在卡车上的车轮),因此它们在自己的 ini 文件中都有转向架容器。

在 Trainz 数据模型 II 中定义资产


下面的列表在页面撰写时是完整的,并且会定期更新。有关可能的更新,请参阅 Trainz-Wiki KIND TrainzBaseSpec。(那里面的许多链接连接到 N3V TrainzOnline Wiki,并且它们与 Wikibook 部分链接之间存在细微的颜色差异。那些在 2014 年 8 月下旬仍然是红链接的还没有在 N3V Wiki 中正式定义,尽管该类可能已经宣传在 内容创建者 的论坛中。 


KIND 的种类

[edit | edit source]

所有 Trainz 定义的数据(内容)都包含三个必需元素:一个 config.txt 文件 来组织数据,一个身份,意味着一个 kuid(仅用户名对你没有任何帮助,但是合法资产可以在没有名称的情况下创建!),最后,一个合法定义的 KIND 标签。KIND 负责,它是管弦乐队的指挥,排长或 CEO 指挥方向——为处理后的所有内容设置要求。简而言之,KIND 的价值,一个很小、紧密定义的仅成员组——告诉 Trainz 软件要在我们创建的虚拟世界中渲染和显示什么,以及如何在何处(或在何处)找到将这些资产部分链接在一起的 config.txt 文件中所需的其余部分。
  下面的每个子类都被认为是 TrainzBaseSpec 作为其数据的“父类”。[注释 4] 下面列出的少数 KIND,那些带下划线的,是早于 Trainz 数据模型TS2009 发布(即 2008 年后期以来)的旧版 KIND,N3V 程序员自此仅施加了逐渐(增量)的更改。
  目前,可以在 N3V Trainz Wiki 的 内容创建者指南 部分中找到基于这些旧版 KIND 修复资产的详细信息 TrainzOnline 网站此处,并以发人深省的 此处提供旧版 KIND 示例。强烈建议所有 Trainz 下载站 用户或任何考虑创建内容的人都仔细阅读 CCG。从了解旧内容定义方式的背景历史中获得的见解可以与当前 TrainzOnline 对相同数据类型的覆盖范围进行对比和比较,因为这种过去与现在的对比通常可以为修复、更改和自定义资产提供宝贵的见解。更重要的是,CCG 在 TrainzOnline 上的写作是由专业人员制作的,并且更加赘述——它通常会让你洞悉如果改变这一点或那一点会产生的扩展效果,而 Trainz Wiki 并没有提供这些效果。TrainzOnline 上发布的 CCG 是 TC1&2/TC3 版本——从 1999 年的 Trainz 开始印刷的几本小册子的最后一个版本;TC3 CCG 包含来自 TRS2004/TRS2006 和 UTC 数据模型的已更改引擎规范机车资产,需要正确更新。

TrainzBaseSpec 子类 KIND(类型资产组)

 


重要日常KIND

[编辑 | 编辑源代码]
本节将提供链接到一个示例子页面集,展示一个常见资产
从 v1.3-v1.5、v2.2、v2.5、v2.9、v3.7、v3.9 或其他版本到 KIND 配置的演变,在这些版本中,活跃的 数据模型 发生了变化,可以使用 文件比较软件 查看差异。
什么是最重要的 KIND?

答案取决于您当前正在处理的资产类型和资产子类型。在人类思维过程中,机车和货车都是 Kind "traincars",但在 Trainz 配置中它们是不同的 KIND 声明,而柴油机车和蒸汽机车都需要定义不同的数据参数来模拟资产;这种配置内的差异来自于 kind 的定义,而强制性的 category-class 标签 仅在 CMsurveyor 的选择和排序过滤器内有作用范围。

场景 KIND

[编辑 | 编辑源代码]

这些通常比较简单,因此要介绍 KIND 的使用方式,

轨道 KIND

[编辑 | 编辑源代码]

轨道旁 KIND

[编辑 | 编辑源代码]

机车 KIND

[编辑 | 编辑源代码]

发动机规格

[编辑 | 编辑源代码]

kind engine

  1. KIND 和许多其他 Trainz 数据定义,虽然范围很广,但都是枚举数据类型……意味着它们必须是来自合法允许词列表的 <值>。没有其他需要申请!
  2. 配置文件 中所有标签和容器的位置并不重要,保存数据结构在引号、括号和圆括号中的正确嵌套才是重要的
  3. 虽然 N3V 程序员没有正式承认(我在任何地方都看不到),但 LOD 文件[1](如 'meshname.LM.txt' 和 filespec.texture.txt)可以被认为是 ini 文件 类型或 包含文件 类型,实际上扩展了配置文件中包含的内联定义。(texture.txt 文件 + LM.txt 文件)每个文件不仅包含路径信息,还包含必要的如何实现数据指令行,并且与 config.txt 文件行一样,必须以正确的格式出现,否则资产将生成错误。
     • config.txt 文件和此类包含文件之间的关键区别在于,它们并不严格遵循 Trainz 的关键字—<值> 对的行格式,而是经常使用等式作为其语法的组成部分。
  4. 注意: 此列表在 N3V TrainzOnline Wiki 上进行了“维基化”,这意味着在“KIND”这个词之后,第一个字母被大写,而 config.txt 文件中的实际数据标签名称全部为小写文本。该维基还使用了相当多的双引号,这种做法我们将在本文中避免。
  5. 'kind consist' 并不经常直接看到,它基本上只存在于菜单和内容管理器列表中。

参考资料

[编辑 | 编辑源代码]


华夏公益教科书