Trainz/refs/TrainzBaseSpec
(重定向自 Trainz/TBS)
KIND TrainzBaseSpec 为所有 Trainz 资产类型在所有 config.txt ini 文件 中提供基本定义。TBS 提供了一些“标准标签”，这些标签对于所有 Trainz 资产是通用的（或者至少，可以在法律上为所有 Trainz 资产定义）[1]。
- 其中一些是强制性的，因为它们决定了资产的进一步处理以及对 config.txt 文件和其文件夹中资产数据的解释。
- 然而大多数是可选的，并且在大多数子资产中可以省略使用该标签的定义行。
- 没有，对于由事实上的父容器（所有 Trainz 数字模型所需的 config.txt 文件）定义的所有内容都是有效且大部分都是必要的。KIND TrainzBaseSpec (TBS) 是一个根类，其他 Trainz 资产类是从它派生的。
- 据说它们是派生的，因为它们继承了参数中定义的处理属性（指令）和值，其中最重要的是 kind 标签的值。该枚举词决定了资产的特定种类声明和要求，这些声明和要求会添加到该资产配置文件中 TBS 的定义中。其他重要的 TBS 定义的数据具有明显的意义和效用，例如资产的名称、Kuid 标识符和版本、Trainz 构建值（TBV）以及其他具有广泛可变定义需求、适用性和范围的数据，例如string-table、obsolete-table、kuid-table和缩略图，这些数据都是临时的。即使是资产名称和描述的字符串值在实践中通常都是完全不必要的，并且可以完全省略。
- 当声明一种类型时，该类型成为父类，需要并规定必须在类中满足的必要数据对，除了 TBS 中列出的数据之外。
- 某些参数可能在一个资产类型的案例中保持未定义，尤其是针对较旧的 Trainz 构建标签值的常见做法，以及针对这些值，内容管理器或内容创建者 Plus（CCP）实用程序将分配一个默认值，但在处理它时会列出警告消息。TrainzOnline 维基、此处或较旧的TC3 时代内容创建者指南（CCG）中提到的许多标签都会提到一个默认值。
- 从 TRS2006 和 Trainz Classics（TC1&2）开始，每个版本的内容管理器模块都会施加越来越多的预先承诺错误测试[注 1]，并且每个版本都变得越来越坚定地警告这样的标签在期望这种标签 - 数据对时没有被定义。
在 TANE 之后版本中，许多这些“昨天默认”的定义行今天会更频繁地生成错误，要求在过去加载时默认值的情况下明确定义值[注 2]。与过去时代相比，这是一种更可取的烦恼，在过去时代，错误的资产定义有时会导致臭名昭著的“蓝屏死机”，或者更常见的是，将运行时软件崩溃回桌面，导致编辑丢失，并可能需要重建数据库。
所有 Trainz 定义的数据（内容）都具有三个必需的元素：一个config.txt 文件 用于组织数据，一个表示kuid 的身份（仅仅用户名是没用的，但是合法资产可以在没有名称的情况下创建！），最后一个是合法定义的类型标签。类型负责，是管弦乐队的指挥、排长或 CEO 发号施令——为处理之后的所有事物设置要求。简而言之，类型的值——一个小型精选的、严格定义的成员专属组——告诉 Trainz 软件在我们的虚拟世界中要渲染和显示什么，以及如何（或在哪里）找到将该配置文件中资产的这些部分链接在一起所需的的其他部分。
以下所有子类都被认为是其“父类”数据的TrainzBaseSpec[注 3]。下面列出的少数类型，那些带下划线的类型，是先于Trainz 数据模型在TS2009（即从 2008 年后期开始）发布时发生的更改的遗留类型，此后 N3V 程序员仅对这些类型进行了逐步（增量）更改。
目前可以在 N3V Trainz 维基的内容创建者指南部分中找到基于这些遗留类型修复资产的详细信息，此处为 TrainzOnline 网站，其中有启发性的遗留类型的示例。强烈建议Trainz 下载站的用户或任何想要创建内容的用户阅读 CCG。了解旧内容定义方式的背景历史可以让我们对同类型数据的当前 TrainzOnline 覆盖范围进行对比和比较，因为这种过去与现在的对比通常会提供宝贵的见解，帮助修复、更改和定制资产。更重要的是，CCG 中的写作是由专业人员制作的，并且更加语义化——它通常会让你了解如果改变了某项内容，会带来哪些扩展的影响，而 Trainz 维基就没有提供这些内容。TrainzOnline 上发布的 CCG 是TC1&2/TC3 版本——这是自 1999 年Trainz问世以来，几个印刷小册子（追溯到 Trainz）的最后一个已发布版本；TC3 CCG 包含 TRS2004/TRS2006 和UTC 数据模型中更改的 Enginespecs 机车资产，需要进行适当的更新。
TBS 标准定义
[编辑源代码]这些标签和容器是标准定义，几乎可以在所有资源中找到。一些标签是可选的，内容创建者可以根据自己的选择来定义。标签是关键字，具有单个分配的 *键-值* 或容器，例如 *字符串数组* 或 '{' ... '}' 绑定封闭的标签-值对或子容器。（在 Trainz 配置文件中声明的所有内容都是成对的，即使 '{' ... '}' 也被视为 *一个 键-值*。）
- 容器是 *'键' 和 '键-值' 对的集合*，以及 *TBS 中的 '上层容器'（与缩略图容器中的子容器相反）通常以 '-table' 为后缀*。
| 类型 | "'字符串值'" |
| trainz-build | '浮点数', 1 位小数 |
| kuid | <Kuid 编码值> |
| 用户名 | 用户名 "'字符串值'" |
| 用户名-XX | 用户名-XX "'字符串值'" |
| 描述 | 描述 "'字符串值'" |
| 描述-XX | 描述-XX "'字符串值'" |
| kuid-table (容器) { 依赖项列表 |
一个键-值表，列出了此资源依赖的所有资源。 |
| obsolete-table (容器) { } |
kuid 列表，此资源替换了这些资源（使其过时） 通常为空（空）[注释 5] |
| string-table (容器) { } |
资源中使用的字符串和消息的键-值列表 通常为空，在路线和会话中比较大。 |
| string-table (容器[s]) { 非英语 语言文本 } |
翻译字符串列表 匹配到 必须的英语 string-table |
| category-region 标签 枚举 代码 | category-region "'字符串数组'" |
| category-class 标签 | category-class "'枚举 字符串值'" |
| category-era 标签 | category-era "'约束字符串数组'" 年代 |
| category-keyword "'字符串数组'" 最大长度为 64 字节 | category-keyword 标签 自然语言搜索关键字 (替换类型、区域) |
| custom-category-list "'字符串数组'" |
脚本接口功能 |
| must-have-product-rights "'字符串值'" |
DRM 字符串数组 |
| must-not-have-product-rights "'字符串值'" |
DRM 字符串数组 |
| privileges (容器) { } |
更多 DRM |
| thumbnails (容器) { } |
缩略图容器 |
| script (文件名) | "'字符串值'" |
| class (脚本资源类) | "'字符串值'"，必须与 script 规范类同步。 |
| script-include-table { } |
(包含库脚本的容器) |
| extensions (容器) { } |
资源也使用的正式脚本扩展 |
| license "'字符串值'" | 资源创建者的版权声明 |
| author | "身份 '字符串值'" |
| organisation | "第三方组身份 '字符串值'" |
| contact-email | "电子邮件地址 '字符串值'" |
| contact-website | "作者/组的网站 URL '字符串值'" |
| member-of-groups (容器) { } |
此资源所属的 KIND 资源组 资源列表。 |
TrainzBaseSpec 在 config.txt 文件 中支持以下标签。 ∅:
- 类型：字符串。
- 字段定义：此 config.txt 文件 代表的资源类型。请参阅索引 类型 和列表：此处（上面）
- KUID
- 'Koolthingz Unique IDentifier'. Trainz 系统软件的 *资源的唯一数据库引用号*，在 KUID2 形式中也扩展到跟踪多个版本。Trainz 可升级性和资源模块化设计的核心，因为每个资源都有其唯一的 kuid 代码，因此可以指定另一个组件（转向架）或整个火车车厢，并在新资源（重新蒙皮或修改的卡车）中选择性地替换其中任何一个。
- 基本 KUID 格式：'<kuid:wwwwww:xxxxxx>'，其中 wwwwww 是 *作者* 的 '唯一 Trainz 身份'，xxxxxx 代表作者分配的 模型识别代码。
 |
|
- 大多数 Trainz 资源在其 kuid-table 中指定依赖项列表，这些依赖项是软件套件的各个部分组装在一起的，以便在 kuid-table 容器 中组成一个可渲染和可用的资源。
- 在许多资源的核心，特定的标签可能由 *kuid 引用定义，并使用引用的资源作为一部分。这实际上是如何实现重新蒙皮的，并且可以将网格用于资源，尽管更现代的做法建议将此类引用设置为网格库资源。
- KUID2
- KUID 格式的更新和更新跟踪修改版本，它允许指定版本号。
<kuid:xxx:yyy>与说<kuid2:xxx:yyy:0>相同（零修订或版本零，表示原始版本）- 这使数据项（Trainz 资源）能够为资源携带一个固有的版本代码。这通常不会与 CM Trainz-build 代码 相匹配，该代码标识了软件技术级别，但表示以前的版本历史记录。
- 如果数据库中存在两个资源，则具有较高后缀代码的 KUID2 资源将覆盖或替换较旧的资源。拥有早期版本不是必需的，但 CM 会将缺少的修订链列为缺少的依赖项，对于那些厌恶 CM 中该功能污染的人来说这是一个软件错误，或者说是程序员保留的 '功能'，无论如何都会降低使用 CM 识别用户缺少什么的功能，并导致用户花费时间手动找出实际情况是什么。
- 主要范围：trainz-build 标签，缩写：TB & TBV (TB-value)∅
- 类型：N3V[2] 使用一个十进制浮点数 枚举 来跟踪和识别与演化软件的技术级别相对应的数据类型。
- 范围： 1.0–4.3 直接对应（映射到3rd' Trainz 1.0—TANE-SP1+hf2；此值预计将随着每次新的主要软件升级而增加 0.1。
每个合法值必须与已发布的 Trainz 版本号完全匹配，以下情况除外
- 分配给 V1.4 的 TBV 或版本值是 Auran 的 Paintshed 版本，它是一种适用于 Microsoft Trainz Simulator (MSTS) 的重制工具，也作为 TRS2004 辅助软件模块的构建值出现；具体来说，它是 ContentManager.exe 实用程序。
- 1.7 和 2.0 之间的差距可能是外语版本，或者正如经过几个小时的挖掘和研究后发现的那样，Auran 没有使用它，因为在构建最初的 Trainz 的程序员团队看来，TRS2004 版本是第二个 Trainz 产品，无论前台如何宣传营销名称（比如 Trainz UTC，是终极的什么…… 真的吗？ 来吧，伙计！ 真的吗！？）
Trainz 版本和相应的 Trainz-build 标签 值序列是 Trainz 1.0=v1.0，Trainz 1+SP1 ⇒ V1.1，Trainz 1.0+SP2 ⇒ V1.2，Trainz 1+SP3 ⇒ V1.3，等等（但跳过 1.4 & 1.7–1.9），所以 TRS2004-SP0 = v2.0 然后递增，其中每个从 2.0（TRS2004 无 Service Pack）到当前版本（v3.7 = TS12-SP1，v3.8 = Mac2，3.9=TANE-CE，4.0—4.3 以及之后？ 从 2016 年 3 月起，4.3 及以上版本是 TANE SPs TBDL）。
- 从 v2.0 (TRS2004) 开始，Trainz-build 标签数值已经通过 23 个步骤增加，这些步骤是连续的，虽然不是单调的，因为 Trainz TS09-sp3—TS09-sp4 共享一些 Trainz-build[2] 值；也就是说，在 TS2009 和 TS2010 的联合开发时期和发布中，有一些 TBV 重叠。
- 此外，N3V 进入 Macintosh 计算机领域，打断了 Windows 基于 Trainz 版本的 TBV 3.4、3.5、3.6、3.7 & 3.8 在 Windows 和 Mac 操作系统之间的顺利递增。
注意： 热修复 不会更改版本号。
- 字段定义： 此资产构建（和归档）到的文件格式版本，不一定与资产使用的技术级别有关，但对应于在 Content Creator Plus 中创建资产时分配的资产级别 - 与在 CM 的标题栏中找到的级别相同。
- 程序员建议此数字通常应设置为正在创建和测试资产的 Trainz 安装的 Trainz 版本号。相反，Content Creator 社区试图将数字设置得尽可能低，以便在下载时为新资产提供尽可能广泛的受众/用户范围。更好的内容创作者将在相应的版本的裸机安装（没有添加内容）上对其进行测试，并验证生成的 cdp 是否包含所有相关材料。
- 某些资产类型根据其 trainz-build 版本标签的解析方式有很大不同。注意：trainz-build 标签 是强制性的。如果未指定，Trainz 将根据 config.txt_file 的内容尝试猜测旧的 Trainz 版本，这通常会解析为 TBV 的值为 1.3。
用户名标签
[edit | edit source]- 类型： UTF-8 字符串，资产的用户名，强制规范。
- 字段定义： 此资产的英文人类可见名称。
在 TC1&2（v2.7）之后的 trainz-builds 中，用户名在编辑资产时也成为操作系统文件夹名称，并且资产文件名被忽略，而它在 v2-6 配置文件中的优先级更高。根据 N3V games 的 TBS 标准，此字段绝不包含非英文文本，除非资产名称是专有名词（例如，地名）并且没有英文本地化变体。此值是每个人通常搜索和记住的数据，因此建议保持清晰的名称。
 |
|
用户名-XX 标签
[edit | edit source]- 类型： UTF-8 字符串，用户名标签 的替代语言版本。
- 字段定义：（其中XX 被替换为表示语言的相应 本地化代码。）此资产的本地化人类可见名称。此字段类似于用户名字段，但表示非英语区域设置。资产中可能存在多个用户名-XX 标签，每个支持的区域设置一个。如果不存在适当的“用户名-XX”标签来在给定的最终用户系统上表示此资产，则使用英文用户名标签。
描述标签
[edit | edit source]- 类型： UTF-8 多行字符串，提供资产的清晰语言描述。
- 字段定义： 此资产的英文人类可见描述性摘要。
描述在 Content Manager 的“资产详细信息”窗格中可见，用于阐明资产名称，提供规格，以及通常的一些历史信息。
N3V 的 Chris Bergmann 表示，此字段应保持简短（1-2 段）描述资产，扩展的详细信息应通过info-url 页面提供，但可以容忍相当长的文本块。有些人使用块的底部作为版本更改记录。
此字段必须包含英文描述性文本，虽然文本可以引用非英文专有名词，如其他地方所述。其他语言翻译或源文本应放在许多可能的替代语言本地化标签之一中（参见 description-xx 标签）。
description-XX 标签
[edit | edit source]- 类型： UTF-8 多行字符串，描述标签。
- 字段定义：（其中XX 被替换为表示语言的相应 本地化代码。）此资产的本地化人类可见描述性摘要。此字段类似于描述字段，但表示非英语区域设置。资产中可能存在多个description-XX 标签，每个支持的区域设置一个。如果不存在适当的“description-XX”标签来在给定的最终用户系统上表示此资产，则使用英文描述标签。
字符串表容器
[edit | edit source]- 类型： UTF-8 字符串列表容器，字符串表容器(s)。
- 字段定义： 一个键值对的英文字符串列表。每个键是一个有意义的脚本标识符，映射到二进制数据并被其引用。每个值都是一个英文字符串。英文字符串可能包含或引用非英语专有名词作为标识符。非英语母语作者制作的资源，如果需要，仍然必须创建一个没有后缀的字符串表容器。软件只链接并引用字符串表容器中没有后缀的名称和值，这将让西班牙语、法语、德语、捷克语、荷兰语…日语作者感到很不舒服。换句话说，带后缀的字符串表仅仅是为了翻译目的，当地图用非英语编写时，就会出现问题——没有 string-table-en 来提供反向翻译的表格。同样，username-en 和 description-en 也是如此。这三者的缺失都体现了一种过时且傲慢的无视世界动态的态度。
其他语言由类似的字符串表（例如 string-table-XX）支持，其本地化代码后缀 (XX) 与 description 和 username 关键字/标签的国际化后缀相匹配，但这些语言键控的字符串表容器始终在左侧条目中具有相同的键值。
- 这些左侧的键或标签既充当"本地索引关键字"，也充当"语言之间的等价表"。
- 左侧列始终包含内容创建者赋予“特殊”名称的对象，例如信号、轨道标记和行业、连接点等的名称，这些名称可能会被引用，并且会出现在 Driver 和 Surveyor 模块的“查找工具”(CTRL+F ) 函数小程序中。
- 另一方面，索引侧也不会列出默认的场所名称，例如在构建路线图时，由随机数自动索引的无数连接点（即毫无意义的杂乱信息。如果重要，路线构建 CC 会命名它！），但会自动包含可能临时的资源，例如火车车的默认名称。如果重命名，这些名称将取代其对应的默认名称。
- 它的主要用途是那些旨在与脚本引用交互并获取可变属性的对象，例如火车站、行业所需的或准备装运的产品数量，或者由交互式火车车（滚动行业到脚本）和其他可配置资源（像一个通用的广告牌式标志，通过一点高度调整和角度扭矩，可以放置在库存建筑或行业的正面，以在建筑上放置不同的商业名称）运送的货物，换句话说，是有点可配置的场景。
- 总的来说，在路线图或布局中，这些左侧名称对应于地图资源上的命名对象，这也是大多数字符串表出现的地方（从字面上看，在一个大型路线kind map中，有成千上万的条目）。
- 在某些资源中，默认名称连接到软件脚本中，因此字符串表变得特别重要，而不是平淡无奇。（见下文）
- 在每种类型的资源中，使用字符串表类型都是合法的，就像 description 标签、trainz-build 和 kind 标签一样。与这些不同的是，它不需要存在或定义，并且绝不是强制性的。除非代码期望它们的结合，否则封装在字符串表容器中的值没有任何功能或效果。
- 在其他资源中，再次以假设的可编程商业标志为例，如果要与软件交互，字符串表必须有一个默认名称。所有地图可放置资源都可以命名或重命名，但“特殊名称”必须与脚本和字符串表索引值匹配。大多数可配置资源定义了一个接口变量，用于替换默认名称作为脚本和资源二进制数据引用的索引或查找表。其他变量也可能在可编程资源中定义。这些都可能被脚本引用，但正是索引值使其进入了地图或会话字符串表，从而使一切在需要 Driver 或会话创建者可变性时协同工作。
- 相反，如果没有系统软件知道索引中命名项目的的位置，对象的脚本可能不会触发，不会进行条件检查，也没有被更新的能力。这是 2000 年代 Trainz 1.0 中对象的特征，而不是 2003 年发布的 TRS2004 之后的现代 Trainz 铁路模拟器。（从那时起，我们已经走过了很长一段路！）
- 有一些资源只能作为一个组一起工作。在这样的资源中，在地图或会话层中命名每一个资源使它们能够一起工作。例如，考虑一个有五个轨道的公路平交道，其中两个轨道不在连接点，并形成所谓的“交叉道”，与直线轨道交叉。如何设置信号，以便任何铁路交通都关闭公路闸门，或者在使用交叉道时，不允许其他火车通过正在穿越交叉道的火车。道路和铁路信号、道岔和闸门都必须协同工作。由字符串表结合在一起的某些“ATLS 系统”资源及其脚本可以使这个复杂的系统发挥作用。
- 有关更多信息，请参见 string-table-XX。
string-table-XX 容器
[edit | edit source]- 类型： UTF-8 字符串列表容器，即本地化的字符串表，每个后缀对应除英语以外的其他语言。
- 字段定义：（其中XX被适当的本地化代码替换，用于表示正在使用的语言。）此字段类似于string-table字段，但表示非英语语言环境。
英文字符串表（没有后缀）是强制性的，其他本地化语言在资源作者的意愿下是可选的。许多提交到 DLS 并在 Trainz 版本附带的路线中使用的资源通常会被翻译，并有一套完整的本地化翻译，用于 description-XX 和字符串表。特别是，与版本捆绑在一起的路线和会话在每个零售版本中都会进行专业翻译成多种语言。
请注意，字符串表的左列是相同的，因为它是一个映射的符号表，并且是网格、会话或路线文件等二进制数据的索引。只有使用名称，即两个元素的右侧或数据元素，才会被本地化并被运行时本地化软件替换。如果需要，这些可以使用户友好的名称手动编辑，即使在英文字符串表中也是如此。索引或左侧引用列的语法不得以任何方式更改，因此在更改数据列中的名称时，请注意全局 SAR 规范。
一个资源中可能存在多个string-table-XX标签，每个标签对应一种支持的语言。每个标签都应该包含一个字符串列表，该列表与string-table列表中的键相同，但值不同。如果在给定的最终用户系统上没有相应的“string-table-XX”标签来表示这个资源，或者相应的字符串在该列表中缺失，那么将引用英文string-table容器。
kuid-table 容器
[edit | edit source]kuid-table {
numberit_library <kuid2:75134:99003:7>
0 <kuid:-3:10164>
1 <kuid:-1:42004201>
2 <kuid2:50567:11155:1>
3 <kuid2:58422:50120:1>
4 <kuid:-3:10003>
5 <kuid2:30671:94407101:1>
6 <kuid2:87907:94407101:1>
7 <kuid2:87907:94407103:1>
8 <kuid2:87907:94407105:1>
9 <kuid2:30671:9870190:1>
10 <kuid2:30671:94407100:1>
11 <kuid2:87907:94407100:1>
12 <kuid2:87907:94407102:1>
13 <kuid2:87907:94407104:1>
14 <kuid:-3:10013>
15 <kuid2:60318:10008:1>
16 <kuid2:60318:10010:2>
17 <kuid2:189041:301:1>
18 <kuid2:50567:11121:1>
19 <kuid2:30671:9840820:1>
20 <kuid2:30671:9870899:1>
21 <kuid2:50567:12646:3>
22 <kuid2:124017:30000:2>
23 <kuid2:124017:30001:2>
24 <kuid2:124017:30002:2>
25 <kuid2:124017:30003:2>
lodi_icon <kuid2:124017:35000:1>
lodi_lib <kuid2:124017:40000:1>
26 <kuid2:30671:69006:1>
27 <kuid2:124017:35000:1>
28 <kuid2:30671:90810901:1>
29 <kuid2:30671:9081290:1>
30 <kuid2:60318:10009:1>
}
- 通常
- 只有具有子组件或备选选择（货物）的资源才会有一个具有相当长度的 kuid-table。大多数具有子组件的资源只有几个。
- 其次，由于内部关键字有时是“自动定义”的，仅仅列出为一个没有名称的数字，作为占位符参数，伪关键字可以是任何唯一值（通常，零索引的连续整数。[notes 1]）它们可以被命名，也可以不被命名，这取决于用户或作者的喜好。
- 此表中的条目有两个目的
首先：确保游戏系统知道依赖关系，以便安装和加载此资源能够成功地安装和加载任何依赖关系，以及
其次：允许脚本定位相关的子资源。 - kuid-table 中只包含第一层依赖关系——具有自身依赖关系的子资源或部件资源将在该子资源的验证和数据库提交过程中处理。
- 循环依赖关系是非法的。
- 如果一个资源被标记为此资源的过时版本，则该资源不能被列为依赖关系。（在 Trainz 资源索引（历史上是 assets.tdx 文件）中，kuid 中只有一个替换 kuid 插槽，这将创建一个循环定义，需要它自己的旧版本！）
- 同样，一个资源不能被列为它自己的依赖关系。[另一方面，这已经成为现实（即，在 TSxx CMs 中，见证了一个成功提交的无故障资源），将地图和会话移植到安装之间，使用 GSARS 来更改 kuid，以便重叠不会覆盖已经在目标安装上使用相同 kuid 的资源，而不会出现错误消息。]它是否也起作用，需要一个比我更勇敢或更愚蠢的人！--Fabartus，编辑。
- 格式(所有值都为 <kuid:aaaaa.bbbbb> 格式)
kuid-table {
0 Kuid-1
1 Kuid-2
3 Kuid-3
... kuid-ii
N-1 Kuid-N
}
|
|
- 利用这些虚拟参数的一个非常实用的方式是将复杂机车车辆资产中产品的KUID进行配对。一辆箱车可能包含各种各样的产品...获得许可，将您的作者ID分配到您自己的带有不同货物集的系列中，可能是您进行重大内容创作的第一步！考虑一辆货车，允许的产品容器，KUID列表可能包含以下条目
... {
Animal_chickens <kuid:-25:230>
Animal_Horses <kuid:-25:236>
Animal_Cows <kuid:-25:239>
Animal_Piggies <kuid:-25:238>
Animal_Sheep_Flock <kuid:-25:240>
} ...
注意连接单词的下划线...两个符号，键和值！我们将如何将KUID添加到货物和允许的产品队列表条目中留给学生来解决。（欢迎您，但这是一个更改名称的好理由！保持事情井井有条几乎是制作资产的全部战斗！）
- 类型：KUID 列表容器，与KUID 表容器格式相同。
- 字段定义：一个 '占位符键—键值' 资产列表，这些资产被此资产所弃用。任何尝试加载此列表中的任何资产都会导致加载此资产。
- 此外：两个资产都标记第三个资产为弃用是非法的，除非两个资产中的一个也标记另一个为弃用。[注释 6]
- 循环弃用引用是非法的。
- 此资产的所有低编号 KUID2 版本都隐含为弃用，无需包含在此列表中。同时，更高 Kuid2 的更新改进资产和它的一个前任永远不应该将同一个前任（例如原始的！）列入 '中间' 中间前任的列表中—因为这些值被用作替换条目表，并且只有一个资产可以替换较早版本。（数组只保存一个值，而且不能用两个替换一个！）
- 标记此资产的更高编号 KUID2 版本为弃用是非法的，因为这会创建一个隐式循环引用。
- 此列表中引用的资产必须与此资产具有相同的创建者，才能通过 DLS 上传过程进行审查和接受，此限制不适用于您的本地版本，例如，它可以用来用一个图形更美观、更新的资产来替换大量货车上的所有旧纸轮 KUID。
- 用途：CM 和 Surveyor 中的过滤器（搜索条件）
- 类型：枚举字符串或字符串数组。
- 字段定义：一个由分号 (';') 分隔的双字符category-region 标签 代码列表。字符串中不应包含其他字符（包括空格等）。此资产被认为与每个指定的区域相关—这与kind 货车 和kind mosignal 资产最相关，但可以为任何资产提供。
- 示例
- category-region "CA;US"
- category-region "CA;MX;US"（北美国家，加拿大、墨西哥、美国）
- category-region "CA;CS;DE;MX;US;VE;AU;FR;IN;IT;JP;KR;ES;AR;AT;BE;CH;DK;IE;EE;NL; NO;NZ;PA;PL;PR;PT;RO;RU;SE;SK;UA;UK"（大多数第一世界国家）
- 用途：CM 和 Surveyor 中的过滤器（搜索条件）；根据 KIND 声明确定 CM 软件如何处理资产，以及 Surveyor 在哪里列出它。
- 类型：枚举字符串。
- 字段定义：一个单一的 2-3 字符category-class 代码，用于描述此内容项。category-class 标签用于提供超出资产类型隐含内容的人工细分。每个 Trainz 资产的 category-class 标签有助于描述资产在游戏中的 '意图'，而不是资产的内部结构。
|
|
请注意，许多 category-class 代码只与特定的资产类型相关—category-class 代码不应应用于不合适的资产类型。
- 示例
| category-class "XBG" | 箱车—来自 PRR 60' | |
| category-class "BR" | 铁路（非功能性风景）—可能是一栋建筑 | |
| category-class "BIN" | 具有产品处理功能的工业资产 |
- 每个时代代码代表一个十年，由一个四位数的整数组成，然后必须是 's' 结尾
(例如 "1990s;2000s;2010s"),从而创建一个枚举软件标记（值），它必须与指定的合法时代代码 之一完全匹配。 - 字符串中不应包含其他字符（包括空格等），包括（尤其是在字符串末尾）在终止双引号字符之前。
- 允许的年份范围是 1800-2010s[注释 7]
- 此资产的唯一意义是对于其他人来说，即此资产被认为是在指定的时代范围内有效且适当的相关，并且Content Manager 将接受指定适用年份的搜索过滤器。
- 示例
category-era "1920s;1930s;1940s;1950s"
- 用途：CM 和 Surveyor 中的过滤器（搜索条件）
- 类型：缩略图容器。
- 字段定义：在整个游戏环境（包括游戏中、在Content Manager 中以及在Download Station 上）中用于在 2D 预览框、列表和图标形式中表示此资产的缩略图。每个数据集都包含在子容器中（通常）使用占位符参数 作为键名或标签。[注释 8] 惯例使这些 0 索引的整数，但值可以是任何可以评估为字符串 的非空文本值。（参见下面的第二个示例）
- 一个实际示例
- （来自资产修复编辑[3]）
thumbnails {
0 {
width 240
height 180
image "$Screenshot (240)(kuid 68787 25222).jpg"
}
1 {
width 512
height 512
image "$Screenshot (512)(kuid 68787 25222).jpg"
}
}
另一个常用尺寸是 128x64 '图标'，它用于Railyard 和测绘师资产选择 API 中，应该有一个Alphamask 或一个非常浅的背景。许多旧的没有使用 jpg 文件，而是列出了 .tga 文件（Targa True Color）在一个 '_art' 子文件夹中（Trainz 1.0—TC3 约定：_art、_body 和 _shadow 是三个由早期 Trainz 数据模型要求命名的子文件夹，名为 'asset-filename_suffix'（过时的标签—<值> 对），如下所示[注释 9]
thumbnails
{
Icons
{
width 128
height 64
image "40ft_boxcar_art\40ft_boxcar_art_icon.texture"
}
CM
{
width 240
height 180
image "$screenshot PRR 40ft_boxcar (240).jpg"
}
DLS1
{
width 512
height 512
image "40ft_boxcar_art\40ft_boxcar_art_512.texture"
}
DLS2
{
width 512
height 512
image "$screenshot PRR 40ft_boxcar (512).jpg"
}
}
在 TS2009 和 TS2010 的早期版本中，没有适当的缩略图容器的资产被标记为有缺陷。补丁后来将这些标记为警告。[注释 10] 这种做法在 TS12 修补程序中被放弃，此前用户社区对此提出了许多抱怨。
• 如果缺少缩略图容器的资产（即使有旧的缩略图标签）后来在新的内置路线或会话中被选择，该资产通常将作为没有图像的项目进行分发——如果纹理 .txt 或 config.txt 缩略图容器未正确引用，它们将被剥离[注 11]。
- 类型： URL 字符串。
- 字段定义：指向资产在线描述、资产说明（帮助）或 TrainzOnline Wiki 上其他帮助页面的链接，旨在从嵌入式专用 N3V 浏览器中使用。该 URL 必须解析到 Trainz Online 安全区域 内的站点。目前，嵌入式浏览器接受三个域
auran.com
ts2009.com
ts2010.com
此外，不直接链接到这些域，而是使用自定义的 Trainz 短 URL 格式，以防范将来可能发生的站点布局更改。'短 URL' 是 Trainz 特定的 URL，有助于将来保护内容，允许内容创建者引用 N3V 网站上的某些页面，而无需依赖于特定的 Web 布局。短 URL 旨在用于游戏内使用，例如 info-url 链接，并且仅在嵌入式 Web 浏览器中有效，在任何外部 Web 浏览器中均无效。在存在此标签的情况下，游戏内按钮允许用户查看资产描述或帮助，而无需离开游戏环境。
这在 Driver 中对于访问路线图、指南或会话说明或澄清可能非常有价值。
建议在任何情况下，对于提供类似功能但外观略有不同的资产类别，都使用通用组页面。这减少了创建、维护和本地化此类文档的时间成本。
- 类型： ASCII 字符串。
- 字段定义：所需产品权利的列表，以分号 (;) 分隔。如果本地安装没有所需的产品权利，则某些游戏系统可能无法加载该资产。
- 类型： ASCII 字符串。
- 字段定义：冲突产品权利的列表，以分号 (;) 分隔。如果本地安装具有列出的产品权利之一，则某些游戏系统可能无法加载该资产。
- 类型：特权容器 是某些作者使用的 DRM，版权保护实现，也可以称为特权 DRM 容器。DRM 代表数字版权管理，这就是它实现的内容。如果已定义，某些参数甚至会阻止查看 config.txt 文件 以获取资产。
- 字段定义：由资产创建者设置的一组特权，用于控制如何操作此资产。
privileges {
is-payware-content 0
permit-listing 1
permit-edit 1
permit-commit 1
}
上面的容器使用默认值设置，这意味着
- 0) 这不是付费软件，因此其他字段具有相关性 [当付费软件编辑和提交为零时，但允许列出]；
允许
- 1) 查看资产的 config.txt 文件，
- 2) 编辑资产，包括查看其主文件夹中组件文件的内容，
- 3) 将对资产的任何更改重新保存（将重新验证的资产提交（提交）到数据库）。
- 类型： 字符串文件名。
- 字段定义：指示此资产的主脚本文件的路径，如果有。此路径应始终以 ".gs" 扩展名结尾 - 运行时将尝试添加或替换 ".gs" 扩展名，如果路径具有其他扩展名。
- 类型：字符串。
- 字段定义：指示要加载的脚本类名称，作为此资产的主类，如果有。此类从此资产的主脚本文件加载。
- 类型： KUID 参数列表及其相应的名称作为键。
- 字段定义：脚本资产的键值表，在编译此资产的脚本文件时，将搜索这些脚本资产以进行脚本包含。键（变量，因此不是标签）目前未被使用，但必须是唯一的；值表示要包含的资产的 KUID。
script-include-table 容器 是顶级 config.txt 文件 条目，可用于任何从 KIND TrainzBaseSpec 派生的资产（简而言之，所有资产）。此容器允许资产直接 包含另一个资产的脚本 来自父资产的脚本文件，使用 N3V TrainzScript 的 Script_Include_Directive。
- 相关
扩展容器是具有特定命名约定的自定义标签或子容器的列表。
此容器是脚本资产名称及其 KUID 的简单键值表，在编译资产的脚本文件时，将搜索这些脚本资产以进行脚本包含。键或标签名称当前未使用（即为 占位符参数）进行搜索；值表示要包含的资产的 KUID。能够搜索和识别键名是内容创建者请求的功能，因此建议使用脚本文件名而不是数字虚拟标签名作为最佳实践，因为它比 KUID 引用传达的信息更多。
通常最好将此类引用限制为 KIND 库 资产，但这并非强制性的，任何资产都可以被引用。
script-include-table {
a-key <kuid:nnnn:nnnnn>
enginespec <kuid2:www:xxxxx:yy>
anim-doors <kuid:tttt:uuuuuu>
}
- 类型：扩展容器。
- 字段定义：一组扩展属性，为脚本提供了超出Config.txt 文件 为此资产类型定义的规范的额外信息。 创建新扩展时，应注意遵守扩展命名准则；提供现有扩展数据的时，应注意遵守扩展创建者的准则。Auran 保留根据扩展创建者的准则，在稍后日期为扩展容器 中特定条目添加验证的权利。
以下关键词是相对较新的开发，在较旧的资产中不会有类似物或存在。
- 类型：UTF-8 字符串。
- 字段定义：用分号 (;) 分隔的自然语言关键词列表。字符串中不应存在其他字符（包括空格或不相关的标点符号）。这些关键词构成了资产关键词搜索的基础。资产的用户名 不需要在category-keyword 列表中重复。
- 根据资产类型（KIND+category-class），会自动提供各种默认搜索关键词，因此无需重复，可能也不应该重复。 Ø
- 标签可能不会作为空字符串 ("") 或标签后的空白存在——这些情况会生成错误。
- 明显的用途：公司，如 ATSF、Santa Fe 和 AT&SF、B&O、Chessie、CSX、NS、PRR 或 NYC 等，而诸如平板车、货车、料斗车等基本类型应该是自动的。桥接键，如凹陷式、井式车和侧卸式（换句话说，修饰词）应该用于增强自动关键词生成的有限智能。自动生成的术语的重复不应令人担忧。
{{anchor|custom-category-list container|自定义类别列表容器|custom-category-list 标签|自定义类别列表标签|custom-category-list 字符串|自定义类别列表字符串|自定义类别列表容器|custom-category-list 容器
- 类型：ascii 字符串数组容器。
- 字段定义：用分号 (;) 分隔的自定义类别标识符列表。每个自定义类别标识符 应该是一个简短的（例如 3-6 个字符）字母数字标记。字符串中不应存在其他字符（包括空格）。
- 这些自定义类别用于使脚本能够快速定位特定类别的资产。强烈建议谨慎引入新的自定义类别标识符。
- custom-category-list 标签值最多应包含 64 个字符。除非存在只能通过 custom-category-list 方法实现的现有特定脚本要求，否则应保留此标签为空。
- 最小版本：V3.5 及更高版本
- 类型：Member-of-groups 容器，配对 占位符参数 和 asset-group kuids 列表。
- 字段定义：此资产所属的KIND_Asset-group 资产列表。有关如何以及何时使用此功能的详细信息，请参阅kind KIND Asset-group 文档。
该容器包含 KIND Asset-group KUID 的常规列表。此包含是一个声明，声明此后，特别是在搜索操作中（包括脚本接口和 TrainzUtil），此资产将被视为每个列出的资产组的成员。
如果给定“member-of-groups”容器未指定任何条目，或者资产省略了“member-of-groups”容器，那么模拟器软件可能会根据资产的 Config.txt 文件指定一些默认资产组。确切的行为可能会在模拟器软件的不同版本之间发生变化，但是当前逻辑在此处进行了描述here。
- 以下标签对于任何资产来说从来都不是强制性的，而且很多资产会将其保留为空。
- 从历史角度来看，识别和许可标签从 Trainz 0.9（测试版）开始。
- 类型：UTF-8 多行字符串。（被程序员法令弃用。）
- 字段定义：许可证，描述了资产创建者希望如何使用此资产。最常见的是许可证声明，禁止在任何付费路线、依赖资产（例如转向架、耦合器等火车部件）或重制皮肤中使用版权资产，包括在任何付费运营的网站上分发该资产。（理论上，即使对于 DLS 也是如此。FCT 费用是为了更快地访问和无限下载，而不是为了访问资产。）
- DLS 上的大多数资产都是对 Creative Commons Share Alike with Attribution (CC-BY-SA) 的措辞不当的版本，例如本维基和其他的 Wikimedia 维基项目。
- license 标签的含义含糊不清，N3V 不建议使用它，但它的存在早于 N3V 的管理 6-7 年。
- 上传到下载站 或用于包含到游戏中的内容可能受到特定再发行合同或许可协议的约束，这些协议优先于此字段中的任何文本。license 字段不提供本地化支持。license 字段的文本不会被 Auran 或 N3V 验证或执行，并且可能对最终用户具有法律约束力，也可能没有。
- 另一方面，Planet Auran 的历史表明，有人通过将他人内容用作自己的内容来侵犯版权，可能会导致其从 Auran 网站迅速被禁止，并失去下载站权限等，从而永久封禁。此外，社区将对违反他人版权的其他用户采取强硬措施，并回避违反者，并忽略任何允许保留在 DLS 上的资产。
- 总之，尝试和更改资产是Trainzer 尝试攀登陡峭的内容创建学习曲线的一种公认甚至被允许的生活方式（每个人都希望有更多内容创建者！），但如果资产有依赖部件，尤其是网格、脚本、纹理，这些是知识产权——在你上传作品之前，请获得使用这些属于其他人的部件的许可。
|
|
- 类型：UTF-8 字符串。（已弃用，取而代之的是可更新的Planet Auran 数据库。）
- 字段定义：作者的姓名或标志。不建议使用此字段，因为归属可以通过编程方式确定。
- 注意英国拼写，“organization” 的北美拼写也适用！
- 类型： UTF-8 字符串。（已过时，建议使用可更新的 Planet Auran 数据库。）
- 字段定义： 负责创建此资产的组织的名称或标识。不建议使用此字段，因为归属可以通过程序确定。
- 类型： 字符串，电子邮件地址。（已过时，建议使用可更新的 Planet Auran 数据库。）
- 字段定义： 此资产创建者的联系电子邮件地址。不建议使用此字段，因为归属可以通过程序确定，并且联系信息可以注册到创建者的 Auran 账户 Planet Auran 账户，在那里可以对其进行限制或更新。
- 类型： URL 字符串。（已过时，建议使用可更新的 Planet Auran 数据库。）
- 字段定义： 此资产创建者的联系网站。不建议使用此字段，因为归属可以通过程序确定，并且 [联系信息] 可以注册到创建者的 Auran 账户 Planet Auran 账户，在那里可以对其进行限制或更新。
|
|
- 在最初的编译之后，在旧版本的数据模型中发现的一些常见但现在已过时的标签已添加在下面，例如在许多桥梁资产中发现的 bendy 及其朋友。
|
|
- asset-name、name 和 name-XX - V1.3–v2.8 - 在几乎所有 v1.3-v2.0 资产中都有历史记录。虽然“asset-name”一直保留着，没有引起任何抱怨，直到 v2.8，但在 v2.5 之后不鼓励使用；因此，在 v1.5 之后，资产的 config.txt 文件中唯一需要的、想要的或被认可的名称是 username-XX 变体。
Asset-name 是 Trainz 1.x--TRS2004 Trainz 时代资产的主要文件夹名称，并且通常是 CM 打开文件以供编辑时打开的文件夹的名称；在当今这样的早期数据模型资产中，通常会发现 asset-name 也用于早期 Trainz 时代的 data 子文件夹系统，在火车车厢资产中，其子文件夹名称为“asset-name_art”、“asset-name_body”、“asset-name_shadow”。在修复此类资产时，通常可以使用从资源文件复制粘贴的 SAR 来替换该值。这种替换通常会正确地定义和链接资产的子文件夹（用于车身、阴影和艺术品），因为在早期方案中，文件名基于 asset-name 标签。
- 范围： 在 轨道或桥梁资产 中发现，早于 v2.9 标准，当时样条线对象经历了重大变化，成为一个统一的数据模型定义，放弃了混合中的一些先前的 KIND，而所有样条线对象都统一在 kind track 下。
- 见上面的 bendy，已过时/废弃的 TS2009 之前的遗留 kind track 标签。
- 'name' 和 'name-XX' 是早期数据模型形式的较长的 username 和 username-XX 标签，XX 代表英文“name 标签”（或今天的“username 标签”）的非英语语言翻译的 ISO 双字母后缀；“XX”形式与 description-XX 一样，是“本地化”对其他语言的用户友好值的支持部分。
- 在最古老的 Trainz 时代 (v1.0-v2.4) 资产中，将 name 和 name-XX 替换为 username 和 username-XX，或者如果存在 username，则直接删除。
- 如果资产的 trainz-build 版本为 v2.7 或更高，则 name-XX 会导致错误。有趣的是，即使在 TS12 这样晚的版本中，name-XX 标签仍然显示在 Surveyor 工具的搜索列表中，如果不存在，则会出现 TrainzBaseSpec。
|
|
- 已被 category-era 标签 取代
- category-era-nn — V1.3–v2.8 s.a. {tag: category-era-0, category-era-1, category-era-2, ...} — 这是一个带有数字后缀的旧日期系统，在 TBV 2.0 之前几乎所有值得记录的资产中都有出现 (甚至在 TBV 2.8 构建的资产中也出现！)。当前的 category-era 字符串数组是在 TBV 2.0 引入的，将这些日期合并到一个 config.txt 行上[注释 12]。虽然在 Surveyor 中无法直接访问，但在 TR06 和 CMP 之后，可以定义一个筛选器来选择日期范围，并将该筛选器与区域和类型一起使用在 Surveyor 中来验证在 Surveyor 的放置和选择工具中可列出的资产。在 TS09 及其以后版本中被弃用，TS09 使用较短的 category-era 标签 字符串数组 放在一行中，而不是使用多个带有 '-nn' 后缀的标签-值对。
- 字符串数组中的空格会导致错误；所有值必须以 's' 结尾，并且具有四位数字，例如 1880s;1950s;2010s (这可能非常适合某些类型的女性服装，这些服装会随着时尚潮流而兴衰！)。定义一个范围目前尚不可行，但已得到用户社区的请求。
- 使用无空格的字符串数组类型 category-era 标签，并用分号分隔日期代码；这些代码以完整的四位数的十年为单位，并在后面加上 's' (小写 's') 后缀。
- 被 category-region 标签 替代。
- 类型 category-region-nn — V1.3–v2.8 — 历史悠久，几乎所有与地区相关的资产中都有出现。这些已被 category-region 标签中 由两个字母组成的枚举 ISO 国家代码的 '字符串数组' 所取代。
- 使用无空格的字符串数组类型 category-region，并用分号分隔两个字符的国家代码，这些代码在引用的标签部分中枚举；这些代码由两个大写字母组成，表示 枚举 代码，并用 ';' 分隔，但在最后一个代码之前的末尾引号之前没有分隔符。
- 字符串数组中的任何 空格 都会导致读取错误和故障消息，包括结尾引号之前的空格。
- region — TBS V1.3–v2.8 中的有效部分，作为内置筛选器和地图资产自定义本地化标识符 (kuid)；现在唯一合法的标签使用是在 地图类型 (布局) 资产中。
- 作为以前的筛选器修饰符，该标签在历史上几乎所有资产中都有出现，但在滚动库存、场景、样条线资产、轨道类型 (包括隧道和桥梁) 和具有某种程度的本地化的轨道旁资产中尤为普遍。
- 地图资产仍然保留着关键字 Region，该关键字在 Map 配置中定义，但使用方式相反，即作为 区域类型 kuid 引用。因此，Region 在地图中是必需的，而且自从 TS2012 以来，与标签类型一样，它在大量的资产中是非法的，而这些资产曾经将它作为 TRS 系列版本 Surveyor 工具窗口中的 '分组数据' '快速筛选器'。
- 在 TRS2009 之后，任何将 region 标签设置为文本字符串的操作都已过时，因为在程序员看来，他们用 选择列表 替换了 Surveyor 工具中 '类型和区域' 字符串值的 粗略筛选 组选择器。这两个标签都有一些优点和缺点，并且都可以追溯到 Trainz 0.9 Beta 版本。
thumbnail 标签是 缩略图容器 的早期单视图实现 (如上所述，也有简要说明)。Trainz 的早期 N3V 之前的程序员版本会找到一个 .jpg 文件，最好大小为 240x180 像素，该文件位于主资产根文件夹或 asset-name_art 或 asset-name_body 文件夹中，并使用它在 CMP 和 DLS 中显示该资产 (如果上传的话)。该标签在 TRS2006 期间被弃用，因为缩略图容器在 v2.0 (TRS2004-SP0) 中引入。在较旧的已修复的资产中，如果 TBV 保持在 v2.4 以下，缩略图通常仍然可以在较新的 CM 中工作，前提是它位于 _art 子文件夹中，并且资产名称与用户名匹配。
- type — V1.3–v2.8 — 一个以前的筛选器修饰符，在历史上几乎所有资产中都有出现，但在滚动库存、场景、样条线、轨道类型 (包括隧道和桥梁) 和轨道旁资产中尤为普遍。
- 与 'region 标签' 一样，type 标签在 Trainz 0.9—TC3 版本中 用作 'Surveyor 中的组筛选器'，它与 region 相结合，可以提供更小的资产选择 (工具组)。自从 TS2009 移除这些本地可点击筛选器，取而代之的是一个新的、更繁琐的筛选器。这使得工具选择变得快捷和简单，而不是在工具选项卡之间切换时变得缓慢和暂停 — 如今的 TANE 之前的版本在工具选项卡之间来回切换时，往往会被重新加载整个选择列表所淹没。
- type 和 region 都默认为 'All'，与 TS09 及其以后版本中的工具提供相同的超长列表。
- ↑ 资产 提交 (TANE 中的提交) 是将内容整合到数据库中并将其在 DB 索引中交叉引用的过程和程序，以便在运行时模块中访问它。
- ↑ 验证资产的一种方法是，除了这些值之外，将 TBV 降低到 2.5-3.7 范围，看看这些消息是否消失。您可能需要多次降低 TBV 直到足够低，反之亦然，在较旧的 TBV 中无法识别的较新关键字可能会给出不同的错误消息。不要害怕尝试，即使失败，也会产生知识和经验，而且您不会破坏任何东西！如果这样，您可以确信，仅仅提供一个值就是解决问题的方案。通常，一些现代需求只需要关键字对，因此在标签后面添加一个空行，或者在标签后面添加一个空的括号集 (表示容器) 就可以满足需求，而错误测试则过于严格。
- ↑ 注意: 此列表在 N3V TrainzOnline Wiki 上被 '维基化'，这意味着在 'KIND' 这个词后面第一个字母被大写，而 config.txt 文件中的实际数据标签名称是 全部小写 文本。该维基还使用双引号来表示相当多的术语，我们将在本文中避免使用这种做法。
- ↑ 'kind consist' 并不经常直接出现，它只存在于菜单和内容管理器列表中。
- ↑ Obsolete-table 必须谨慎使用，最常出现在 Auran 制作的资产中。该表格将旧的 kuid 替换为新的 kuid，大多数内容创作者会正确使用 Kuid2 形式的 kuid 来取代旧版本。相比之下，N3V 过度使用 obsolete-table 来更新新发布的内置资产，这会导致很多混淆，无法获得预期结果。（例如，许多漂亮的 '翻转树' 在 TS10 和 TS12 中被淘汰，取而代之的是 Speedtrees，这影响了许多路线，因为创作者并不需要也不想要 Speedtrees。在不同的安装中，这也会导致依赖项丢失，直到找到包含 obsolete-table 的资产。
• 此外，Assets.tdx 数据库索引中每个 kuid 仅支持一个 obsolete 条目，用 Kuid2 版本替换 kuid 会导致问题（即您将看到哪个版本？）
• obsolete-table 的一个很好的用途是升级使用特定部件（尤其是转向架）的一系列资产。添加一些将被较新的转向架替换的 kuid 可以显著改善路线或场景的外观，只需进行一次编辑（前提是转向架（例如）兼容且尺寸合适！） - ↑ 最近将一个过时的资产引入 TANE 的经验表明，至少有五个备用 kuid 替换了那个可怜的 翻转树资产。随着 speedtrees 引入造成的混乱，以及 TANE 为了追求最更新的适当资产而进行的彻底改革，ContentManager 进程现在允许使用多个不同 kuid 的资产来替换相同的 kuid。作为良好的实践，只有在绝对必要时才使用 obsolete-table...例如，在您想上传到 DLS 或在网站上自行发布的依赖资产中替换一个不需要的付费资产。
- ↑ 关于类别时代标签范围：已知有效的安全做法。其他“未来十年”值应在依赖之前进行测试。
- ↑ 许多容器在列表中使用虚拟/占位符名称。这些可以是描述性词语，只要它们不包含空格。在短语构建的名称中使用下划线或句点可以保持可读性并显著提高清晰度。例如，一辆货运车厢可以承载 45 种合法产品类型。这些将在依赖项容器中列出。使用 Coal、granite、crushed_limestone 等可以更轻松地维护和更改表格。Jes Sayin'，自 1976 年起担任程序员
- ↑ 在第二个缩略图容器示例中，有一个第二个 512x512 大小的图像，即额外的图像。DLS 使用哪一个是未知的。还可以包含更大的图像尺寸，通过电子邮件聊天，T:ANE 可能支持更大的图像尺寸，这将在预览操作或 DLS 列表中找到用途。N3V Games 通常不会透露此类信息。
- ↑ 早期实践可以追溯到 Trainz 1.x，使用关键字/标签“thumb”和带引号的路径规范引用，指向 240x180 的缩略图图像，用于运行时菜单。艺术文件夹包含一个 512x512 的 tga，带有 Alpha 遮罩（通常是 bmp 文件，但正确格式的 tga 可以用作自 Alpha 遮罩），以及 64x128 的菜单图标图像及其控制纹理文件 texture.txt。
- ↑ 在 2014 年至 2015 年冬季与前版本经理 James Moody 进行的私人电子邮件对话中，关于该主题的重点是，DLS 上传验证软件可能已被更改，以强制执行适当的缩略图容器。
- ↑ 关于类别时代-nn 与类别时代标签值：' TRS 会接受两种形式的类别时代数据；但是 TS2009-SP0 及更高版本从以前合法的关键字-值对中创建了错误，并试图强迫内容创作者更改所有程序员故意破坏的资产。后来，DLS 上传软件强制执行了转换，但这要好得多，因为第一个操作使许多人浪费了数小时来修复不必要的错误，这些错误本应在验证旧的 trainz 构建资产时通过软件预筛选流程自动实施。这些操作实际上保证了旧的资产下载会有错误。这是 N3V 程序员所做过的最愚蠢、最傲慢的事情之一，而 Auran 更具经验的软件人员永远不会如此轻率地对待社区的时间成本。
参考文献
[edit | edit source]- 此页面的主体内容取自 N3V TrainzOnline Wiki，来自 KIND_TrainzBaseSpec。增强信息由 Yesterdayz-Trainz 用户组成员添加。
脚注
[edit | edit source]- ↑ N3V 的 KIND_TrainzBaseSpec，作为未经增强的源页面，缺少历史信息（标签），在此处找到；访问日期=2014 年夏季
- ↑ a b "Trainz-build" 标签 直接链接
- ↑ 根据 fabartus，2014 年夏季；很可能是在添加此示例的同一天。
- ↑ Christoph Bergman，N3V Games 首席程序员，又名 'Windwalkr'，KIND TrainzBaseSpec 历史 页面。
|
此参考页面改编自 TrainzOnline Wiki，根据 CC-BY-SA 3.0 许可。此页面可能包含比 同一主题的源页面 更多的文字解释、说明、历史和/或示例。 TrainzOnline Wiki 主要由程序员或了解情况的 内容创作者 维护，可能包含有关当前 trainz-build 代码 标准的更新信息，这些标准随着软件功能的添加而不断变化。 |