Open Arondight opened 2 years ago
后续相关问题在此讨论
不平行,米游社布局是米游社布局,游戏内展柜是游戏内展柜,顶天是把两个 API 获取的数据合并
不平行,米游社布局是米游社布局,游戏内展柜是游戏内展柜,顶天是把两个 API 获取的数据合并
需要平行,因为 enka 可能会嗝屁,但是米游社可以认为不会,要支持 enka 就必须同时维护米游社的 api 数据展示
米游社布局是米游社布局,游戏内展柜是游戏内展柜
可能没表达清楚,我是觉得“我的迪卢克”应当支持两套 api 和对应的网页,米游社官方的一套和三方 enka 的一套
我主要是没太理解这个目标
机器人中插件通过选项来判定使用哪套 API
假设某个用户游戏内展柜中只放了一个迪卢克,米游社展柜中有旅行者和迪卢克,机器人选项设置使用 enka api 查询
那么当用户查询 “我的旅行者” 的时候,应该返回 “未找到角色” 还是使用米游社的结果?
应该返回 “未找到角色” 还是使用米游社的结果
两套逻辑独立工作,完全平行的,例如配置使用 mys 逻辑,则所有的数据和展示以 mys 为准, bot 也不会去请求 enka 。
中间不发生关联
分开两个不同指令就是咯,我那项目是enka的独立一套指令(更新8个角色面板和查询单独角色),mys的照旧,用户自己发不同指令来选择 (不过有了enka之后就没人看mys的了..)
分开两个指令我觉得对于一般用户来说不是特别友好,如果项目面向的是开发者,他们很容易理解为什么有两个指令分别做不同的事情;但是对于一般用户很难理解
比如说
配置使用 mys 逻辑,则所有的数据和展示以 mys 为准, bot 也不会去请求 enka 。
用户会问我明明米游社展柜里面放了 xxx 角色啊,为什么告诉我找不到这个角色?/我游戏展柜放了 xxx 角色啊,为什么不能展示面板数据?
所以如果是我个人的话更倾向于新加一个 properties
字段用来存储角色面板,就扔在现有的米游社数据库里面
仅作参考,人人都恨产品经理,人人都是产品经理
确实,有的人分不清游戏内展柜和米游社展柜,会因为懒得上游戏换角色而不用
所以我一直没做单独角色的页面,只展示圣遗物套装个人觉得意义不大; enka API上线之后 角色面板 也只调用enka API
因为项目有米游社 ID 的用户习惯,又因为通过米游社 ID 是可以查到游戏内 UID 的,所以我还是觉得以米游社为主,第一次查询的时候两个 API 都查,融合一下然后扔进数据库里面备用,这样还是可以用 我的xx
进行查询,查询逻辑也不用改,反正查到了就直接扔出来就完事了。前端检查有没有 ·properties· 属性,如果有的话就展示额外的面板信息
第一次查询的时候两个 API 都查
只调用enka API
@KimigaiiWuyi 但是没人保证 enka 的稳定性,甚至官方简单的增加一个查询间隔就足够废掉 enka ,他本身的运营模式(未来是否付费以及是否长期运营)没有保证,我觉得全部转移过去不是个好办法
只调用enka API
@KimigaiiWuyi 但是没人保证 enka 的稳定性,甚至官方简单的增加一个查询间隔就足够废掉 enka ,他本身的运营模式(未来是否付费以及是否长期运营)没有保证,我觉得全部转移过去不是个好办法
嗯 限于我原本没有角色面板查询(只是个人觉得只看圣遗物套装意义不大),所以直接 用全部调用enka的方式 关于enka未来的模式,我和enka的作者dc上聊过一段时间,目前他服务器应该可以承载大量访问(暂时) 所以对我来说就直接全用他那边的数据就好了
生活安顿下来了,真不容易,准备休息半个月,这个月底开始做
那我一边摸论文一边画原型图了
那我一边摸论文一边画原型图了
你先忙你的
不急,是我两年后的毕业论文,做个数据分析就能结束了,但是就硬摸
圣遗物主属性忘加了
先做完 #811 ,然后照着楼上抄(特指代码)
继续鸽
继续鸽,希望月底有空做
猴年马月预定
啊哈哈哈哈哈,监工来咯,让我看看两绿皮苦工有没有偷懒
没有偷懒,直接躺平
i am 正在享受 life & 做🐮🐎
我也在做🐮🐎&灵活奋斗
没有偷懒,直接躺平
好家伙,居然不内卷了
脖子都卷断了,再卷连福报都享受不到
问题描述
目标
文档
计划
没有计划,未来有意向做
其他
当前提交