median-dxz / seerh5-assistant

赛尔号H5端登陆器 & api封装接口

Median-dxz | 君の指先で舞っている電光は、私の今生に変わらない信仰

seerh5-assistant's Issues

因子兑换界面修改

在core中支持的部分：

• 根据id判断精灵是否存在
• 如果存在则获取ct
• pet支持判断
  • 是否开启魂印(通过Pet对象的hasEffectgetter判断是否有魂印，然后通过player-info模块下的isPetEffectActivated函数判断是否激活)
  • 是否拥有第五(通过Pet对象的hideSkillActivated属性，存在说明有第五，true/false代表是否开启)

在sdk中实现的功能：

• 更改筛选因子的行为
  • 未兑换本体但有因子
  • 已兑换精灵但是没兑换第五和魂印
  • 可兑换时列表显示叹号
• 兑换魂印第五的时候自动首发精灵再启动兑换, 如果背包没空间或精灵不存在则维持默认行为(提示需要手动设置首发)
• 右侧面板直接显示是否拥有
• 右侧面板在已拥有时disable按钮

因为现在常常需要查一下这个精灵换过没，如果换过是缺第五还是缺魂印，很麻烦，所以想写一个修改功能。因为这个字是贴图，所以加筛选按钮不是那么方便，就直接改功能了。
具体来说，修改两个筛选选项：

• 未拥有：这个精灵因子还没有兑换过本体
• 可合成：所有已经有本体，但是缺第五 or 魂印的

上述操作只支持唯一性精灵!

[错误报告] 运行程序时出现 "Error: connect ECONNREFUSED ::1:80" 错误

错误描述
在尝试使用该程序时，我遇到了以下错误信息：

03:57:58 [vite] http proxy error at /seerh5.61.com/app.js?t=1686556678680:
Error: connect ECONNREFUSED ::1:80
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1494:16)

问题背景
我尝试在我的环境中使用程序时遇到了这个错误。这个程序使用了 Vite 构建工具，并尝试在本地运行一个 HTTP 代理。

错误详细信息
错误信息中指出了错误的原因和位置。根据错误提示，这是一个连接被拒绝的错误 (ECONNREFUSED)，发生在本地主机 (::1) 的 80 端口上。

问题重现步骤
在我的环境中，安装了所需的依赖并克隆了程序的代码。
在终端中进入程序的根目录，并执行启动命令。
在启动过程中，出现了上述错误信息。
期望行为
我期望程序能够成功启动，并且 HTTP 代理能够正常工作，没有连接被拒绝的错误。

环境信息
操作系统：Windows 11
Node.js 版本：v18.16.0
NPM：9v.7.1
其他相关软件或依赖的版本信息
为了解决这个问题，我已经尝试了以下方法：
检查本地主机和端口是否正确，并确保没有其他程序占用了该端口。
确认是否存在防火墙或网络代理的配置问题，导致连接被拒绝。

套装切换bug

把漆黑天使切换为杰出新兵（自带目镜）后，再切换回漆黑天使，目镜那栏会显示异常，虽然改了，但不显示。
https://www.alipan.com/s/aJD77DELLAi

一键收发星星BUG

到达上限后出错

电池时间显示为100%

电池相关的逻辑都还在，但是UI上被硬编码为满电100%，意义不明。

还未验证5小时之后能否正常不获得经验，可能考虑写个mod把电池显示加回去。

SEA Project v0.6.x 版本迭代计划

主项目

• 项目更名为SEA(Seerh5 Assistant Project), 启动器部分名称更改为SEAL(Seerh5 Assistant Launcher)
  • core包更名为sea-core
  • server包现在是@sea/server
  • app包现在是@sea/launcher

其实名称没变，变的是缩写

工具链部分

• 项目全面启用pnpm
• 添加nodemon支持
• 添加concurrently支持

后端 & 技术栈

