缺氧版本号

正式版: CS-469300-D

更新速度已经肉眼可见的慢了下来……

一来是一些属性和程序关联性（C#我也是现学现用的，好在看懂不难）需要更多的思考；二来是规划时候就把简单的放在了前面、繁杂的放在了后面……；三来，最近工作也越来越忙了……。。

这期更新完成后很可能会直接进入【Manager】文件的分析，光是对于其目录结构整体的梳理，就是一个超级大的工程……我觉得进入【Manager】后，半个月能够更新一期就是神仙了……

还望各位看官老爷们，不要觉得我是溜走了……

我真的不是不想更新，是内容太多了哇/(ㄒoㄒ)/~~！

下面进入本期正题！

A、文件概述

codex作为一个文件夹，其完整地址为：

.\StreamingAssets\codex

此文件夹内在当前版本下包含以下主要类别：

1. 建筑 Building（这里只有一个打印舱……）

2. 小动物 Creatures

3. 植物 Plants

4. 间歇泉 Geysers （这里只有一个储油石……）

5. 系统 System

6. Emails 电子邮件

7. Investigation 调查

8. Journals 日志

9. Notice 通知

10. ResearchNotes 研究笔记

11. MyLog 我的日志

12. HomePage.yaml 索引

本文件夹内的内容构成了游戏内右上角数据库的大部分，内部依旧是yaml文件。

• 上方列出的 红色（其具体数据信息除外） 与 橙色（可视为游戏背景/剧情资料） 内容和游戏内数据库内容是基本对应的。

• 索引信息 内部只有一个排版情况，应只用来提供索引排布，无特别意义。

• 建筑 应该是不再从这里调用信息了，只有一个打印舱保存在这里，有一个disabled: false属性。在游戏内数据库直接索引一层层翻找，没找到，但是直接搜索就有。大约就是达成了这个效果？

• 间歇泉 是一个神奇的存在，猜测为已经废弃的调用（有了其他地方可调），或后续会调整过来（不信……）。

Tip：关于间歇泉，有个特别有意思（离谱！）的点在于，其他所有数据引用StringKey均为“STRINGS.CODEX.”开头，而间歇泉在游戏中的StringKey开头是“STRINGS.CREATURES.SPECIES.”。每一种泉都是，生物……有意思……EmmmmΣ(っ °Д °;)っ？？？大约是为了什么机制？

B、数据分析

这个大概会比elements略麻烦一点，毕竟有一些层级结构。

第一层结构已经在A部分中进行了介绍。

第二层结构则是每一类对象的细分，如动物的亚种（目前只有动物这样做了……）┑(￣Д ￣)┍不过可以很明显地推测，游戏对于所有可能有细分的对象都采用了Dynamic（动态的）这个前缀。所以一个对象如有细分，则会在同层级下建立一个文件夹，其名为对象文件名“_”后单词的复数形式。其内部细分文件名，前缀则为SubEntry（子条目）。

就这样对应，这只是人眼观察的最好方法罢啦！

当然我不觉得程序这么判断 对象文件 和其 细分文件夹 的关系……=。=闹呢！

每个对象的yaml文件里呢，都有一个id属性，作为其标识。其细分（文件夹内）后对象的yaml文件中呢，还有一个parentEntryID属性，这里就写的是它所继承对象的id。那么从属关系，也就在这里很明显啦~

除此以外，还有一些其他的属性。

• title: 一个STRINGS字符串。结合细分子项目的title内容，推测最有可能是用于codex中搜索条目名称的对应。（个人认为几率为99%，除非klei强行搞乱数据调用关系。这里从细分子项目title&&一个游戏内数据库搜索特性（bug？后面会提到）入手，可以快速锁定。）

• contentContainers: 其后为数据库中显示具体内容。

• content: 具体内容为分块布局中，每一个布局内的内容。

• !XXXX: 绿色这三个是一组。此为数据类型。CodexText为文本，CodexDividerLine为分割线，CodexImage为图片，

• stringKey: CodexText时存在。数据库中要显示的具体内容对应的STRINGS字符串。用于调用。可在《strings解析》一文中了解。

