Mark Chen
Mark Chen
不平行，米游社布局是米游社布局，游戏内展柜是游戏内展柜，顶天是把两个 API 获取的数据合并
我主要是没太理解这个目标 > 机器人中插件通过选项来判定使用哪套 API 假设某个用户游戏内展柜中只放了一个迪卢克，米游社展柜中有旅行者和迪卢克，机器人选项设置使用 enka api 查询 那么当用户查询 “我的旅行者” 的时候，应该返回 “未找到角色” 还是使用米游社的结果？
分开两个指令我觉得对于一般用户来说不是特别友好，如果项目面向的是开发者，他们很容易理解为什么有两个指令分别做不同的事情；但是对于一般用户很难理解 比如说 > 配置使用 mys 逻辑，则所有的数据和展示以 mys 为准， bot 也不会去请求 enka 。 用户会问我明明米游社展柜里面放了 xxx 角色啊，为什么告诉我找不到这个角色？/我游戏展柜放了 xxx 角色啊，为什么不能展示面板数据？ 所以如果是我个人的话更倾向于新加一个 `properties` 字段用来存储角色面板，就扔在现有的米游社数据库里面 仅作参考，人人都恨产品经理，人人都是产品经理
因为项目有米游社 ID 的用户习惯，又因为通过米游社 ID 是可以查到游戏内 UID 的，所以我还是觉得以米游社为主，第一次查询的时候两个 API 都查，融合一下然后扔进数据库里面备用，这样还是可以用 `我的xx` 进行查询，查询逻辑也不用改，反正查到了就直接扔出来就完事了。前端检查有没有 ·properties· 属性，如果有的话就展示额外的面板信息
response sample https://gist.github.com/Mark9804/d20e781a9b8b87ace2089fad49746e47
那我一边摸论文一边画原型图了
不急，是我两年后的毕业论文，做个数据分析就能结束了，但是就硬摸
圣遗物主属性忘加了
今天米忽悠楼上的莉莉丝密接了，不知道 3.0 能不能顶得住
> 没得五星吗 暂时不能放吧，放了都攒水晶抽草萝莉去了