69
次編輯
User:CppHusky/WhyHaven'tWeDeterminedArcaea'sPttAlgorithm (查看原始碼)
於 2022年6月19日 (日) 23:36 的修訂
、 2022年6月19日 (星期日)無編輯摘要
小 （缩进修改，希望有用） |
小無編輯摘要 |
||
| 第23行： | 第23行： | ||
除此之外，R30更迭机制还会受到一种所谓的<b>“EX保护机制”</b>影响，但3.0.0以后这个机制是否还如同原来一样？不得而知。3.0.0以前的EX保护机制使得玩家在达到EX评级时不会再因为R30更新 | 除此之外，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和移动端是一致的呢？<br> | 而导致ptt降低。然而，目前出现了<b>排除多设备登录影响下达到EX但扣ptt的情况</b>，但只是“零星的报告”（罕见），查证也很困难。而对应的，NS端并没有EX保护机制（实验支撑），那么移动端ptt算法是否也是如此？如果不是如此（EX保护机制确实存在），就说明NS与移动端ptt算法不一致，那我们又如何敢确定NS拆包得到的（30+10）÷40和移动端是一致的呢？<br> | ||
除了EX保护机制存在争议以外，另一个点也存在争议，那就是Recent数据是否参与ptt的计算。sxy表示”官方API只返回30个数据而且看起来是B30”，而R10数据不得而知；NS拆包的结果是“没有R10这个桶”，这暗示着或许NS端公式中的10个所谓Recent数据其实是另有来源？是否来源于B30？但如果这样就无法解释ptt数据大幅度的漂移。问题来了，NS端没有R10这个桶，那么移动端是否有？如果没有，那么这10个数据来自哪里？如果有，那么NS和移动端的ptt算法就显然不一致了，上述NS公式就一定能在移动端成立吗？<br> | |||
<i>注：移动端查分器会返回R10均值数据，但是这个R10均值并非由lowiro的API直接返回，而是通过lowiro的API所返回的ptt和B30数据套用旧公式进行计算得到的。查分器的查分结果并不能证明R10是确实存在的</i><br> | <i>注：移动端查分器会返回R10均值数据，但是这个R10均值并非由lowiro的API直接返回，而是通过lowiro的API所返回的ptt和B30数据套用旧公式进行计算得到的。查分器的查分结果并不能证明R10是确实存在的</i><br> | ||
当然，上述讨论还是建立在<b>“移动端与NS的ptt算法一致”</b>的假设下的。如果不一致呢？这样我们关于ptt的研究还要有大篇幅作废。<br> | 当然，上述讨论还是建立在<b>“移动端与NS的ptt算法一致”</b>的假设下的。如果不一致呢？这样我们关于ptt的研究还要有大篇幅作废。<br> | ||