• style: CodexText时存在。说明stringKey调用数据的格式（级别？）。Title为标题级别，Subtitle为副标题级别，Body为普通文本级别。

• spriteName: CodexImage时存在。尚未分析图片部分信息，因此猜测为图片id的调用。【待后续验证。

• preferredHeight: CodexImage时存在。图像显示的高度。

• layoutPriority: 细分子项目特有。因数据库中，子分类是接在parent级条目下直接展示的，所以此值标表示子分类的展示顺序。

• sortString: Mylog特有。根据包含有该属性的yaml文件来看，均为“启动信息”、“周期X”，因此猜测为根据游戏进程直接展示出的日志。【具体意义与作用待后续验证。

• lockID: 目前基本可推测为，该条目需要绑定到的对象函数，即当该函数完成调用后（即该函数对应的时间在游戏中被完成），解锁此条目。

至此，该文件中绝大部分属性已经基本了解。

C、特性闲聊

那么，再来聊聊这里的一些有趣的小点：

• 字符串中会有一些字符，是可以通过<link=\"id\">某一字符串</link>来制造可点击链接，用于呼出id对应的游戏内数据库数据。【但是，这里link到的id还需要研究~】

• 特性：对于“小动物”这部分，因为存在细分子条目，它的parent级里，title用的STRINGS……和主子条目title的STRINGS，，大多数情况是一样的。。。这其实保证了搜索名称不会存在物种名，而都是实际动物名~~延申特性（bug？）：但这就导致，你在游戏里比如搜索“毛鳞壁虎”，它出来两条记录（这里还可以理解为主分类和子分类）；但是比如搜索“抛壳蟹”，他就没有子分类啊，还是两条记录哈哈哈=。=

可以被理解的壁虎……

就……离谱的抛壳蟹

就说到这里吧！

那么开始进行数据的提取工作咯~ ( •̀ ω •́ )y

D、数据提取

这里听取了一下有好的轮子何必自己造轮子的想法，同时也考虑到yaml的解释器写出来了以后，也暂时值时针对游戏内使用的yaml部分语法。。何必呢

于是我放弃了自己写的这个垃圾解释器……

pyyaml模块~它不香么！【顺手直接把原来的elements的代码也改了。。舒服……

当然提取的数据还是返回一个字典。。。。

字典格式如下：

{
  "MainTitle":{
    "title":"游戏内数据库具体内容中显示的标题名",
    "Subtitle":"游戏内数据库具体内容中显示的副标题名",
    "Body":"游戏内数据库具体内容中显示的正文文本" },
  ......
}
# MainTitle：就是yaml文件中的开头那个title对应的STRINGS对应的实际名字。
# 以上实际都已在strings中转化成中文了。
# 例如：
{
  "打印舱": {
    'Title':'打印舱',
    'Subtitle':'',
    'Body':'庄严科技开发的一种先进3D打印机。\\n\\n这款打印舱的最大特点是能够依据生物蓝图打印活的有机材料。\\n\\n该产品能够合成专用的打印有机材料，并且储存了多到几乎不可思议的能量，完全可以自动打印所有3个周期。' }，
   ......
}

简单点，就这样了……没啥说的了！嗯~ o(*￣▽￣*)o

这部分其实真没啥可写的……就import了啥啥……导出了啥啥……

然而却是要干的事情最多（也许以后是第二多）的？【Manager】数据分析的量感觉要崩……

至此，【StreamingAssets】中的主要内容已经基本搞定~

其他一些小文件夹，以及图片相关的信息，什么时候写就先随缘啦~

下一步还是以数据为主，所以还是打算继续进攻【Manager】。

因为图片提取不是什么重点。

而【StreamingAssets】下其他文件的内容，直接看可能有点难以分析。我觉得可能基于【Manager】的一些数据整体来思考，会有更高的效率叭！

那么这篇确实好长了，就不再写有的没得了，真是头疼~~

估计各位看的也会头疼吧……哈哈。不搞了！就此结束！

( E.N.D )