median-dxz
median-dxz
# 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版本，标志其功能已经达到稳定。在正式发布之前，还有如下的事项需要处理： - [x] 精简 api 界面，删除不必要的导出...
电池相关的逻辑都还在，但是UI上被硬编码为满电100%，意义不明。 ~~还未验证5小时之后能否正常不获得经验~~，可能考虑写个mod把电池显示加回去。 UPD: 已验证5小时后无经验获取的机制仍然存在。
举例说明，精灵王日任关卡挑战的是困难难度，那么对于还没解锁困难难度的萌新，在使用该关卡时，关卡应该抛出异常让登录器的任务调度器(taskScheduler)去处理还是使用状态机自行处理？如果自行处理，根据目前的架构设计思路，next函数是否应该返回一个特定的错误状态？还是在data中置一个errno属性，然后自陷一个通用的error状态？ 而且说回来，有必要区分前置条件不满足（可以在update函数中判断出）和意外错误导致的关卡无法运行吗？ 目前的大部分自由度交由关卡模组本身来处理。TaskRunner并没有能和登录器交互的接口为logger和错误捕获，和LevelRunner的交互是特定Action和错误捕获，有必要增加交互方式吗？
到达上限后出错
鉴于淘米对待H5版本的态度和目前Unity版本的情况，本项目进入归档倒计时，具体措施如下： 1. 不再接受新的Issue和PR 2. 积极尝试迁移本项目到Unity版本，但是不做保证 3. 如果2实现，则归档本项目 4. 在2实现之前，本项目只进行影响登录器正常使用的修复更新，不再进行任何功能性和架构性更新 如果你想为Unity版本的开发填一份力，欢迎加入我们的dc群组进行交流讨论！ UPD: SEAL-H5目前支持解锁H5 UI（通过左下角快捷按钮进入对应界面）和新版U端因子（通过自动对战->因子面板添加配置，并支持自动/手动/扫荡对战） UPD：25/09/05 H5端口已经关闭，本项目正式归档。
**Note: This PR is currently undergoing beta testing** This will close issues: #1655 #1634 So, this is quite a big PR. I've already outlined my changes in [#10](https://github.com/median-dxz/Cookie-AutoDelete-MV3/issues/10), and there...
I used the latest Three.js as a peer dependency, but the bundler complains with `Could not resolve "three/examples/jsm/WebGL"` in [background-renderer.ts](https://github.com/aeroheim/midori/blob/master/src/background-renderer.ts). If you could spare some time to update the peer...