用戶:CppHusky/為什麼我們還未確定arcaea的潛力值算法?

本文簡而言之:關於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