Trainz/种类
| |||
|
|||
|
词汇表 |
HKeys-CM |
HKeys-DVR |
HKeys-SUR |
HKeys-WIN |
鼠标使用 |
符号 |
操作说明:点击正文中的脚注([2])或注释标签([note 12])将引导您(定位页面)到该条目的确切文本。 • 然后:点击那里的?符号,将带您返回到您开始阅读的地方。 |
在本地安装数据库之外定义 Trainz 资源的所有元素都包含在一个单个文件夹中——资源文件夹或资源源文件夹——当资源分别打开进行编辑或构建时,这两个文件夹都可以访问——都涉及(可能多种类型的编辑)编辑和数据操作。
种类是在这些资源源文件夹中定义的特殊父数据形式,并在文件夹的唯一config.txt 文件中定义。Kind 标签的合法值受到严格限制。[注释 1]每个配置都有一个种类,并且每个配置在本地定义的目录中都有一个家,用于构建该资源。因此,资源源文件夹也可以分类为高于 Trainz 容器的一般数据类型,并且每个都由其明确的唯一关键字指定类型控制,即Kind 标签值。
因此,每个 Kind 都表示在自定义的自包含 Trainz 资源定义层次结构中的一组基本的 Trainz 资源类型或资源种类数据类。内部的config.txt 文件负责定义唯一 KIND 行的“资源类型”数据需求,并将 KIND 要求定义为必要的(或可选的)内容与 TBS设置的其他强制性和可选资源数据定义聚合在一起——实际上,配置的任务是定义父 KIND,将其他TrainzBaseSpec定义行所需的内容与父 KIND 行(种类“名称”)值所需的定义行合并,以创建种类 KIND 类型的资源,如在 TBS 中设置“种类“KIND 枚举类型名称””行所定义。
将计算机科学翻译成英文:每个“Kind 标签”都设定了 资源是什么,以及其资源文件夹在提交给 Trainz 内容管理器进行提交(现在,由于 TANE 内容管理器的出现,奇怪地称为提交)或验证(错误检查和测试,在将资源提交(或提交)到数据库之前的步骤。也在上传到 DLS 之前。每个种类都与其源 config.txt 文件配对(通常)作为其最开始的行之一[注释 2]。所有内容都是 TAG--DATA 对的一部分。有些是 TAG-容器,许多是 TAG-值,但所有配置数据都是配对的。容器中的子容器遵循相同的规则。即使是数组数据元素——字符串、多个值、多种可能性(类别时代和类别区域)在一行上以配对关系定义。因此,容器是关键字标签,表示预期“{”和“}”,并根据标签名称定义的规则处理两者之间的数据。
理解 KIND 的作用可以说仅次于理解 TrainzBaseSpec 和包含这两者的普遍容器 config.txt 文件的作用。在某种情况下,这三者都是用户在修复或创建资源时需要掌握的最重要的数据元素。幸运的是,每种 Trainz 资源都有一个唯一的 KIND,因此可以根据需要或系统地逐个掌握这些 KIND,类似地,可以逐个理解每个容器。
事实上,所有这三个元素都紧密相连,因为它们在资源根文件夹中一起工作,该文件夹必须包含配置,而该配置又“必须”包含TBS 中的 Kind 标签和其他强制性 TBS 支持定义,例如kuid 和用户名,并且根据 TBS 行中定义和选择的 KIND,“必须”因此包含该Kind 标签和所有支持定义所需的所有定义……包括必需的容器和子容器。
在较小程度上,KIND 和类别类标签一起告诉 内容管理器软件在资源的config.txt 文件中哪些其他关键字是必要的、可选的或非法的,而后者旨在将该类别类成员(正在定义的资源)添加到各种排序标准的组合中,这些标准对 CM 的排序和选择操作很有用。
|
Trainz 种类是定义用于描述单个识别 kuid 下资源类型的最小数据结构的上层容器。
KINDs 在 Trainz 模拟器中定义了属性,这些属性与类别-类设置一起构成必要的信息字段,以便正确渲染资产模型。从非常真实的意义上讲,KIND 数据结构(将与模型渲染和运行时模拟需求相关的不同类型相关数据进行分组)是 Trainz 中的第一级容器(尽管它有一个特殊的名称“KIND”),并且几乎总是需要其他容器级数据组在 ini 文件中与其一起使用。这些是枚举的支持容器和标签,KIND 标签和类别-类的枚举类型组合使用这些标签和容器来确定必须为这种资产定义哪些其他数据元素,这可以被认为是子 KIND,因为所有类似的资产都需要定义相同的数据元素。
现在所有容器和类似容器的结构都位于 config.txt 文件中,但区别仅仅在于“容器定义类型”通常在几个不同的 KIND 定义的资产中具有作用域(适用性),并表示一个共享属性(一个特征,例如转向架),而每个 KIND 对该类资产都是唯一的。KIND 机车和 KIND 货车都具有转向架(卡车上的车轮),因此两者都在其 ini 文件中都有一个转向架容器。
|
下面的列表截至页面撰写时是完整的,并且会定期更新。请参阅Trainz-Wiki KIND TrainzBaseSpec以获取可能的更新。(那里下面的许多链接连接到 N3V TrainzOnline Wiki,并且这些链接与 Wikibook 部分链接之间存在细微的颜色差异。在 2014 年 8 月下旬,那些仍然是红链接的链接尚未在 N3V Wiki 中正式定义,尽管该类可能已在内容创建者的论坛之一中推广。)
所有 Trainz 定义的数据(内容)都包含三个必需元素:一个config.txt 文件 用于组织数据,一个标识,即kuid(仅用户名对您没有用处,但是可以创建合法的资产而无需名称!)以及最后,一个合法定义的 KIND 标签。KIND 负责,是管弦乐队的指挥,是排长或 CEO 发出指示——为处理后的一切设置要求。简而言之,KIND 的值,一个小的、选择的、严格定义的仅限成员的组——告诉 Trainz 软件在虚拟世界中渲染和显示什么,以及如何(或在哪里)找到使资产的那些部分链接在一起的其他部分在该 config.txt 文件中。
以下每个子类都被认为具有TrainzBaseSpec作为其数据“父类”。[注释 4]下面列出的一些 KIND,那些带下划线的 KIND,是早于Trainz 数据模型在TS2009版本中(即 2008 年后期以来)更改的旧版 KIND,并且自那以后 N3V 程序员只施加了渐进的(增量的)更改。
目前,有关基于这些旧版 KIND 修复资产的详细信息可以在 N3V Trainz Wiki 的内容创建者指南部分TrainzOnline 网站此处找到,并提供有启发性的旧版 KIND 示例此处。强烈建议Trainz 下载站的任何用户或任何考虑创建内容的人员仔细阅读 CCG。通过了解旧内容定义的背景历史获得的见解,然后可以与 TrainzOnline 对相同数据类型的当前覆盖范围进行对比和比较,因为通常这种过去与现在的对比可以为修复、更改和自定义资产提供宝贵的见解。更重要的是,CCG 中的写作是专业制作的,并且更具同义反复性——它通常会让您了解如果更改了这一点或那一点的扩展效果,而 Trainz Wiki 则没有提供这些信息。TrainzOnline 上发布的 CCG 是TC1&2/TC3版本——最后出版的几本小册子,其出版日期可追溯到 1999 年的Trainz;TC3 CCG 包含来自 TRS2004/TRS2006 和UTC数据模型的已更改的 Enginespecs 机车资产,需要正确更新。
- 本节将提供指向一组示例子页面的链接,展示一个常见资产的演变过程
- 到 v1.3-v1.5、v2.2、v2.5、v2.9、v3.7、v3.9 等版本的 KIND 配置,或到其他活跃的数据模型发生变化的版本,可以使用文件比较软件查看差异。
- 什么是最重要的 KIND?
答案取决于您目前正在处理哪种资产和资产子类型。在人类的思维过程中,机车和货车都是“火车车厢”(Kind "traincars"),但在 Trainz 配置文件中则是不同的 KIND 声明,而且柴油机车和蒸汽机车都需要定义不同的数据参数来模拟资产;这种配置中的差异来自kind的定义,而强制性的类别-分类标签仅在CM和勘探者选择和排序过滤器中起作用。
这些通常比较简单,因此可以引入 KIND 的用法。
本Trainz/Kinds章节是一个存根占位符,一个概述或标记,表示本书的这一部分尚未完善。您可以通过扩展它,更全面地讨论主题,从而帮助 Wikibooks Trainz 项目。 需要完成的工作: 本节将提供指向一组子页面的链接,展示从 v1.3-v1.5、v2.2、v2.5、v2.9、v3.7、v3.9 或其他数据模型发生变化的版本的常见资产 KIND 配置的演变过程,可以使用比较软件查看差异。 |
本Trainz/Kinds章节是一个存根占位符,一个概述或标记,表示本书的这一部分尚未完善。您可以通过扩展它,更全面地讨论主题,从而帮助 Wikibooks Trainz 项目。 需要完成的工作: 本节将提供指向一组子页面的链接,展示从 v1.3-v1.5、v2.2、v2.5、v2.9、v3.7、v3.9 或其他数据模型发生变化的版本的常见资产 KIND 配置的演变过程,可以使用比较软件查看差异。 |
本Trainz/Kinds章节是一个存根占位符,一个概述或标记,表示本书的这一部分尚未完善。您可以通过扩展它,更全面地讨论主题,从而帮助 Wikibooks Trainz 项目。 需要完成的工作: 本节将提供指向一组示例子页面的链接,展示从 v1.3-v1.5、v2.2、v2.5、v2.9、v3.7、v3.9 或其他数据模型发生变化的版本的常见资产 KIND 配置的演变过程,可以使用比较软件查看差异。 |
本Trainz/Kinds章节是一个存根占位符,一个概述或标记,表示本书的这一部分尚未完善。您可以通过扩展它,更全面地讨论主题,从而帮助 Wikibooks Trainz 项目。 需要完成的工作: 本节将提供指向一组子页面的链接,展示从 v1.3-v1.5、v2.2、v2.5、v2.9、v3.7、v3.9 或其他数据模型发生变化的版本的常见资产 KIND 配置的演变过程,可以使用比较软件查看差异。 |
- ↑ KIND 和许多其他 Trainz 数据定义,虽然范围广泛,但都是枚举数据类型……这意味着它们必须是从允许的单词列表中选取的 <值>。其他都不适用!
- ↑ 配置文件中所有标签和容器的位置实际上并不重要,除了数据结构在引号、方括号和圆括号中的正确嵌套。
- ↑ 虽然 N3V 程序员没有正式承认(我在任何地方都没有看到),但LOD 文件[1](例如 'meshname.LM.txt' 和filespec.texture.txt 文件)可以被认为是ini 文件类型或包含文件类型,实际上扩展了配置文件中内联定义。(texture.txt 文件 + LM.txt 文件) 每个文件不仅包含路径信息,还包含必要的如何实现数据指令行,并且与 config.txt 文件行一样,必须采用正确的格式,否则资产将生成错误。
• config.txt 文件和此类包含文件之间的一个关键区别在于,它们并不严格遵循 Trainz关键字—<值>对在一行上的格式,而是经常在其语法中使用等号。 - ↑ 注意:此列表在 N3V TrainzOnline Wiki 上被“维基化”,这意味着在“KIND”一词之后首字母已大写,而配置文件中实际的数据标签名称则是全部小写文本。该维基在相当多的术语中也使用了双引号,我们将在本文中避免这种情况。
- ↑ 'kind consist' 并不经常直接看到,它只存在于菜单和内容管理器列表中。
本参考页面改编自TrainzOnline Wiki,根据CC-BY-SA 3.0 许可证发布。与同一主题的源页面相比,本页面可能会包含更多文本说明、阐述、历史和/或示例。 TrainzOnline Wiki 主要由程序员或知识渊博的内容创作者维护,可能包含有关当前trainz-build 代码标准的更新信息,随着软件功能的添加,这些标准具有一定的变化趋势。 |