User:CppHusky/WhyHaven'tWeDeterminedArcaea'sPttAlgorithm：修订间差异

来自Arcaea中文维基
（创建页面，内容为“==为什么我们还没有确定arcaea的潜力值（ptt）算法== （关于ptt算法的问题就不要再说我们维基咕咕咕了） * 我们通过什么了解p…”）
 
第2行： 第2行：
 （关于ptt算法的问题就不要再说我们维基咕咕咕了）
 （关于ptt算法的问题就不要再说我们维基咕咕咕了）
* 我们通过什么了解ptt算法？
* 我们通过什么了解ptt算法？
: “任何编辑者应当且仅应当信任拆包的数据/服务器返回的数据/游戏本身返回的精度足够的数据，并对任何不是此来源的数据持怀疑态度。”——维基方针
“任何编辑者应当且仅应当信任拆包的数据/服务器返回的数据/游戏本身返回的精度足够的数据，并对任何不是此来源的数据持怀疑态度。”——维基方针
: 在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
详细的机制 不 是本文的重点，此处不展开。
在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

2022年6月19日 (日) 23:08的版本

为什么我们还没有确定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

详细的机制不是本文的重点，此处不展开。 在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

取自“https://arcwiki.mcd.blue/index.php?title=User:CppHusky/WhyHaven%27tWeDeterminedArcaea%27sPttAlgorithm&oldid=37613”