• 后端迁移至TS+fastify+tRPC (#9)
• 样式引擎切换至emotion

SEA Core v0.5.0

• logger部分重写，迁移log逻辑到app层，core不再负责log信息的显示
• 重构对战策略模块概念, 精简核心的职能, resolveStrategy由Manager导出, 主要逻辑的处理移交登录器层

SEA Core v0.6.0

• 重构GameConfig查询模块, 采用注册接口架构, 配合TypeMap, 添加可扩展性
  • 通过模块声明合并以及全新的GameConfigRegistry注册可查询的GameConfig
  • 通过GameConfigRegistry获得GameConfigQuery对象用以查询数据
• 事件模块全部重构, 采用RxJS, 以响应式结构作为事件相关逻辑的组织方式 (#10)
  • 使用Subscription来批量管理订阅
  • DataSource现在是使用观察者模式而不是发布订阅模式
  • 使用DataSource上的静态方法from*来获取事件流, 而后进行订阅
  • 移除SendWithReceivedPromise接口, 根据发包客户端的源码分析，这个接口是没有必要的
• wrapperapi重构, 采用链式不可变结构对函数添加before和after装饰器

SEA Core v0.7.0

• 使用类型来提示SDK使用者和Launcher开发者当前Core的版本
  • 从CoreLoader上来获取实例版本, 从type中获取api定义的版本
• CoreLoader现在不需要传入监听事件名了
• 属性攻击/特攻/物攻的枚举
• 额外允许一些模块打印关键日志, 通过common包下的log模块启用
  • Log.setLogger()允许使用自定义logger, 默认启用console.log, 输出格式为[sea-core][module name]:
  • 外部api为Log.enable()和Log.disable(), 通过传入模块名称来开启这一部分的输出
  • 目前暂定支持的模块只有Battle, 开启后将输出Operator模块的入参
• LevelRunner api更改
• 更改事件签名方式->type:event
• 修复缺失的fromEventPattern导出
• 更换playerSuit的检测方式, 添加更多定义
• GameConfigQuery api更新
  • 添加查询id的getIdByName 方法
  • 现在要求传入以id为键的Map, 查询id时现在基于Map, 以此加快对大表进行id查找时的速度
  • 添加对Equipment(装备)的查询
  • Query的查询方法现在具有正确的可空返回type

Launcher部分

#11

• 重新组织UI实现, 添加基于Tabs的路由
• 添加独立Service层, 实现最基本的模组管理
• 重新组织入口点部分的代码
• 迁移所有旧版关卡
• 更换sdk和模组定义, 现在是基于函数组合的实现而不是原来基于类的实现
  • 迁移所有模组到现在的sdk接口
• 命令栏功能重新启用

预设模组集

• #6
• #7

sdk

• sign类模组：对check进行优化，批量查询multiValue，减少发包次数 sign类模组接口即将改变，之后会重写对应部分

theme传sx，不用手动导入！

• createLocalStorageProxy api已删除
• extractObjectId api已删除

issues:

• #4
• 战队派遣模块的bug(重复刷新)
• 更新背包精灵发包后无响应的bug(cache await update一直不resolve)(hmr?)
  • 在两个缓存逻辑修复之后暂未发生过
• #5
• 不能正确领取精灵王每周奖励
• 套装更换面板不能正确识别目镜栏位
  • 预定修改方案是更换套装功能不变，单独检测当前套装效果，同时加上目镜栏的更换功能

让LevelManager和Task提供更好的出错处理抽象

举例说明，精灵王日任关卡挑战的是困难难度，那么对于还没解锁困难难度的萌新，在使用该关卡时，关卡应该抛出异常让登录器的任务调度器(taskScheduler)去处理还是使用状态机自行处理？如果自行处理，根据目前的架构设计思路，next函数是否应该返回一个特定的错误状态？还是在data中置一个errno属性，然后自陷一个通用的error状态？
而且说回来，有必要区分前置条件不满足（可以在update函数中判断出）和意外错误导致的关卡无法运行吗？
目前的大部分自由度交由关卡模组本身来处理。TaskRunner并没有能和登录器交互的接口为logger和错误捕获，和LevelRunner的交互是特定Action和错误捕获，有必要增加交互方式吗？

sa-core package.json

seerh5-assistant/packages/core/package.json 的export 里不知道为什么路径都是relative to dist 文件夹的，但是core里面并没有这个文件夹，是不是之前有然后没改package.json啊。

签到部分修正

• 添加战队道具自动兑换
  • 正确判断道具设施是否开启
• 判断今日派遣次数
• 修复vip领取错误
  确的判断今日点数是否领取预设总点数到二十再领取(懒得改了)
  • 正确的判断是否可以领取点数奖励
  • 正确的领取设置的点数奖励
  • 领取日/周/月礼包

战斗结束，关闭得到新技能面板导致的看板娘消失问题

• 注意到新技能面板同样会导致使用物品界面的立绘消失 无法复现
• 猜测是新技能面板的style设置不正确
• 还未在原版游戏中尝试过是否能复现: 确认可以复现

因子目前存在稳定的断线情况, 具体来说就是隔一段时间或者场数断一次, 不频繁, 但是怀疑和单纯的两次战斗之间的延迟已经无关联

容器化以方便部署

待定

这个项目该如何使用呢？

请问这个项目该如何使用呢？

给`launcher`的测试脚本加上`--host`

如题，本人电脑是经常开着代理的，如果测试脚本不加--host进行暴露，就会出现无法访问的情况

"dev": "vite --open"

改成

"dev": "vite --host --open"

9-12月迭代计划表

sdk

sdk将转为独立仓库，同时将github仓库作为模组的在线源，目前参考的思路是BetterNCM的插件源处理思路。大致描述为：

1. 创建一个模板仓库，可以通过fork该仓库快速创建模组开发环境
2. sdk使用github发版的mod-type/mod-resolver/core进行开发
3. 使用esbuild进行构建，需要手动配置环境变量，包括后端api和入口
4. 编写esbuild构建插件脚本，在开发模式下，以监视模式运行，并自动通过插件以更新模式安装到后端
5. 生产模式下，构建生成用于提交到
6. 创建一个插件源仓库，该仓库主分支包含所有模组的源码
7. 该仓库另一个分支包含所有的构建结果和清单文件，作为插件源
8. 构建是由github actions自动触发的CI，通过提交pr来发布模组，只允许提交模组的源码，审核完成才能合并

以上具体实现方案仍在探索中...

core v1.0.0

core在最近的开发中基本维持稳定，且具有完整的公共API组织以及一定的扩展性，个人认为是时候发布v1.0.0版本，标志其功能已经达到稳定。在正式发布之前，还有如下的事项需要处理：

• 精简 api 界面，删除不必要的导出
  • 删除不常用的子包导出
  • 删除不必要的实体接口
  • 重命名SocketBuilderRegistry为SocketDeserializerRegistry
  • Battle下导出全部重新组织
• SEAPet 更换更优雅的链式调用 api
• 重新组织导出
  • 不再有子包导出
  • seac作为核心实例用于控制全局副作用
  • Strategy模块重写, 提供更加方便优雅的 api, 且统一大部分操作
    • 新 api 以纯函数式方式实现，包括技能对点，自动，第五，攻击
  • 更名
    • SEAPet -> spet
    • GameConfigRegistry.getQuery -> query
    • extendEngine -> engine.extend
    • Engine -> engine
    • SEABattle -> battle
• 启用单元测试
• 查询关卡获取的因子数量
• 查询魂印激活放到 SEAPet 中
  • 修复为同步实现
• 解耦登录器/后端特定逻辑，分离非核心功能，部分由登录器提供扩展定义, 合并到engine中, 部分由@sea/mod-presets实现
  • script 解密(后端)
  • 对战显血(模组)
  • 自动关弹窗(模组)
  • logFilter(后端+登录器)
• LevelRunner使用事件流
• 对于 CoreLoader 的注册 hook，提供标志位来进行功能的打开，关闭
  • 同时公开 hook 数组，以便登录器层可以开关特定功能
• 集成测试作为单独的包，移出 @sea/core
• 日志模块重写，输出 object 而不是消息，可以子 logger 化，规范化行为
  • 为hook添加日志
• 删除dev标志
• hookConstructor删除实验性标志
• 验证第五和魂印判断的正确性
• 战斗延迟可以在battle中进行配置

website

• 移出到单独的仓库，在有精力写文档和打理之前，先使用本仓库的简版文档
• 配色修改（如果简单的话）
• 设置push自动部署的ci
• 删除blog功能
• 首页整理一下
• 重写readme，分割roadmap，quick start，添加截图和常见QA，目标：让有一定动手能力的人目前可以把项目跑起来，安装模组
  • 这个项目在干什么
  • 基本运行原理（需要有一定知识储备）
  • 开发进度和目前可用性
  • 预期正式发布日期
  • quick start
    • 模组安装
  • 如何获取更新通知（开个discuss，等dc群建好）

launcher / server v0.9.2

• 对data和config存储添加版本字段
• 内置模组的整个初始化流程更改
  • 不再有安装步骤，而是用特殊的端点通知后端内置模组的加载
• task移入redux存储，编写相关切片
• 模组管理功能
  • 禁用启用
  • 重载
  • 优先级配置
  • 本地安装时显示perfetch信息
  • 查看详情
  • 出错处理
• 日志重构（待定）
• 部署时区分全部部署和单个部署
• 简化情况，拒绝循环依赖和多层依赖
• 模组更新处理（待定）
• 在线安装模组（待定）

mod-resolver / mod-type v1.0.0

• 抽象准备安装端点所需的逻辑
• 安装时附带完整metadata
• 可选的主页和作者字段
• 表示支持热重载的标志位
• 增加只能在登录器由用户配置的加载优先级
• 元数据附带对等依赖
  • 包括对core和mod-type的依赖

toolchain

• 引入changeset
  • (launcher / server) / (mod-resolver / mod-type)维持主版本和次版本一致
• 重构构建脚本（待定）

迁移后端至ts

全面启用typescript，之后进一步将使用tRPC和websocket来支持前后端之间的交互