Trainz/refs/config.txt 文件
|
|||
|
这是对 Trainz ini 文件 类型（称为 config.txt 文件）的更技术性介绍。
- 要了解主题的介绍，请参阅：Trainz/Config.txt files，要了解一般基础知识，请参阅 Trainz/AM&C/config.txt files。
无论 Trainz 版本如何，特定版本 Trainz 数据模型 一直都有 KIND 数据容器，它位于 config.txt 文件中，并使用 kuid 标识符代码 作为 Trainz 内容项的最少中心描述需求。这使得特定资产文件夹中的 config.txt 文件成为任何给定资产的中心描述；为了使模型更紧密，配置文件在数据位于数据库内且不可编辑时定义了其所在文件夹的名称。
| 每个内容项在其文件夹中都有一个名为 config.txt 的定义文件，该文件确定资产的名称，识别其 种类 并指定项目的 KUID ID 代码，唯一地允许从资产到资产或到运行时软件的数据匹配和引用。每个配置文件根据资产 KIND 还会保存各种 KIND 特定的详细信息，这些信息定义了该资产以及允许在使用同一资产的多个副本运行 GUI 时出现多次的任何键（实例）。（树木、火车车厢、房屋等——其中许多都通过脚本影响进行半定制，例如随机车厢编号、替代皮肤、标签和其他会话编写者定义的功能。） |
config.txt 文件（在很大程度上，所有格式化为文本的 Trainz 文件类型）存储在 ACS 文本格式 中，简而言之，它定义了关键字和值对。某些关键字是聚合值，在 Trainz 中，它们对应于 容器，该容器保存着此类数据对和其他容器的列表。
- 手动编辑文件时，必须小心使用正确的语法，否则文件的部分或全部内容可能会永久丢失。当内容安装到 Trainz 中，或将其归档（以 CDP 格式 或类似的 .cdpa 文件格式）时，config.txt 文件将以机器优化的二进制格式存储。如果内容随后使用 内容管理器 提取，config.txt 文件将转换回文本格式，但是任何自定义格式或错误的语法都已经丢失，无法恢复。
- 主要文章：TrainzBaseSpec
Trainz 数字模型基于数据定义，所有数据定义都遵循一种格式，其中 枚举的 标签关键字 位于一行首，后面紧跟着同一行上的数据对。在某些更复杂的数据允许的情况下，数据元素只是开始——一个引号标记数据或一个开括号 '{'，它标记其他特定关键字——数据对。即使是复杂的容器，其中一些包含子容器，也遵循这种强制格式。从这个意义上讲，容器和子容器都包含一个标签和一个值，这些标签和值被匹配的括号括起来，这是一种从 C 编程语言借来的约定。
请注意，这种复杂的数据定义在子程序数据处理级别很合理，因为一旦识别出标签，它就会用于选择适当的处理 子程序（在计算中，Handler 例程），该子程序输入该行的其余部分（或几行），知道如何解释第一个 '{'（或引号标记）之后的包含数据，直到遇到 匹配的闭括号 '}'（或结束引号 '")。该 Kinds 数据子类型定义了该资产在游戏引擎内正确渲染所需的唯一对。 相反，各种标签和容器对所有 Trainz 内容定义种类都是合法的，在该种类资产的 config.txt 文件中合法，无论特定资产类型如何。为了方便起见，自 TS2009 发布和 TrainzOnline Wiki 的诞生以来，这组数据关键字和通常强制数据定义被称为Trainz 基本规范 (TBS)，在程序员的 (驼峰式命名法) 行话 中成为TrainzBaseSpec 规范——一个始终合法的标签、容器及其必要定义列表。
• 合法性不涉及您当地的法律机构，而是内容管理器和 DLS 错误检查软件例程核心中的警察。如果标签-值对超出上下文，例如在容器边界之外放置子容器标签，或者不合适，那么“警察”将生成故障消息和投诉（“起诉书！”），并将资产标记为故障... 使其不可用，直到修复（至少在以后的 Trainz 版本中——早期版本更宽容）。因此，各种配置文件标签，包括必需标签和可选标签，都从 kind trainzbasespec 基本资产类型继承，并在那里详细描述。这些值类型是
标签 或单独的行首词是 '关键字'，并具有 单个分配的 '键值' ，格式正确的容器数据结构，或者有时该键值需要组织为引号字符串数组（实际上，是该特定标签类型定义的参数的容器），通常是受限的编码值（枚举列表成员），引号标记之间用分号隔开，定义单个字符串（字符串值）对于该标签。（示例："CA;MX;US" 是一个 category-region 定义，涵盖整个北美——加拿大、墨西哥和美国。
容器 是关键字和键值对以及可能的子容器的集合。上层容器（与子容器相反，例如缩略图容器中的子容器）是 KIND 规范（包括 KIND TBS）的一部分，并且是高使用容器，尤其是那些可能接受可变数量的子容器元素的容器，例如 mesh-table 容器 通常以“-table”结尾。
最后，但最重要的是，有各种类型（参见下面的第二个表格或 TBS 中的列表），每个配置文件都需要一个，并且定义了其他关键字，包括必填和可选这些是满足该类型资产定义所需的。因此，每个类型数据组都扩展了必需和可选的参数，标签和容器，这些参数必须在该 config.txt 文件中详细定义，以便正确地将所有用于创建数字模型（Trainz 资产）的元素组合在一起。请注意，类型是定义其他容器和其他特定标签的容器，这些标签必须满足定义才能使内容管理器的错误检查接受（并提交）资产到数据库中。如果数字模型不在数据库中，则内容创建者无法在制作场景或地图时显示和使用它。
- 下表正式称为'Trainz 基本规范' 或 TrainzBaseSpec (TBS). TBS 包含 Trainz 数据模型规范的关键字和键值对，这些规范可能在任何资产中找到。其他标签和值由种类标签的值定义，该值列在种类表中。
- 在缺少此类标签的 config.txt 文件中添加任何一个此类标签，只要您的语法（键入和拼写）正确，就不会出现问题。
- 后缀为 -XX 的标签是支持多种语言的非英语语言支持。后缀源于 ISO 标准缩写列表，但通常很简单。例如：-it 代表意大利语，-fr 代表法语，-cz 代表捷克语，-de 代表德语，-es 代表西班牙语等等。
| kind | "'字符串值'" |
| trainz-build | 'float', 1 位小数 |
| kuid | <Kuid 编码值> |
| username | username "'字符串值'" |
| username-XX | username-XX "'非英语语言字符串值'" |
| description | description "'字符串值'" |
| description-XX | description-XX "'非英语语言描述字符串值'"[注释 1] |
| kuid-table 按 kuid 列出的依赖项（容器） { |
该资产所依赖的资产的键值列表。 |
| obsolete-table （容器） { } |
此资产取代的 kuid 列表（使其过时） 通常为无（空） |
| string-table （容器） { } |
资产中使用的字符串和消息的键值列表 通常为空，但是！ 在路线和场景中可能非常大。（地图上的命名资产列在此处，从轨道标记和触发器到信号，命名建筑物和产业，到路标。 |
| string-table-XX 按每种非英语语言（容器） { } |
翻译后的字符串列表匹配到必填的string-table |
| category-region "'字符串数组'" | category-region 标签 |
| category-class "'枚举字符串值'" | category-class 标签 |
| category-era "'字符串数组'" | category-era 标签 |
| 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 资产组资产列表。 |
所有 Trainz 定义的数据（内容）都有三个必填元素：一个config.txt 文件 用于组织数据，一个表示kuid 的身份（仅用户名对你没有用，但是可以创建合法的资产，而无需名称！），最后，一个合法定义的类型标签。类型负责，它是乐队的指挥，排长或 CEO 指挥——为之后处理的所有内容设置要求。简而言之，类型的价值，一小部分严格定义的成员组——告诉 Trainz 软件在虚拟世界中渲染和显示什么，以及如何（或在哪里）找到其他部分，以使 config.txt 文件中链接的资产部分组合在一起。
下面的每个子类都被认为具有TrainzBaseSpec 作为它们的数据 '父类'。[注释 2] 下面列出的几个类型，那些带下划线的类型是早于Trainz 数据模型在TS2009 发布（即 2008 年后期）中更改的旧类型，自那以后 N3V 程序员只实施了渐进的（增量）更改。
目前可以在 N3V Trainz Wiki 的内容创建者指南 部分找到基于这些旧类型修复资产的详细信息TrainzOnline 网站在这里，并提供发人深省的旧类型示例在这里。强烈建议Trainz 下载站 的所有用户或任何打算创建内容的用户仔细阅读 CCG。了解旧内容定义方式的背景历史可以与当前 TrainzOnline 对相同数据类型的报道进行对比和比较，因为这种过去与现在的对比往往会为修复、更改和定制资产提供宝贵的见解。更重要的是，CCG 在 TrainzOnline 上发布的是TC1&2/TC3 版本——这是自 1999 年Trainz 以来出版的几本小册子中的最新版本；TC3 CCG 包含来自 TRS2004/TRS2006 和UTC 数据模型的已更改的 Enginespecs 机车资产，需要适当更新。
- 本地化是 '学术界的说法' 用于“国际化”，或数据翻译成其他语言...
由于 ACS 文本格式 使用 UTF-8 编码，因此非英语文本字符串条目可能出现在 config.txt 文件中的任何字符串字段中，除非禁止。 (例如，用户名标签应该始终为英文，但语言后缀形式也允许在区域语言中支持多种语言环境 - 为了避免混淆，需要本地化支持的标准字符串标签实际上允许多个条目，因为运行时软件使用以下约定
- username - 内容的人类可读名称，以美式英语显示。 资产的英文名称必须存在，并且应该以英文定义。 (不幸的是，一些资产在没有对该标准进行监管的情况下上传，因此在 DLS 上发现了一些非英文名称。
- username-cz - 内容的人类可读名称，以捷克语显示。
- username-de - 内容的人类可读名称，以德语显示。
- username-es - 内容的人类可读名称，以西班牙语 (Espanol) 显示。
- 等等。
以下标准标签支持这种形式的本地化
其中 XX 是语言的 ISO 两字符缩写。 (例如 de=德语，fr=法语，it=意大利语，等等)
- attached-track 容器
- extensions 容器
- kuid-table 容器
- mesh-table 容器
- obsolete-table 容器
- string-table 容器
- textures 容器
- 缩略图容器
- ... 待续
Config.txt 文件在 Trainz 资产中是普遍存在的，因为没有资产可以在没有这种类型的 计算机科学容器 的情况下被定义。
- Trainz 印刷或 pdf 文件 手册，适用版本 - 通常在 ..\extras 或 ..\extras\manuals 文件夹 中
- TrainzOnline Wiki Config.txt 文件页面 和其他页面
- TrainzOnline Wiki 内容创作者指南页面 (各种)
- 各种 CCG 和 Auran 网站
|
本参考页面改编自 TrainzOnline Wiki，根据 CC-BY-SA 3.0 许可证。 本页面可能包含比 [online.ts2009.com/mediaWiki/index.php/Config.txt_file 相同主题的源页面] 更多的文本解释、说明、历史记录和/或示例。 TrainzOnline Wiki 主要由程序员或了解 内容创建者 维护，并且可能包含有关当前 trainz-build 代码 标准的更新信息，这些标准随着软件功能的添加而有所变化。 |