※ 文章網址: https://www.ptt.cc/bbs/WOW/M.1481105484.A.662.html
推 miaobee: QAQ?? 12/07 18:15
推 tryagain24: @@? 12/07 18:15
推 devilshadow: 算了一堆數字還不是要看臉，省點力氣吧 12/07 18:20
推 w199381: 快推 不然讓人家以為我看的懂 12/07 18:22
推 luis0624: 推 12/07 18:23
推 HidakaShu: 喔喔原來如此 嗯嗯 12/07 18:25
推 marssss: 很有說服力的推論 不過在機率低到這個程度的情況下只能說 12/07 18:27
→ marssss: 臉還是最重要的 12/07 18:27
推 NoLimination: 那866天選之人的機率是? 12/07 18:29
推 greg7575: 102級的怎麼算？溢位了嗎 12/07 18:30
推 trance1204: 雖然看不懂~但好像很厲害 12/07 18:30
→ mystery7631: 一般是 1.看你幾橘訂個機率 2.在X橘形況下每50場或 12/07 18:30
→ mystery7631: 100場機率+Y% 然後加到某個層度就終止 防止不可預期 12/07 18:31
→ mystery7631: 這樣不但好預期 也不用再額外消耗CPU的運算時間 12/07 18:31
推 marssss: 不是很同意樓上 因為loot event發生率其實很低 計算甚少 12/07 18:32
→ marssss: 照原po的模型也只需要一個counter累積總機率就好 剩下的 12/07 18:34
推 mystery7631: 我不知道啦 我七八年寫程式在寫機率是不會這樣 12/07 18:34
→ marssss: 靠loot event時的條件式判斷即可(n橘檢查) 12/07 18:34
→ mystery7631: 累加算法很容易搞成overflow現象 不知道有沒拚對 12/07 18:35
→ mystery7631: 基本上 能不要算就可以不要算 簡單幾個if就能搞定 12/07 18:36
→ mystery7631: 會啥還要消費cpu的運算 明明就可以規定好 12/07 18:36
推 marssss: 在這個模型下要overflow就算是初始機率KP也高得嚇人 12/07 18:37
→ marssss: 而且7.1改版當天發生的橘裝大放送可能就是counter未歸零 12/07 18:37
→ mystery7631: 很多時候 就只是官方中途機率更改了 前後產生了一個 12/07 18:38
→ marssss: 因為你需要一個有感的防臉黑機制 而且真的計算量低 12/07 18:38
→ marssss: 會掉橘裝的event給你打一整天頂多發生幾十次 跟戰鬥計算 12/07 18:39
→ mystery7631: 數據，他可能只是某個參數調整後 前面+後面的結果 12/07 18:39
→ marssss: 相比實在連零頭都不算 12/07 18:39
→ mystery7631: 問題是 為啥需要自找麻煩 能不找麻煩就不要找麻煩 12/07 18:40
→ mystery7631: 你能節省 而且又有簡單的算法 為啥不採用 12/07 18:40
→ mystery7631: 你只要固定調整每幾場的參數 就好了 12/07 18:41
→ marssss: 因為原po提的模型符合數據證明... 12/07 18:41
推 paul26277: 簽名檔......(跪) 12/07 18:42
→ marssss: 也是要提一個符合防臉黑且能對應數據的模型吧? 12/07 18:44
推 mystery7631: 這數據從一開始就統計 結果是中間不知道調整多少次 12/07 18:49
→ mystery7631: 後產生的 所以吻合反而是奇怪的地方 12/07 18:50
→ mystery7631: 當然我不是說不可能拉 只是我工作多年還真沒人這樣寫 12/07 18:51
→ mystery7631: 可能暴雪的工程師有不一樣想法吧 我自己是覺得 結果 12/07 18:51
→ STGCBA: 反正一切都是運氣 12/07 18:51
→ mystery7631: 是多次調整後混和的 你不知道中間調整過了啥 12/07 18:51
→ marssss: 只有過去四周 也就是7.1改版之後 而且限定在4橘以下 12/07 18:52
→ arcross: model fitting不就是把數字調到看起來很吻合嗎 12/07 18:52
→ mystery7631: 但一個結果可能只是 我想讓0橘的多5% 就這樣而已.. 12/07 18:52
→ marssss: 這期間檯面上消息只有"取消4橘以上反臉黑機制"而已吧? 12/07 18:53
→ mystery7631: 然後結果 可能是 之前沒+5% 和後來+5%融合的 12/07 18:53
→ arcross: 是取消「四菊以上沒有房臉黑」 12/07 18:55
推 marssss: 如果是從7.0統計到現在的確會 但是1個月內... 12/07 18:55
→ mystery7631: 而且一個中等數據 可能是 2個極端值 融合成的結果 12/07 18:56
→ mystery7631: 除非你保證他概率和演算法都不變 那這模型就很正確 12/07 18:57
→ marssss: 所以才會是萬人統計 而不是看個別例子啊 12/07 18:57
→ mystery7631: 沒有說不可能 但我直覺是這種寫法很麻煩 僅供參考 12/07 18:58
→ marssss: 同版本短時間內(統計是11/26往前四周) 不變的可能性較大 12/07 18:59
→ mystery7631: 我說的極端值 是指他給定的演算法是極端的 12/07 18:59
→ marssss: 看錯 是11/23 12/07 18:59
推 bobby1028: 結論是拿5橘的是真天選者，前兩橘非核心砍角色比較快.. 12/07 19:00
→ bobby1028: .偉哉BZ 12/07 19:00
→ mystery7631: 比如之前調橘裝的演算法可能是每場 0.1% 過50場0.2% 12/07 19:00
→ mystery7631: 7.1可能改成每場0.5% 過50場1% 這種極高極低的調整 12/07 19:00
推 mystery7631: 幾場 是指事件 你只要把每個事件 給予一個屬性 他就 12/07 19:05
推 theget3874: D3也是裝備掉落池不對就重練啊 只是團隊沒想到的是魔 12/07 19:06
→ theget3874: 獸重練要多久 更別提還有神兵XD 12/07 19:06
→ mystery7631: 屬於那個物件 只要計算物件就知道該種事件發生多少次 12/07 19:06
→ mystery7631: 我看你回應就知道你根本沒寫過程式 沒啥好聊的lol 12/07 19:06
→ mystery7631: 要改機率也不會照你這樣改 我認真的 最近剛好負責 12/07 19:07
→ ttt95217: 少年別激動 12/07 19:09
推 mystery7631: 場次是一定有的 你每進去 最少是一個事件 最少會給你 12/07 19:11
→ mystery7631: 一個UUID 就是絕對辨識碼 統計場次這些都是小運算 12/07 19:12
→ mystery7631: 但float相加 相乘 對cpu的運算是耗蠻大的 12/07 19:13
→ mystery7631: 機率這種很敏感的東西更不太可能去直接累加 12/07 19:13
推 ZJerry: 感覺討論是平行線，原PO這篇文也沒說程式怎麼寫的 12/07 19:15
→ ZJerry: 只是提出機率可能是怎樣累加而已 12/07 19:15
→ asgard1991: 說到CPU負載突然想到之前的123Lag會不會其實是同時太 12/07 19:28
→ asgard1991: 多拾取運算結果卡住了XD 12/07 19:28
推 Marabuda: 先推再說以免人家以為我看不懂 12/07 19:29
→ mystery7631: 應該是這個 但更多原因應該是沒寫好 或CPU不給力 12/07 19:30
→ arcross: 其實是同時太多人打123 造成cpu負載過高 導致更多人打123 12/07 19:30
→ mystery7631: 其實MMO是非常消耗CPU的類型 因為交互這事情 不能 12/07 19:31
推 izplus: 最近沒123，可是延時變長了 12/07 19:31
→ mystery7631: 分批處理 很多不能寫成柱列(queue)來處理 要及時 12/07 19:32
→ mystery7631: 然後弄不好 沒同一frame處理完 跑去下一frame 就會 12/07 19:33
→ mystery7631: 有不可預期的情況發生 像WOW機制太多很容易爆 12/07 19:34
推 tony77731: 原文列表有人416KP出4橘 也有人731KP0橘 對BZ失望了 12/07 19:51
推 hansen5026: 趕快推文免得別人以為我看不懂 12/07 20:00
推 evaal: 提出可能性，不代表確信並要說服其他人事情就是這樣，理性 12/07 20:12
→ evaal: 勿戰。 QAQ 12/07 20:12
推 aynydy: 這樣看起來 狂刷H隨機似乎最划算 每一個王都有給KP? 12/07 20:17
推 apley: 嗯嗯，喔喔，是醬子啊。 12/07 20:18
推 henry1234562: 當然是先刷一遍M阿 12/07 20:21
推 evan700607: 0-1 臉 1-2 臉 2-3 臉 3-4 生辰八字 12/07 22:35
推 roea68roea68: 有可能啊 也不是沒有前例 事實上爐石不就是這樣搞.. 12/08 02:24
→ roea68roea68: 當然爐石寬鬆許多 越接近40包沒橘機率越大 最差40包 12/08 02:24
→ roea68roea68: 但原理上應該會是一樣的 同公司用同樣系統也不意外 12/08 02:25
推 lpb: 快推，假裝自己看的懂。 12/08 09:30
推 dh3014: 以工程師的角度來看其實可能性真的滿高的 12/08 10:20
推 bally0527: 這太專業了 12/08 10:45
推 marssss: 說到底這麼多機率的東西還用浮點數運算才叫浪費CPU... 12/08 10:54
→ marssss: 都已經覺得很專業了還不用整數去逼近運算才奇怪 12/08 10:56
推 XDXDXD8022: 上一個祈倫托開到第3 今天開到第4.. 12/08 10:56
推 barboo007: 借問，同帳號的橘裝拾取是一起算的？ 12/08 11:34
→ zseineo: 看角色 12/08 11:50
推 mystery7631: 對阿 所以才說if判斷就能解決的問題 不用機率累加lol 12/08 13:32