「User:CppHusky/WhyHaven'tWeDeterminedArcaea'sPttAlgorithm」：修訂間差異
小無編輯摘要 |
小 （为什么我们还没有确定arcaea的潜力值（ptt）算法 全文编辑完毕） |
||
| 行 1： | 行 1： | ||
<h1> 为什么我们还没有确定arcaea的潜力值（ptt）算法</h1><br> | |||
（关于ptt算法的问题就不要再说我们维基咕咕咕了） | （关于ptt算法的问题就不要再说我们维基咕咕咕了） | ||
<h2> 我们通过什么了解ptt算法？</h2> | |||
“任何编辑者应当且仅应当信任拆包的数据/服务器返回的数据/游戏本身返回的精度足够的数据，并对任何不是此来源的数据持怀疑态度。”——维基方针<br> | “任何编辑者应当且仅应当信任拆包的数据/服务器返回的数据/游戏本身返回的精度足够的数据，并对任何不是此来源的数据持怀疑态度。”——维基方针<br> | ||
在ptt算法问题上，维基的态度是尤为严苛的。<br> | 在ptt算法问题上，维基的态度是尤为严苛的。<br> | ||
| 行 8： | 行 8： | ||
游戏本身返回的ptt数据精度还不如服务器给的数据，其它数据精度基本上也不会超过服务器返回的数据，所以基本不在考虑范围内。<br> | 游戏本身返回的ptt数据精度还不如服务器给的数据，其它数据精度基本上也不会超过服务器返回的数据，所以基本不在考虑范围内。<br> | ||
NS端的情况则要好一些，因为NS的ptt是断网结算的。通过拆包，可以获知算法的有关信息。然而这不是直接获取源代码！完整的源代码只能从lowiro的程序员处获取，这样的可能性几近于零。<br> | NS端的情况则要好一些，因为NS的ptt是断网结算的。通过拆包，可以获知算法的有关信息。然而这不是直接获取源代码！完整的源代码只能从lowiro的程序员处获取，这样的可能性几近于零。<br> | ||
<h2>arcaea的ptt算法经历了什么？</h2> | |||
在3.0.0版本配信之前，已经有明确的B30/R10机制共识，即以下公式：<br> | 在3.0.0版本配信之前，已经有明确的B30/R10机制共识，即以下公式：<br> | ||
::<b>ptt=（30×B30均值+10×R10均值）÷40</b><br> | ::<b>ptt=（30×B30均值+10×R10均值）÷40</b><br> | ||
| 行 16： | 行 16： | ||
那么我们为什么还在使用“不准确”的信息？维基管理员sxy的回答是“只是因为 没有 更对的 表述”。<br> | 那么我们为什么还在使用“不准确”的信息？维基管理员sxy的回答是“只是因为 没有 更对的 表述”。<br> | ||
一言以蔽之，<u>目前维基的描述已经尽力接近真实的ptt算法了</u>。<br> | 一言以蔽之，<u>目前维基的描述已经尽力接近真实的ptt算法了</u>。<br> | ||
<h2> 关于ptt算法，维基走到了哪一步？</h2> | |||
NS拆包结果表明，<b>NS端ptt算法是一个（30+10）÷40的算法</b>。<br> | NS拆包结果表明，<b>NS端ptt算法是一个（30+10）÷40的算法</b>。<br> | ||
其中的30个数据很有可能是B30值，但另外10个数据如何选取，我们不得而知。<br> | 其中的30个数据很有可能是B30值，但另外10个数据如何选取，我们不得而知。<br> | ||
| 行 26： | 行 26： | ||
当然，上述讨论还是建立在<b>“移动端与NS的ptt算法一致”</b>的假设下的。如果不一致呢？这样我们关于ptt的研究还要有大篇幅作废。<br> | 当然，上述讨论还是建立在<b>“移动端与NS的ptt算法一致”</b>的假设下的。如果不一致呢？这样我们关于ptt的研究还要有大篇幅作废。<br> | ||
之前arcaea圈内就出现了ptt12.88的情况，但用现有模型计算的ptt最高值也只能有12.87，这也从一个侧面反映了目前已有ptt算法是仍有问题的。然而，这种问题不是我们这么少的人在短时间内可以解决的。<br> | 之前arcaea圈内就出现了ptt12.88的情况，但用现有模型计算的ptt最高值也只能有12.87，这也从一个侧面反映了目前已有ptt算法是仍有问题的。然而，这种问题不是我们这么少的人在短时间内可以解决的。<br> | ||
<h2> 结语</h2> | |||
维基群里经常有新人在问ptt算法的事，每次都需要管理员反复解释。这是一件费时费力的工作，因此我写出本文，旨在告知有这样困惑的朋友，解出这个ptt的算法是一件多么困难的工作。 | 维基群里经常有新人在问ptt算法的事，每次都需要管理员反复解释。这是一件费时费力的工作，因此我写出本文，旨在告知有这样困惑的朋友，解出这个ptt的算法是一件多么困难的工作。 | ||
我的建议是，与其在这个几乎不可能解出来的算法上耽误过多的时间，不如去做一些其它的工作。就算是多玩一会儿arcaea也是好的。<br> | 我的建议是，与其在这个几乎不可能解出来的算法上耽误过多的时间，不如去做一些其它的工作。就算是多玩一会儿arcaea也是好的。<br> | ||
如果ptt算法破解方面有了新的进展，也请第一时间关注维基动向，因为维基无疑是国内arcaea信息最严谨、最可靠的提供方。<br> | 如果ptt算法破解方面有了新的进展，也请第一时间关注维基动向，因为维基无疑是国内arcaea信息最严谨、最可靠的提供方。<br> | ||
written by cppHusky, 6/19/2022 | <hr> | ||
<h6>written by cppHusky, 6/19/2022</h6> | |||
於 2022年6月19日 (日) 23:27 的修訂
為什麼我們還沒有確定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信息最嚴謹、最可靠的提供方。