User:CppHusky/WhyHaven'tWeDeterminedArcaea'sPttAlgorithm:修订间差异
小 (加了一些标签,不知道能不能用。) |
小 (修引用) |
||
(未显示同一用户的7个中间版本) | |||
第1行: | 第1行: | ||
<h1> 为什么我们还没有确定arcaea的潜力值(ptt)算法</h1><br> | |||
(关于ptt算法的问题就不要再说我们维基咕咕咕了) | (关于ptt算法的问题就不要再说我们维基咕咕咕了) | ||
<h2> 我们通过什么了解ptt算法?</h2> | |||
“任何编辑者应当且仅应当信任拆包的数据/服务器返回的数据/游戏本身返回的精度足够的数据,并对任何不是此来源的数据持怀疑态度。”——维基方针<br> | |||
在ptt算法问题上,维基的态度是尤为严苛的。 | 在ptt算法问题上,维基的态度是尤为严苛的。<br> | ||
事实上,移动端arcaea的ptt相关信息都是保存在lowiro服务器内的,arcaea的安装包本身并没有ptt算法的代码,更遑论解读获知ptt算法。 | 事实上,移动端arcaea的ptt相关信息都是保存在lowiro服务器内的,arcaea的安装包本身并没有ptt算法的代码,更遑论解读获知ptt算法。<br> | ||
通过lowiro的API我们能够获知的数据为:玩家的ptt,所有曲目上传到服务器的最高分等,这些信息是我们反推ptt算法的基础。 | 通过lowiro的API我们能够获知的数据为:玩家的ptt,所有曲目上传到服务器的最高分等,这些信息是我们反推ptt算法的基础。<br> | ||
游戏本身返回的ptt数据精度还不如服务器给的数据,其它数据精度基本上也不会超过服务器返回的数据,所以基本不在考虑范围内。 | 游戏本身返回的ptt数据精度还不如服务器给的数据,其它数据精度基本上也不会超过服务器返回的数据,所以基本不在考虑范围内。<br> | ||
NS端的情况则要好一些,因为NS的ptt是断网结算的。通过拆包,可以获知算法的有关信息。然而这不是直接获取源代码!完整的源代码只能从lowiro的程序员处获取,这样的可能性几近于零。 | NS端的情况则要好一些,因为NS的ptt是断网结算的。通过拆包,可以获知算法的有关信息。然而这不是直接获取源代码!完整的源代码只能从lowiro的程序员处获取,这样的可能性几近于零。<br> | ||
<h2>arcaea的ptt算法经历了什么?</h2> | |||
在3.0.0版本配信之前,已经有明确的B30/R10机制共识,即以下公式: | 在3.0.0版本配信之前,已经有明确的B30/R10机制共识,即以下公式:<br> | ||
::<b>ptt=(30×B30均值+10×R10均值)÷40</b> | ::<b>ptt=(30×B30均值+10×R10均值)÷40</b><br> | ||
详细的机制不是本文的重点,此处不展开。 | 详细的机制不是本文的重点,此处不展开。<br> | ||
在3.0.0版本之后,官方表态“潜力值的计算方式也将被改动”,但维基并没有足够的能力将新的ptt算法解出。因此,目前维基的潜力值信息<b>基本沿用了3.0.0以前的内容</b>。 | 在3.0.0版本之后,官方表态“潜力值的计算方式也将被改动”,但维基并没有足够的能力将新的ptt算法解出。因此,目前维基的潜力值信息<b>基本沿用了3.0.0以前的内容</b>。<br> | ||
目前维基的共识为:“现在维基的潜力值页面几乎肯定是错误的。”相应地,潜力值页面也标注了“不准确”字样。 | 目前维基的共识为:“现在维基的潜力值页面几乎肯定是错误的。”相应地,潜力值页面也标注了“不准确”字样。<br> | ||
那么我们为什么还在使用“不准确”的信息?维基管理员sxy的回答是“只是因为 没有 更对的 表述”。 | 那么我们为什么还在使用“不准确”的信息?维基管理员sxy的回答是“只是因为 没有 更对的 表述”。<br> | ||
一言以蔽之,<u>目前维基的描述已经尽力接近真实的ptt算法了</u>。 | 一言以蔽之,<u>目前维基的描述已经尽力接近真实的ptt算法了</u>。<br> | ||
<h2> 关于ptt算法,维基走到了哪一步?</h2> | |||
NS拆包结果表明,<b>NS端ptt算法是一个(30+10)÷40的算法</b>。 | NS拆包结果表明,<b>NS端ptt算法是一个(30+10)÷40的算法</b>。<br> | ||
其中的30个数据很有可能是B30值,但另外10个数据如何选取,我们不得而知。 | 其中的30个数据很有可能是B30值,但另外10个数据如何选取,我们不得而知。<br> | ||
我们猜测这个R10是从R30中经过【某种机制】选出来的,但是我们又怎能确定R30是用何种机制选取的? | 我们猜测这个R10是从R30中经过【某种机制】选出来的,但是我们又怎能确定R30是用何种机制选取的?<br> | ||
而这里的【某种机制】并不像是一种类似于时间顺序的简单机制,已有的猜测都被实验证伪了。sxy表示:“你所想的所有的简单想法别人和我们都想过了。” | 而这里的【某种机制】并不像是一种类似于时间顺序的简单机制,已有的猜测都被实验证伪了。sxy表示:“你所想的所有的简单想法别人和我们都想过了。”<br> | ||
除此之外,R30更迭机制还会受到一种所谓的<b>“EX保护机制”</b>影响,但3.0.0以后这个机制是否还如同原来一样?不得而知。3.0.0以前的EX保护机制使得玩家在达到EX评级时不会再因为R30更新而导致ptt降低。然而,目前出现了<b>排除多设备登录影响下达到EX但扣ptt的情况</b>,但只是“零星的报告”(罕见),查证也很困难。而对应的,NS端并没有EX保护机制(实验支撑),那么移动端ptt算法是否也是如此?如果不是如此(EX保护机制确实存在),就说明NS与移动端ptt算法不一致,那我们又如何敢确定NS拆包得到的(30+10)÷40和移动端是一致的呢? | 除此之外,R30更迭机制还会受到一种所谓的<b>“EX保护机制”</b>影响,但3.0.0以后这个机制是否还如同原来一样?不得而知。3.0.0以前的EX保护机制使得玩家在达到EX评级时不会再因为R30更新 | ||
除了EX保护机制存在争议以外,另一个点也存在争议,那就是Recent数据是否参与ptt的计算。sxy表示”官方API只返回30个数据而且看起来是B30”,而R10数据不得而知;NS拆包的结果是“没有R10这个桶”,这暗示着或许NS端公式中的10个所谓Recent数据其实是另有来源?是否来源于B30?但如果这样就无法解释ptt数据大幅度的漂移。问题来了,NS端没有R10这个桶,那么移动端是否有?如果没有,那么这10个数据来自哪里?如果有,那么NS和移动端的ptt算法就显然不一致了,上述NS公式就一定能在移动端成立吗? | 而导致ptt降低。然而,目前出现了<b>排除多设备登录影响下达到EX但扣ptt的情况</b>,但只是“零星的报告”(罕见),查证也很困难。而对应的,NS端并没有EX保护机制(实验支撑),那么移动端ptt算法是否也是如此?如果不是如此(EX保护机制确实存在),就说明NS与移动端ptt算法不一致,那我们又如何敢确定NS拆包得到的(30+10)÷40和移动端是一致的呢?<br> | ||
<i>注:移动端查分器会返回R10均值数据,但是这个R10均值并非由lowiro的API直接返回,而是通过lowiro的API所返回的ptt和B30数据套用旧公式进行计算得到的。查分器的查分结果并不能证明R10是确实存在的</i> | 除了EX保护机制存在争议以外,另一个点也存在争议,那就是Recent数据是否参与ptt的计算。sxy表示”官方API只返回30个数据而且看起来是B30”,而R10数据不得而知;NS拆包的结果是“没有R10这个桶”,这暗示着或许NS端公式中的10个所谓Recent数据其实是另有来源?是否来源于B30?但如果这样就无法解释ptt数据大幅度的漂移。问题来了,NS端没有R10这个桶,那么移动端是否有?如果没有,那么这10个数据来自哪里?如果有,那么NS和移动端的ptt算法就显然不一致了,上述NS公式就一定能在移动端成立吗?<br> | ||
当然,上述讨论还是建立在<b>“移动端与NS的ptt算法一致”</b>的假设下的。如果不一致呢?这样我们关于ptt的研究还要有大篇幅作废。 | <i>注:移动端查分器会返回R10均值数据,但是这个R10均值并非由lowiro的API直接返回,而是通过lowiro的API所返回的ptt和B30数据套用旧公式进行计算得到的。查分器的查分结果并不能证明R10是确实存在的</i><br> | ||
之前arcaea圈内就出现了ptt12.88的情况,但用现有模型计算的ptt最高值也只能有12.87,这也从一个侧面反映了目前已有ptt算法是仍有问题的。然而,这种问题不是我们这么少的人在短时间内可以解决的。 | 当然,上述讨论还是建立在<b>“移动端与NS的ptt算法一致”</b>的假设下的。如果不一致呢?这样我们关于ptt的研究还要有大篇幅作废。<br> | ||
之前arcaea圈内就出现了ptt12.88的情况,但用现有模型计算的ptt最高值也只能有12.87,这也从一个侧面反映了目前已有ptt算法是仍有问题的。然而,这种问题不是我们这么少的人在短时间内可以解决的。<br> | |||
<h2> 结语</h2> | |||
维基群里经常有新人在问ptt算法的事,每次都需要管理员反复解释。这是一件费时费力的工作,因此我写出本文,旨在告知有这样困惑的朋友,解出这个ptt的算法是一件多么困难的工作。 | 维基群里经常有新人在问ptt算法的事,每次都需要管理员反复解释。这是一件费时费力的工作,因此我写出本文,旨在告知有这样困惑的朋友,解出这个ptt的算法是一件多么困难的工作。 | ||
我的建议是,与其在这个几乎不可能解出来的算法上耽误过多的时间,不如去做一些其它的工作。就算是多玩一会儿arcaea也是好的。 | 我的建议是,与其在这个几乎不可能解出来的算法上耽误过多的时间,不如去做一些其它的工作。就算是多玩一会儿arcaea也是好的。<br> | ||
如果ptt算法破解方面有了新的进展,也请第一时间关注维基动向,因为维基无疑是国内arcaea信息最严谨、最可靠的提供方。 | 如果ptt算法破解方面有了新的进展,也请第一时间关注维基动向,因为维基无疑是国内arcaea信息最严谨、最可靠的提供方。<br> | ||
<hr> | |||
written by cppHusky, 6/19/2022 | written by cppHusky, 6/19/2022 |
2022年6月19日 (日) 23:38的最新版本
为什么我们还没有确定arcaea的潜力值(ptt)算法
(关于ptt算法的问题就不要再说我们维基咕咕咕了)
我们通过什么了解ptt算法?
“任何编辑者应当且仅应当信任拆包的数据/服务器返回的数据/游戏本身返回的精度足够的数据,并对任何不是此来源的数据持怀疑态度。”——维基方针
在ptt算法问题上,维基的态度是尤为严苛的。
事实上,移动端arcaea的ptt相关信息都是保存在lowiro服务器内的,arcaea的安装包本身并没有ptt算法的代码,更遑论解读获知ptt算法。
通过lowiro的API我们能够获知的数据为:玩家的ptt,所有曲目上传到服务器的最高分等,这些信息是我们反推ptt算法的基础。
游戏本身返回的ptt数据精度还不如服务器给的数据,其它数据精度基本上也不会超过服务器返回的数据,所以基本不在考虑范围内。
NS端的情况则要好一些,因为NS的ptt是断网结算的。通过拆包,可以获知算法的有关信息。然而这不是直接获取源代码!完整的源代码只能从lowiro的程序员处获取,这样的可能性几近于零。
arcaea的ptt算法经历了什么?
在3.0.0版本配信之前,已经有明确的B30/R10机制共识,即以下公式:
- ptt=(30×B30均值+10×R10均值)÷40
- ptt=(30×B30均值+10×R10均值)÷40
详细的机制不是本文的重点,此处不展开。
在3.0.0版本之后,官方表态“潜力值的计算方式也将被改动”,但维基并没有足够的能力将新的ptt算法解出。因此,目前维基的潜力值信息基本沿用了3.0.0以前的内容。
目前维基的共识为:“现在维基的潜力值页面几乎肯定是错误的。”相应地,潜力值页面也标注了“不准确”字样。
那么我们为什么还在使用“不准确”的信息?维基管理员sxy的回答是“只是因为 没有 更对的 表述”。
一言以蔽之,目前维基的描述已经尽力接近真实的ptt算法了。
关于ptt算法,维基走到了哪一步?
NS拆包结果表明,NS端ptt算法是一个(30+10)÷40的算法。
其中的30个数据很有可能是B30值,但另外10个数据如何选取,我们不得而知。
我们猜测这个R10是从R30中经过【某种机制】选出来的,但是我们又怎能确定R30是用何种机制选取的?
而这里的【某种机制】并不像是一种类似于时间顺序的简单机制,已有的猜测都被实验证伪了。sxy表示:“你所想的所有的简单想法别人和我们都想过了。”
除此之外,R30更迭机制还会受到一种所谓的“EX保护机制”影响,但3.0.0以后这个机制是否还如同原来一样?不得而知。3.0.0以前的EX保护机制使得玩家在达到EX评级时不会再因为R30更新
而导致ptt降低。然而,目前出现了排除多设备登录影响下达到EX但扣ptt的情况,但只是“零星的报告”(罕见),查证也很困难。而对应的,NS端并没有EX保护机制(实验支撑),那么移动端ptt算法是否也是如此?如果不是如此(EX保护机制确实存在),就说明NS与移动端ptt算法不一致,那我们又如何敢确定NS拆包得到的(30+10)÷40和移动端是一致的呢?
除了EX保护机制存在争议以外,另一个点也存在争议,那就是Recent数据是否参与ptt的计算。sxy表示”官方API只返回30个数据而且看起来是B30”,而R10数据不得而知;NS拆包的结果是“没有R10这个桶”,这暗示着或许NS端公式中的10个所谓Recent数据其实是另有来源?是否来源于B30?但如果这样就无法解释ptt数据大幅度的漂移。问题来了,NS端没有R10这个桶,那么移动端是否有?如果没有,那么这10个数据来自哪里?如果有,那么NS和移动端的ptt算法就显然不一致了,上述NS公式就一定能在移动端成立吗?
注:移动端查分器会返回R10均值数据,但是这个R10均值并非由lowiro的API直接返回,而是通过lowiro的API所返回的ptt和B30数据套用旧公式进行计算得到的。查分器的查分结果并不能证明R10是确实存在的
当然,上述讨论还是建立在“移动端与NS的ptt算法一致”的假设下的。如果不一致呢?这样我们关于ptt的研究还要有大篇幅作废。
之前arcaea圈内就出现了ptt12.88的情况,但用现有模型计算的ptt最高值也只能有12.87,这也从一个侧面反映了目前已有ptt算法是仍有问题的。然而,这种问题不是我们这么少的人在短时间内可以解决的。
结语
维基群里经常有新人在问ptt算法的事,每次都需要管理员反复解释。这是一件费时费力的工作,因此我写出本文,旨在告知有这样困惑的朋友,解出这个ptt的算法是一件多么困难的工作。
我的建议是,与其在这个几乎不可能解出来的算法上耽误过多的时间,不如去做一些其它的工作。就算是多玩一会儿arcaea也是好的。
如果ptt算法破解方面有了新的进展,也请第一时间关注维基动向,因为维基无疑是国内arcaea信息最严谨、最可靠的提供方。
written by cppHusky, 6/19/2022