最近这些项目的阶段总结

RiotManifestGo#

这个是用 Go 重写的 Riot manifest 解析和下载工具。之前 Python 版本能用，但长期来看，下载、并发、Range、路径处理这些东西放在 Go 里会更合适一点。

最近主要是把下载路径和边界情况重新加固了一遍。manifest 这类东西看起来只是拉文件清单，但真要做成工具，就会遇到很多细碎问题：路径不能乱写，Range 响应不能默认可信，下载失败以后要能判断到底是远端问题还是本地处理问题。

目前它更像是后续一批工具的底座。只要还需要从 Riot CDN 处理资源，manifest 这条线就绕不开。

RiotManifest#

这是 Python 版本的 manifest 工具。

它还没有完全退场，因为 Python 生态里还有不少脚本和旧流程会用到它。最近主要是依赖和发布流程上的维护，不会像 RiotManifestGo 那样继续大改，但只要还有调用它的工具，就不会直接扔掉。

后续大概率是：新逻辑优先往 Go 版本靠，Python 版本保持可用和兼容。等迁移足够稳定，再考虑哪些能力合并、哪些能力停止扩展。

lol_extract_voice#

这个就不用多说了，英雄联盟语音提取这条线里最核心的工具之一。

最近也做了一轮发布整理，补了一些 GUI 引导和版本发布相关的东西。这个项目以前更多是“能把语音解出来”，现在慢慢变成“尽量让别人也能按流程用起来”。这两个目标看着接近，实际差得挺多。

前者是脚本能跑就行，后者就要考虑入口、提示、依赖、错误信息、用户会不会点错。没办法，工具只给自己用和给别人用，维护成本不是一个量级。

league-tools#

这个项目早期更接近 bnk-extract 的 Python 版本和相关工具集合。现在它的位置有点像英雄联盟音频处理链路里的基础依赖。

最近主要处理的是依赖自动化和发布策略。它不是每天都要加新功能的项目，但只要上层工具还依赖它，就要保证包能装、版本能发、依赖别悄悄炸。

这种项目最烦的地方就在这里：平时没存在感，一出问题就是整条链路都跟着报错。

pyvgmstream#

这个主要作为 lol_extract_voice 的依赖存在。

当前能用，也已经实现了需要的能力。后续没有主动维护计划，除非它自己出问题，或者上层工具需要新能力。依赖类项目有时候就是这样：最好的状态反而是长期不动。

vgmstream-cli-build#

这是对 vgmstream CLI 的扩展构建，增加了一些更实用的批量处理能力。

目前没有什么大改动计划。它的定位很工具化，能解决手头问题就行。除非后面音频链路又遇到新的批处理需求，否则大概率只会做修补。

lol-game-data-snapshot#

这个仓库是最近新拆出来的，作用比较单纯：保存从客户端 manifest 生成出来的游戏数据快照。

以前很多脚本都是临时取、临时处理，能跑，但是不太适合复盘和对比。现在把快照单独放出来，后面无论是做版本差异、事件整理，还是给其他工具当输入，都会更清楚一点。

说白了就是先把原料稳定下来。原料不稳定，后面所有自动化都会变成玄学。

FangYuan#

这个是现在博客在用的 Astro 主题，也是这次站点重新开张的基础。

最近发布了第一个公开版本。这个项目的定位也很明确：先服务自己的站点，再把通用部分整理成主题。它不是那种一开始就奔着大而全去的主题，更多是把中文个人站点、外部内容配置、评论后端这些自己真的在用的东西打通。

换成静态站以后，文章、配置、图片都更直接了。代价是构建链路要自己盯，比如图片路径、外部内容、评论集成这些。好处也明显：不用再被 WordPress 那套历史包袱拖着走。

QingYan#

QingYan 是给个人站点用的评论后端。

博客重新开张以后，评论也要重新接上。之前 WordPress 自带评论，现在静态站当然不能直接照搬，所以就有了这个后端。最近它也发了首个公开版本，至少先把安装、启动和基础路径固化下来。

评论系统这东西挺微妙的。不开吧，博客像自言自语；开了吧，又要考虑垃圾评论、维护成本、数据存储。现在的想法还是先做一个自己够用、能长期维护的版本，不急着搞复杂。

lol-event-semantics#

这个项目还在想办法。

英雄联盟音频最麻烦的其实不是“把文件解出来”，而是“知道这个文件在说什么、什么时候触发、应该怎么分类”。单纯靠哈希表或者规则替换，能解决一部分，但很难形成真正可靠的体系。

本地已经有一些探索，但还没到能公开成体系的程度。它后续应该会替代过去一些零散的事件表和脚本，只是这个坑比看起来深，不能硬凑一个仓库出来假装完成。

pyvgmstream#

这个主要作为 lol_extract_voice 的依赖存在。

当前能用，也已经实现了需要的能力。后续没有主动维护计划，除非它自己出问题，或者上层工具需要新能力。依赖类项目有时候就是这样：最好的状态反而是长期不动。

vgmstream-cli-build#

这是对 vgmstream CLI 的扩展构建，增加了一些更实用的批量处理能力。

目前没有什么大改动计划。它的定位很工具化，能解决手头问题就行。除非后面音频链路又遇到新的批处理需求，否则大概率只会做修补。

GrimoireVFS#

这个项目更像是一个已经完成的想法。

轻量、无依赖、安全一点的 Python 二进制资源管理库，听起来挺有用，实际做完以后暂时没找到特别合适的使用场景。它不是不能用，而是现在手头这些项目还没有强需求。

所以它会放在那里。以后如果某个项目真的需要打包资源、读写归档，再把它拿出来也不迟。

gemini-pmos-tweaks#

这个暂时搁置。

小米 5 加 postmarketOS 这个方向挺有意思，但现在项目太多，精力不够。折腾这种系统级东西很吃连续时间，不是今天修十分钟、明天改两行就能舒服推进的。

所以先放着。以后如果重新有精力折腾 postmarketOS，再继续。

lol-manifest-tool#

这个被其他工具替代了。

manifest 相关能力后续会集中到正在维护的库和工具里，比如 RiotManifestGo、RiotManifest，以及依赖它们的快照和资源处理流程。单独维护一个旧工具意义不大，容易让入口越来越混乱。

kratos-pe#

以前的 WordPress 主题项目。

现在博客已经不用 WordPress 了，这个自然也不会继续维护。它属于过去某个阶段确实用过、也解决过问题，但现在技术栈已经换掉了。

valorant-audio#

这个有恢复的可能，但现在先搁置。

Valorant 音频方向不是完全没兴趣，只是当前主线明显还是英雄联盟这边。两个游戏都做的话，资源、规则、更新节奏都会翻倍，现阶段不太现实。

lol-audio-events-hashtable#

这个已经被 lol-event-semantics 替代。

哈希表本身可以作为历史数据参考，但后续不会再以它作为主维护对象。事件语义如果要继续往下做，肯定不能停留在简单表格层面。

lol_dialog#

这是 2022 年的项目，基于第三方语音识别服务去处理英雄联盟默认皮肤语音。

现在这条线已经不会按原方案继续了。下一步如果要做识别，也会等事件名字整理处理完以后再看，而且不太可能继续依赖第三方云服务，可能会转向本地模型。

旧项目不一定完全没用，它至少证明了当时那条路能走到哪里。但现在继续沿着 2022 年那套方案做，意义不大。