Closed Xm798 closed 2 years ago
米忽悠,你把人变成鬼
这么一来,不光是我们项目,深渊黑白榜也全爆炸了啊
米忽悠,你把人变成鬼
这么一来,不光是我们项目,深渊黑白榜也全爆炸了啊
是的 深渊排行也无了
https://github.com/Arondight/Adachi-BOT/issues/399#issuecomment-970196910
我感觉这个问题发生的原因很大可能是使用了非本人cookie
什么嘛,我猜bug原因还蛮准的……
估计得改改深渊样式了,游戏公司方面不太可能改了,这数据估计耽误赚钱了
Ref #404
不知道会不会进一步限制
怎么连这都改,他们程序员上班就干这个?
完全废掉的功能有:
我的
,那么 #424 的后端部分就可以暂时不做了半残的功能有:
米游社
深渊
以上功能都只要改前端,只有我受伤的世界完成了
做还是要做的,就还得把提示信息改改了
我下午把代码打个 tag ,省的以后官方反复横跳找起来难受
这周先看看黑白榜怎么处理这件事,这俩如果改成自行上传 cookie ,那基本上就没办法了,后续再看看要不要跟进,如果 cookie 满天飞那我们死活不做这功能也没意义,这个加起开倒是好加
大概是前几天的那个小程序吧,搞账号估价,还拿来盈利,搞的规模太大了
这周先看看黑白榜怎么处理这件事,这俩如果改成自行上传 cookie ,那基本上就没办法了,后续再看看要不要跟进,如果 cookie 满天飞那我们死活不做这功能也没意义,这个加起开倒是好加
自行上传肯定是不会传的……
大概是前几天的那个小程序吧,搞账号估价,还拿来盈利,搞的规模太大了
跟这个没关系,单纯是游戏公司不太行,角色做的不平衡,所以也不敢放数据。魔兽世界一直开放英雄榜和各种榜单也没见因为这事黄了,玩魔兽大家都是月卡不服你也练一个,玩原神不行,你知道几千块钱抽的没人白嫖的厉害就会不开心。单纯是游戏质量有问题,不应该指责那个小程序,他只不过统计了官方的公开数据
大概是前几天的那个小程序吧,搞账号估价,还拿来盈利,搞的规模太大了
跟这个没关系,单纯是游戏公司不太行,角色做的不平衡,所以也不敢放数据。魔兽世界一直开放英雄榜和各种榜单也没见因为这事黄了,玩魔兽大家都是月卡不服你也练一个,玩原神不行,你知道几千块钱抽的没人白嫖的厉害就会不开心。单纯是游戏质量有问题,不应该指责那个小程序,他只不过统计了官方的公开数据
但不能否认的是那个小程序确实引起了很多氪佬的不满…而氪佬都是有专属客服的
所以目前来说我们的 bot 在查询官方数据这块意义就比较小了,以后我会想想还有什么能做的事情,不过好在还能查一点零星的数据,如果以后数据进一步管制的话,估计各种项目都会没啥用了,那时候我就把这个项目归档了
米忽悠,你把人变成鬼
这么一来,不光是我们项目,深渊黑白榜也全爆炸了啊
提交深渊战绩时顺带提交ltuid和login_ticket(雾)
我感觉先临时处理一下吧,好像只有米游社不让看了,也可能是个暂时性的,可怜的白榜是死翘翘了,黑榜倒是没影响
我刚发了个版当归档用了,以后如果官方放开数据改回来也方便
说是暂不支持,真要大规模 cookie 自由估计 mhy 更头疼
肯定对外说是“暂”不支持呀,但是究竟会暂多久呢,话语权就掌握在mhy手上了 就像睿叔叔暂不支持海外IP直播暂了两年,现在也可以继续暂下去
我稍微改了一下深渊是否存在详细楼层信息的判断, https://github.com/Mark9804/Adachi-BOT/commit/4941ed895b50b0a5fe4e652cb3b437bec02243e3 , 但是具体文案要怎么写让用户能看懂我还在考虑, 因为假如我们说“mhy已禁止查询他人信息”,用户会很迷惑,我明明查的是我自己的号啊怎么就成他人了
米游社那边就很怪异,能查到几个人的,但是不能查看全部角色。我考虑在角色的 container 后面跟一句说明,但是这句说明应该怎么写我也没想好
hoyolab 也改了,看来是不会改回去了
所以不要考虑怎么说明了,以后直接改一下布局吧,只显示官方让显示的数据
b48cff9599a05866561159bc6bde4a294326739a , 83be53b51fa8660d8647ea833eadb2a52d99ad28
我在dev
分支屏蔽了精确到层的数据模块
如果没有查询到floor信息的话,就不会显示;
如果将来米爹大发慈悲放开了,这个网页也会立刻响应变化
我现在想把横向排版的网页改成纵向,还好当时重写的比较早,现在只要改最外层 container 的排列参数然后微调一下其他边距就可以了,但是米游社
的页面我暂时拿它没有办法
@Mark9804 做得好啊老大哥,另外我看黑榜公告似乎他们不死心的样子,或许未来还有转机吧
突然就被限制了,我fork的只好加了私人Cookie判断。用自己的Cookie是可以查的,而且数据和接口完全一致Orz
闲来无事,做点别的插件玩玩吧(悲)
闲来无事
也不能算闲来无事, Arondight 想要整合一个正经数据库,我要对米游社和深渊前端下手了,短时间内应该不会有什么新功能做出来,但是如果你有什么好想法的话之后说不定也会做的
只好加了私人Cookie判断
如果最后搞成 cookie 满天飞,大家都开始满不在乎地把 cookie 交给各种网站,那我再坚持也就没意义了,不过我还是不希望有那一天把,用隐私换方便我不反对,用安全换方便我就比较抵触了
可以参考一下我的 还有待测试
可以参考一下我的 还有待测试
是 https://github.com/KimigaiiWuyi/GenshinUID/commit/82ad1efb19837dbbded18f066e921e8f1fe553bf 这个commit吗?
可以参考一下我的 还有待测试
是 KimigaiiWuyi/GenshinUID@82ad1ef 这个commit吗?
是的,可以只看getImg.py
的改动
是的,可以只看
getImg.py
的改动
感谢,虽然看起来相当暴力,但是也提供了一种可能性
是可以正常获取到所有信息,唯一的疑虑就是,会不会因为多线程,被mhy当成DDos然后banip
大致看了一下,周末再说吧,每个 uid 大概得查四五十次,查多了不知道 bot 还能活着么
我觉得这个接口应该是不会被改的,至少有了一种获取数据的方法,周末我看有空就跟进一下
@KimigaiiWuyi 你那里如果使用有异常的话麻烦说一下,毕竟短时间内几个人查这就是二三百次请求,我担心有点多了
@KimigaiiWuyi 你那里如果使用有异常的话麻烦说一下,毕竟短时间内几个人查这就是二三百次请求,我担心有点多了
我是小群用,群成员加起来不过六十多个,不可能会有那么大的请求量,我主要是怕其他用户用了会被BanIP,所以想请你们测一测,(顺带防一手mhy玩不起,八个线程就给我BanIP)
@KimigaiiWuyi 你那里如果使用有异常的话麻烦说一下,毕竟短时间内几个人查这就是二三百次请求,我担心有点多了
我是小群用,群成员加起来不过六十多个,不可能会有那么大的请求量,我主要是怕其他用户用了会被BanIP,所以想请你们测一测,(顺带防一手mhy玩不起,八个线程就给我BanIP)
但不开多线程就十分慢了,所以这方面我就分享出来,这边人多可以多测试,但还是希望不要大范围传播(虽然大多数人迟早会知道)
那几乎不用测了,肯定会被ban 的,用 bot 群用户数量从几百到一两万的都有,八线程都被ban 了,那肯定跑不了
那几乎不用测了,肯定会被ban 的,用 bot 群用户数量从几百到一两万的都有,八线程都被ban 了,那肯定跑不了
我的意思是 我没被ban,但是怕
原来如此,我有空搞一下,主要是我被ban了之后也挺麻烦的,我想周末先看一下黑白榜的反应吧,另外似乎你这直接挂个脚本跑一下压测也可以知道是不是会被ban,就是无论公司还是vps被ban就很难受
白榜黑榜也有大量请求的需要,他们是怎么做到的,服务器集群吗?我感觉他们不像是有钱到不在意这个支出的团队
因为他们的数据不要求这么精确的时效性,我猜测他们的做法是把请求数量在某个时段(比如全天)之内平均分配,我们是不是可以效仿这种做法?就像搜索引擎一样,先用 spider 把全网数据扒下来,用户发送查询请求的时候使用这些缓存来处理用户请求
换句话说,以后用户查询米游社
就真的是在纯调用缓存了,
不过看起来我的
这个功能给这么一整是可以复活的,直接通过角色名查表获得角色ID,然后向对应API发送请求就可以了
原来如此,我有空搞一下,主要是我被ban了之后也挺麻烦的,我想周末先看一下黑白榜的反应吧,另外似乎你这直接挂个脚本跑一下压测也可以知道是不是会被ban,就是无论公司还是vps被ban就很难受
无论VPS还是公司或者家里的IP 我都不想被Ban,只能push到开源社区让大家评估一下了; 另外黑白榜无论难不难受,从这次国际服同步那么快看来,mhy估计不可能放出深渊信息查询了(只是我感觉); 第三点是这个方法既然能用,那当然要想想怎么保护好,而不是瞬间几千个访问,让mhy第二天就封掉,所以希望各位测试谨慎点; 第四点是,也许可以不用暴力遍历,有方法可以先获取到前8个,然后再把常见4星(御三家+国家队)给获取了,剩下的再遍历
@MiniGrayGay 小白鼠来了
@SilveryStar 老大哥瞅一瞅
@MiniGrayGay 小白鼠来了
我和小灰灰今天下午就在研究了(
哈哈哈,你扯上灰灰那还保护了个啥,他其中一个 bot 就快六万个用户,分分钟上千请求不是小意思 🤣
怎么看封账号的概率都比封ip概率大的多
哈哈哈,你扯上灰灰那还保护了个啥,他其中一个 bot 就快六万个用户,分分钟上千请求不是小意思 🤣
正常测试没办法,以后总会有人发现这个方法的
我觉得我们重新思考一下米游社
这个功能的需求场景吧
我群里使用米游社
的更多作用主要是用来“更新角色数据”,然后才是“查看自己已经拥有的角色图鉴”,最后是“查看自己的统计数据”
那么从这个角度来说的话,我们也许不需要强行认为【只要有用户发送米游社
指令,我们就必须给他一个完整的角色列表】
比如说啊,比如说,我们的功能调整成只有当用户输入是米游社 --all
的时候才强制获取一遍用户的所有角色信息,剩下的时候我们只需要给他返回八个角色,就足够了。当用户使用我的
指令的时候,先看一看这八个角色里面有没有他的,如果没有,那么再用这个方法请求对应的角色,然后缓存进这个用户的数据库当中