文章列表
这里是博客所有文章的列表。
Policr Mini 现在运行在 ARM64 架构的服务器上
由于 x86 服务器成本较高，Policr Mini 已经被迁移到 ARM64 的服务器上。相比于此前的服务器，现在使用的 ARM64 服务器具有更大的内存和更强的 CPU 性能。由于此前的服务器只能勉强应付负载（尤其是本地部署 Bot API 以后，内存严重不够用），时长导致机器人不稳定。现在以及未来较长一段时间里应该不会发生了。 为了更快的发布 ARM64 架构的构建版本，新增了一个 arm-develop 标签的镜像（此标签仅支持 arm64 架构）。开发分支短期内可能不会再构建 x86 的版本，因为构建多架构镜像非常的耗时（之前的情况是反过来的，即 develop 只提供 x86）。 不久的将来我们会再次提供多架构的 develop 镜像。 注意，这里有两个变化： 控制台的统计数据被清空了，我们没有迁移这些数据（因为它还是实验性的）。 机器人的网络延迟变高了，因为我们不再使用更靠近机器人帐号数据中心的服务器。 如遇到异常请即时反馈。
Policr Mini 更新：新的 Web 控制台，基于时序数据的统计功能
本文不能算正式的更新说明，仅包含下一阶段部分内容。这些更新也并未推送到 stable 分支。截止到本文发表，下阶段的完整计划并未完全实现。 注意：曾经的 master 分支已被重命名为 stable 分支。目前的所有更新都停留在 develop 分支上。 新的 Web 控制台 控制台是用于替代旧有后台的新功能管理页面。也就是曾经的 /admin 路径访问的管理后台，它将会被 /console 淘汰。我们没有选择改造旧管理后台，实质上一直以来它也没有得到积极的维护和更新。 旧的管理后台是一个具有严重历史包袱的前端部分，它早已经过时且年久失修。新的控制台毫无包袱，它基于 SolidJS + TailwindCSS + ArkUI，使用 Vite 构建和 Typescript 语言开发。控制台的源码位于 webapps/ 目录下。 控制台将会提供比后台更多的内容，包括所有功能设置、记录查询、数据分析等。更加精美，它不基于任何带有固执己见样式的 CSS 组件库，具有最高的定制自由度。同时兼容移动端和桌面端访问。简单来说，控制台更加强大，实用和美观！ 桌面版截图： 移动版交互： 目前控制台正在积极开发，你可能会看到随着时间推移它逐渐完善的现象。文本发表时，仅在「仪表盘」页面存在内容。 基于时序数据的统计 在此前 Policr Mini 将统计结果存储在 PostgreSQL 上，查询时不需要聚合即可高性能获得统计数据。因为传统数据库并不适合作为时序或指标数据的存储后端（在未足够优化的情况下）。相关功能也非常简单。 现在 Policr Mini 的验证数据（点）已交给 TSDB 处理，目前使用 InfluxDB。它仍处理实验性阶段，数据可能在任何时候清空和重新生成。我们希望能提供足够长的统计窗口，例如最近一年的各种报表。 结束 你不能通过简单的升级开发版镜像来完成更新，因为有一些新增的设置还未提及。你目前不应该升级，请等待下一阶段的正式更新内容。
幻兽帕鲁助手机器人使用教程
介绍 我们发布了幻兽帕鲁的 Telegram 机器人助手，私聊 @palworld_tools_bot 即可使用。目前机器人提供最短帕鲁配种路径搜索功能，后文会讲解细节。 注意：当前机器人只能在私聊中使用。如果你有人数众多的游戏群想拉进去供群友使用，可以反馈给我们，我们会考虑加快进展。 最短配种路径 不同于查询配种表 配种路径搜索和配种关系查询并不相同，网络上常见的查询功能是通过父母帕鲁或结果帕鲁查询存在配种关系的简单功能。例如我们有一只棉悠悠，可以查出棉悠悠可以配出什么，以及什么可以配出棉悠悠。它的作用十分有限，例如我想知道怎么通过棉悠悠一路配种到焰煌，它的效率和对着配种表手动 Ctrl + F 搜索几乎没有区别。 需求和结果 假设我们有一个棉悠悠，它有我们需要的金词条，我想将此词条继承到焰煌，该如何做呢？这时候就需要最短配种路径搜索了。结果如下： 节点编号 父母1（已拥有） 父母2 结果 1 棉悠悠 雪猛犸/佩克龙 严冬鹿 2 严冬鹿 女皇蜂/覆海龙/腾炎龙/森猛犸/雪猛犸/天羽龙/熔岩兽/铠格力斯 炎魔羊 3 炎魔羊 清雀 覆海龙 4 覆海龙 朱雀 清雀 5 清雀 焰煌 焰煌 每一个路径节点的第一个父母都是已拥有（起始或上一个节点的结果）帕鲁，第二个父母是可选帕鲁，所以它可能有多个。 使用 私聊 @palworld_tools_bot 发送 /search_breeding_path 命令即可使用此功能。路径节点数量没有限制，可以超过 3 个，且能瞬间给出搜索结果。 警告 此功能会聚合数万条数据，通过纯算法推导路径。当前它可能存在一些不合理或 BUG，但通常不影响结果。 结束 我们会视情况决定是否添加更多辅助查询功能，如果你有需求，可以在频道的消息中提供建议。如果有可能，我们还会免费提供自动部署游戏服务端、生成世界配置甚至修复/修改存档的技术性功能。
我们正在计划开源一些新项目
我们计划开源一些新的项目。这些项目有些是待开放的，有些是和曾经的商业客户讨论过后决定部分开源的。 目前我们有两个肯定会上线的项目。一个跟 AI 聊天相关，一个跟远程下载管理相关。它们都可以集成 Telegram 机器人来使用，并且都是免费的。在前期我们可能会闭源运营一段时间，直到我们认为已满足开源条件。 提示 我们始终寻求开源项目的可持续赞助商，如有意愿欢迎与我们联系。
Mini Assets 生成器更新：增加居中剪裁机制
大家好，随着 Policr Mini 最近的更新，我们的验证资源制作工具 mini-assets-gen 也有了新的进展。现在用它制作的验证资源更具识别可靠性和一致性，为网格验证提供了更好的效果。 此前的设计 之前的版本中（实际只发布过一个版本），mini-assets-gen 通过指定统一的宽度（width 字段），让输出图片的宽度和指定的值一致，高度按原始比例保持自由。在网格验证诞生前，这个设计是没有问题的，因为 Telegram 的图片预览也有一定程度的尺寸自适应，用户几乎不需要看点击图片（看完整大图）就能完成验证。 新的问题 自网格验证诞生后，这种简单的设计造成了一些弊端。网格验证需要每个单元格（单个图片）保持一样的宽度和高度，合成的完整图片才具有最好的视觉效果。若图片的宽高都截然不同，网格验证也兼容了这种情况，它会缩放图片到指定的统一尺寸。 弊端很明显，部分尺寸差异太大的图片在横向或纵向上会被拉伸变形，影响视觉效果（不美观，识别困难）。有的图变形得甚至有些滑稽：） 居中剪裁机制 为了解决上面提到的问题，我们给 mini-assets-gen 增加了「居中剪裁」这一图像处理步骤。 首先图片会按照指定的宽高比例计算出保持该比例下最大的居中剪裁区域（新的宽高和居中坐标）。在进入第下一个步骤前，图片尺寸仍然是各式各样的，但是它们都具有相同的比例。例如 240x160 和 180x120，宽高比都是 1.5。在后续图片缩放时，几乎不会被拉伸，因为在缩放前图片已经是指定的宽高比例了。我们只是在上一个步骤中将比例之外的部分“裁剪”掉了，保留的是可居中的最大区域。 一些例子 我们准备了一张图片，用于清晰的展示包含居中剪裁机制的优势。这并不是一个好的图片，可以看到它的主体内容太偏左了。 危险 更致命的是，此主体内容是一个圆形的物体，一颗足球。 我们将其用旧版本缩放，设定宽高是 240x160： 警告 足球已有轻度的如从左右方向挤压过一般的变形。 我们再次将其用旧版本缩放，设定宽高是 140x160： 危险 此时变形十分夸张。若是“风景”可能还能看，但足球这种圆形物体被拉伸一点就很明显了。 信息 注意：旧版本在缩放图片时高度是按照比例决定的，输出图片并不存在拉伸。变形只发生于网格图片合成。 我们用添加居中剪裁机制的新版本，设定同样的严重失实的夸张宽高，看效果： 可以看到足球被剪裁掉了左边的一部分，因为足球本就靠左。但是它的形状是真实的，没有变形。这就是居中剪裁后再缩放的效果。 提示 只要图片的主体内容没有太偏离中心，生成的图片就基本完美。 我们用一张更标准的图片举例，它是一张长明显大于宽的图片，且内容主体几乎在正中间： 本文不存在任何整治立场和表达，此处的「自由女神像」图片只是恰好符合我们的筛选特征。 我们仍然用夸张的失真的尺寸来缩放它： 有趣的是，我们将一张典型的长方形图片缩放成了正方形，但是图片内容并没有变形。图片主体人物的面部基本位于中心，图片类型（即雕像）特征仍然极为明显。这就是我们想要达到的效果，居中剪裁也确实做到了。 使用 居中剪裁机制在 0.2.0 版本发布。它有一个破坏性修改，清单文件 Manifest.yml 必须指定高度（height）字段。你只需要在清单文件中像这样加入即可： --- version: 0.2.0 datetime: "2024-01-11T09:27:25Z" width: 240 height: 160 # <- 加在这里 # 其余内容省略…… 具体的宽高根据你收集的图片的实际情况来决定，最好是更为通用的比例。Policr Mini 官方公布的验证资源的宽高比是 1.5，也就是上述例子中的 240x160。在 Policr Mini 的部署中，配置的网格验证宽高值的比例也要与此处保持对应。
使用我们的 Telegram Bot API 镜像
Telegram Bot API telegram-bot-api 项目是 Bot API 的后端程序，提供 HTTP 接口给机器人调用。 在开发机器人时，我们可以选择和官方的部署于荷兰节点的 Telegram Bot API 交互（即默认的 https://api.telegram.org/ 地址），也可以选择自己部署 Bot API 后端程序，让机器人和自己的后端交互。 我们的镜像 我们创建了gramlabs-oss/docker-telegram-bot-api仓库用于构建镜像，也可使用我们托管于 Dockr Hub 的预构建版本。 当你想为例如 Policr Mini 这样的项目配置自己的 API 后端时，应该考虑使用我们的 Bot API 镜像，因为它和开发进展具有绑定关系。查看docker-compose.dev.yml文件可以看到绑定的 Bot API 版本。 提示 我们发布的镜像还提供对 ARM64 架构的支持。 使用 这是一个示例 docker-compose.yml： services: telegram-bot-api: image: gramoss/telegram-bot-api:ade0841 # 标签 hash 对应 telegram-bot-api 特定提交 environment: TELEGRAM_API_ID: <YOUR_TELEGRAM_API_ID> TELEGRAM_API_HASH: <YOUR_TELEGRAM_API_HASH> TELEGRAM_LOCAL_MODE: true # 添加 `--local` 选项 your-bot: # Your bot service # 使用 `http://telegram-bot-api:8081` 作为基础 URL 镜像是 gramoss/telegram-bot-api，标签是 ade0841（对应telegram-bot-api/commit/ade0841）。
Policr Mini 更新：新部署模型，网格验证，图片重写机制以及 ARM64 架构支持
这是第一篇在博客中发表的更新日志，很高兴在此宣布 Policr Mini 的新内容。你们可能也注意到，前不久 Policr Mini 的域名已更换为 mini.gramlabs.org，它是新的官方域名。 官方的线上版本最后一次具有实质功能变化大约是在半年以前，这期间也不定期的做了一些维护升级工作。这半年来的更新也逐渐在开发分支积累，这些变化将在下面一一介绍。 新的部署模型 在此前版本中机器人只能处于 Polling 工作模式（轮询获取更新），我们将官方实例部署于荷兰（或其它欧洲国家）节点，以尽可能的减少延迟。但这是远远不够的，通信路径决定了它的网络延迟并不会太低。 注释 在最理想的部署环境下，机器人程序应该运行在离自己的数据中心最近的位置，并和同样位于该数据中心附近的 Bot API 服务端通信。它最好通过 Webhook 工作模式获取更新。 得益于对全新的 Telegex 1.0 框架的适配工作结束，我们可以随意改变获取更新的工作模式，自由配置 Bot API 的服务端地址。官方实例当前在 Webhook 下工作，并与本地部署的 Bot API 服务端通信。这几乎把延迟降到了最低，所以能感受到它的响应速度明显更快了。 信息 对于自建用户而言，要切到到 Webhook 工作模式并和本地部署的 Bot API 服务端集成，你需要额外配置一些东西。请参考此处。 网格验证 此前默认的验证方式是通过识别单张图片，并在数量不超过 5 个的按钮列表中进行选择。严格来说，它存在较大的“碰运气”可能。我们当然也可以简单的提高答案列表的个数，但会导致消息显示占用太长的屏幕空间。 其实很早我们就开始考虑用更复杂的交互来避免这一点，在「多选」和「多阶段」以及「多图片」中犹豫了很久。实际上这些我们都会实现，但当时考虑的是优先实现哪一个。最终我们实现了「多图片」，即网格验证： 来自『POLICR · 中文社区』的验证，请确认问题并选择您认为正确的答案。 选出所有「火车」的图片编号 您还剩 198 秒，通过可解除限制。 329 107 548 817 428 106 327 598 129 提示 就像上面的模拟 UI。网格验证会生成单张 9 宫格图片，让被验证用户选择其中的某一类图片。每一张图片都会被“编号”，每一个按钮上都是多个编号的组合。 理论上网格验证的安全性要高得多，因为每一张图片都是随意组合生成的，且答案数量更多，识别难度更大。 我们以上面的截图为例，正常思路的人类会认为答案是 248，但实际生成答案是 428。它是无序的，这也进一步阻碍了识别速度。即使面对批量过验证的“人形机器”，也有够受的。不过我们仍然认为网格验证是用户友好的，所以它成为了新的默认验证模式。 信息
升级 PostgreSQL 到 16 版本（适用于 Policr Mini）
为什么要升级 在 Policr Mini 项目成立时 PostgreSQL 的大版本为 12，而现在的 PostgreSQL 已进化到 16 版本。落后数个数据库大版本的状态对于项目的可持续发展是不利的，这便是升级原因。 注释 如果您的实例使用的数据库版本已经是 16 或更新的版本，您不需要做这些。官方实例于 2023-08-18 完成升级，部署于此日期之后的实例通常也不需要升级（因为文档的配置模板中的版本已是最新）。 一般的升级步骤 PostgreSQL 官方有一个叫做 pg_upgrade 的工具，它可以直接将旧版本的数据兼容性提升到新版本。但是这个工具有一些限制，比如不能跨大版本升级。 如果要将 12 版本升级到 16 版本，我们需要循序渐进的经历这期间的所有大版本的过渡升级：12 -> 13 -> 14 -> 15 -> 16。这太过于繁琐，所以我们不使用这种方法。 提示 若我们后续会紧跟 PostgreSQL 的版本步伐，pg_upgrade 其实也可以是合适的工具。 数据备份与还原，升级一步到位 我们可以通过 pg_dump 和 pg_restore 两个工具来备份和还原数据，这样就可以一步到位的完成数据兼容性和数据库版本的升级。 具体步骤 以下步骤都默认在项目根目录下运行，也就是 docker-compose.yml 存在的目录。请先 cd 到该目录下，再往下看。 创建数据备份目录: mkdir dumps。此步骤是为了让数据备份文件可以存放到指定的宿主机（Host）目录中，为备份和还原做准备。 编辑 docker-compose.yml 文件，在 services -> db -> volumes 下添加 - ./dumps:/dumps，请注意缩进的正确性。此步骤是为后续还原数据做准备。 停止机器人服务: docker compose stop server。此步骤是为了避免在备份和还原期间，机器人向数据库写入新的变化。 备份数据: docker compose exec db pg_dump -U postgres -F c -Z 5 policr_mini_prod > dumps/policr_mini_prod.
为什么 Telegex 1.0 是正确无误的框架
本文章是早期 Telegex 作者在外部宣传时发表的内容，它还欠缺修改以更适应博客读者。 背景 大概三年前，我们创建了一个叫做 Telegex 的库。它那时候只是一个简单的 Telegram Bot API 客户端，虽然它的实现也是用数据来生成一个个调用 API 的函数，但是面对 Bot API 的频繁更新，它仍然显得适配乏力。 最近，我们完全重新的设计了这个库。它在适配新的 Bot API 的速度上是无与伦比的，因为只需要一条命令。秘密在于它基于官方文档“数据”来自动生成代码，只需要更新一下文档便可适配所有最新变化。包括 API 变动、注释变动，任何类型和字段的变动。 为什么叫文档数据？ 因为文档真的解析成了数据。我们将官方文档页面中的几乎所有的有效内容转换为了 JSON 格式，并上传到独立的仓库中（telegex/api_doc.json）。包括所有类型、方法和注释。 从文档生成 JSON 文件是 Mix 任务，位于 telegex/lib/mix/tasks/gen.doc_json.ex 文件。 对于类型 我将类型转换为 JSON，如： { "name": "WebhookInfo", "description": "Describes the current status of a webhook.", "fields": [ { "name": "url", "type": "String", "description": "Webhook URL, may be empty if webhook is not set up", "optional": false }, { "name": "has_custom_certificate", "type": "Boolean", "description": "True, if a custom certificate was provided for webhook certificate checks", "optional": false }, { "name": "pending_update_count", "type": "Integer", "description": "Number of updates awaiting delivery", "optional": false }, { "name": "ip_address", "type": "String", "description": "Optional.
博客成立了！
新的一年大家好！为了迎接崭新的 2024 年，本博客终于上线。博客的更多细节可以参考关于页面。