橘裝實際掉落率分析 - WOW

Elvira avatar
By Elvira
at 2016-12-07T18:11

Table of Contents

※ 引述《Esun0104 (尚恩)》之銘言:
: 在巴哈看到有人貼,點進去看覺得很有意思,沒人發我來簡單分享一下。
: 英文數學樣樣不通,有錯歡迎各位指正與鞭笞。
: 原文:https://goo.gl/dXniia
: 簡單說一下,這個作者很有才,使用了PHP機器人去wowprogress.com上面
: 撈了單一歐洲伺服器近萬人過去4週的橘裝獲得狀況來分析。
: 我的理解是他透過橘裝獲取管道對應橘裝獲取數量,為每一個橘裝獲取
: 的管道定義了一個KP分數如下,分數越高應該是取得的機率越大。
: 要注意的是,這僅僅為數據分析結果,並不代表真實的掉落率,實際掉落率
: 只能等BZ自行公布才能知道。
: http://i.imgur.com/1nl1zQ3.gif
: 這樣同學們有沒有比較了解呢?

先說結論,我之前的論點是4件以下時
出橘裝的機率是會隨著每次出橘失敗累計到下一次
簡單說,一橘不染的人,第一次出橘的機率是假設是1%,那下次出橘機率就2%、3%累加
這樣對工程師來說,只要調整機率參數,就可以輕鬆達成

為了證明理論,用不同的參數去逼近實際數字,結果發現我這理論蠻符合的
0橘的人,每次出橘裝的機率是0.015 % * N, N等於會調橘裝的參與度
1橘的人,每次出橘裝的機率是0.0015% * N, N等於會調橘裝的參與度
2橘的人,每次出橘裝的機率是0.0008% * N, N等於會調橘裝的參與度
3橘的人,每次出橘裝的機率是0.0006% * N, N等於會調橘裝的參與度
4橘以上機率不明,沒有累加出裝機率
雖然沒辦法證明我的理論是對的,但是參數上看起來就很完美,


對照萬人實驗中,從0到1出橘裝的機率
沒有橘裝的人,178次KP後,會有91.66%的人會拿到橘裝
一件橘裝的人,287次KP後,會有48.17%的人拿拿到橘裝
二件橘裝的人,216次KP後,會有17.62%的人拿拿到橘裝
三件橘裝的人,165次KP後,會有 7.56%的人拿拿到橘裝

請準備一個EXL表格
0->1橘
A B C D E F G
D=B*C E=1-D F1=1-E1 G=1-F
F2=F1*E2
KP數 初始機率 倍數 拿到橘裝機率 該次沒拿到橘裝機率 全部MISS的機率 拿到1橘機率
1 0.0150% 1 0.0150% 99.9850% 99.9850% 0.01%
2 0.0150% 2 0.0300% 99.9700% 99.9550% 0.04%
3 0.0150% 3 0.0450% 99.9550% 99.9100% 0.09%
4 0.0150% 4 0.0600% 99.9400% 99.8501% 0.15%

178 0.0150% 178 2.6700% 97.3300% 8.9701% 91.03%
(實測91.66%拿到橘裝)

1->2橘
KP數 初始機率 倍數 拿到橘裝機率 該次沒拿到橘裝機率 全部MISS的機率 拿到1橘機率
1 0.0015% 1 0.0015% 99.9985% 99.9985% 0.00%
2 0.0015% 2 0.0030% 99.9970% 99.9955% 0.00%
3 0.0015% 3 0.0045% 99.9955% 99.9910% 0.01%
4 0.0015% 4 0.0060% 99.9940% 99.9850% 0.01%

287 0.0015% 287 0.4305% 99.5695% 53.7507% 46.25%
(實測48.17%拿到橘裝)

2->3橘
KP數 初始機率 倍數 拿到橘裝機率 該次沒拿到橘裝機率 全部MISS的機率 拿到1橘機率
216 0.0008% 216 0.1728% 99.8272% 82.8949% 17.11%
(實測17.62%拿到橘裝)

3->4橘
KP數 初始機率 倍數 拿到橘裝機率 該次沒拿到橘裝機率 全部MISS的機率 拿到1橘機率
165 0.0006% 165 0.0990% 99.9010% 92.1090% 7.89%
(實測 7.56%拿到橘裝)


--
o0 0o 偉業:中立熊貓人 7.0 ^____^
qop / o00o \
\_/ 在漂流島上將一個熊貓人升級到110等 | \__/ |
V 11-25-16
http://imgur.com/0KYferU http://imgur.com/GtI43Mu http://imgur.com/t0jZC4r
CST 2016/11/25 07:09 (UTC 2016/11/24 16:09) 總遊戲時數5小時44分3秒

--
※ 文章網址: 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
這樣子符合BZ所說的,只要夠努力,4橘不是問題
mystery7631: 累進算法對寫程式其實超麻煩的 每次都要計算後再相加 12/07 18:29
不會吧
有出就歸1,沒出就+1,有問題嗎
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
會說幾場,那就是只管M+
但是因為還有WQ寶箱也要加在內,所以用幾場,會更麻煩
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
mystery7631的說法是機率是固定的
很簡單,用EXL計算也很快
每次出橘裝的機率設定多少,是固定的,不累加
零件橘裝的人,178次KP後,會有91.66%的人會拿到橘裝
一件橘裝的人,287次KP後,會有48.17%的人拿拿到橘裝
二件橘裝的人,216次KP後,會有17.62%的人拿拿到橘裝
三件橘裝的人,165次KP後,會有 7.56%的人拿拿到橘裝
0-1橘的機率是0.014 時會逼近實測結果
1-2橘的機率是0.0023
2-3橘的機率是0.0009
沒有規律性
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
實際結果是4週內、萬人統計數字
中間應該沒有什麼大改版或調整參數
只有BZ跳出來說有防臉黑機制而已
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
※ 編輯: allbs (123.205.107.42), 12/07/2016 19:13:41
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
這是真的
※ 編輯: allbs (123.205.107.42), 12/07/2016 19:24:05
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

Tags: WOW

All Comments

Connor avatar
By Connor
at 2016-12-11T11:50
QAQ??
Caitlin avatar
By Caitlin
at 2016-12-16T10:37
@@?
Eden avatar
By Eden
at 2016-12-20T20:59
算了一堆數字還不是要看臉,省點力氣吧
Edward Lewis avatar
By Edward Lewis
at 2016-12-24T22:22
快推 不然讓人家以為我看的懂
Christine avatar
By Christine
at 2016-12-27T02:33
Emily avatar
By Emily
at 2016-12-31T00:44
喔喔原來如此 嗯嗯
Rosalind avatar
By Rosalind
at 2017-01-04T09:08
很有說服力的推論 不過在機率低到這個程度的情況下只能說
臉還是最重要的
Xanthe avatar
By Xanthe
at 2017-01-08T22:55
那866天選之人的機率是?
Eartha avatar
By Eartha
at 2017-01-11T09:19
102級的怎麼算?溢位了嗎
Tristan Cohan avatar
By Tristan Cohan
at 2017-01-13T11:40
雖然看不懂~但好像很厲害
Agatha avatar
By Agatha
at 2017-01-17T15:15
一般是 1.看你幾橘訂個機率 2.在X橘形況下每50場或
Isla avatar
By Isla
at 2017-01-20T13:10
100場機率+Y% 然後加到某個層度就終止 防止不可預期
這樣不但好預期 也不用再額外消耗CPU的運算時間
Zora avatar
By Zora
at 2017-01-20T21:04
不是很同意樓上 因為loot event發生率其實很低 計算甚少
James avatar
By James
at 2017-01-25T02:06
照原po的模型也只需要一個counter累積總機率就好 剩下的
靠loot event時的條件式判斷即可(n橘檢查)
Necoo avatar
By Necoo
at 2017-01-27T11:44
我不知道啦 我七八年寫程式在寫機率是不會這樣
Emily avatar
By Emily
at 2017-01-31T21:31
累加算法很容易搞成overflow現象 不知道有沒拚對
Lydia avatar
By Lydia
at 2017-02-01T04:49
基本上 能不要算就可以不要算 簡單幾個if就能搞定
會啥還要消費cpu的運算 明明就可以規定好
Charlie avatar
By Charlie
at 2017-02-03T02:49
在這個模型下要overflow就算是初始機率KP也高得嚇人
而且7.1改版當天發生的橘裝大放送可能就是counter未歸零
Wallis avatar
By Wallis
at 2017-02-07T17:35
很多時候 就只是官方中途機率更改了 前後產生了一個
Edwina avatar
By Edwina
at 2017-02-11T09:00
因為你需要一個有感的防臉黑機制 而且真的計算量低
Kristin avatar
By Kristin
at 2017-02-12T12:50
會掉橘裝的event給你打一整天頂多發生幾十次 跟戰鬥計算
相比實在連零頭都不算
Doris avatar
By Doris
at 2017-02-13T15:02
數據,他可能只是某個參數調整後 前面+後面的結果
Dorothy avatar
By Dorothy
at 2017-02-17T06:11
問題是 為啥需要自找麻煩 能不找麻煩就不要找麻煩
你能節省 而且又有簡單的算法 為啥不採用
Suhail Hany avatar
By Suhail Hany
at 2017-02-18T04:37
你只要固定調整每幾場的參數 就好了
Elvira avatar
By Elvira
at 2017-02-18T17:14
因為原po提的模型符合數據證明...
Genevieve avatar
By Genevieve
at 2017-02-22T08:35
簽名檔......(跪)
Margaret avatar
By Margaret
at 2017-02-25T19:22
也是要提一個符合防臉黑且能對應數據的模型吧?
Hazel avatar
By Hazel
at 2017-02-28T21:29
這數據從一開始就統計 結果是中間不知道調整多少次
Hardy avatar
By Hardy
at 2017-03-02T14:45
後產生的 所以吻合反而是奇怪的地方
Sarah avatar
By Sarah
at 2017-03-05T22:05
當然我不是說不可能拉 只是我工作多年還真沒人這樣寫
可能暴雪的工程師有不一樣想法吧 我自己是覺得 結果
是多次調整後混和的 你不知道中間調整過了啥
Tom avatar
By Tom
at 2017-03-09T23:07
反正一切都是運氣
Bethany avatar
By Bethany
at 2017-03-12T04:40
只有過去四周 也就是7.1改版之後 而且限定在4橘以下
Hedwig avatar
By Hedwig
at 2017-03-15T17:00
model fitting不就是把數字調到看起來很吻合嗎
Irma avatar
By Irma
at 2017-03-17T16:04
但一個結果可能只是 我想讓0橘的多5% 就這樣而已..
Lily avatar
By Lily
at 2017-03-18T01:52
這期間檯面上消息只有"取消4橘以上反臉黑機制"而已吧?
Adele avatar
By Adele
at 2017-03-19T13:50
然後結果 可能是 之前沒+5% 和後來+5%融合的
Zanna avatar
By Zanna
at 2017-03-21T15:47
是取消「四菊以上沒有房臉黑」
Rebecca avatar
By Rebecca
at 2017-03-25T22:20
如果是從7.0統計到現在的確會 但是1個月內...
Catherine avatar
By Catherine
at 2017-03-28T13:24
而且一個中等數據 可能是 2個極端值 融合成的結果
Daph Bay avatar
By Daph Bay
at 2017-04-01T04:03
除非你保證他概率和演算法都不變 那這模型就很正確
Emma avatar
By Emma
at 2017-04-02T05:23
所以才會是萬人統計 而不是看個別例子啊
Iris avatar
By Iris
at 2017-04-02T20:25
沒有說不可能 但我直覺是這種寫法很麻煩 僅供參考
Rae avatar
By Rae
at 2017-04-06T04:44
同版本短時間內(統計是11/26往前四周) 不變的可能性較大
看錯 是11/23
Ida avatar
By Ida
at 2017-04-09T03:24
我說的極端值 是指他給定的演算法是極端的
Anthony avatar
By Anthony
at 2017-04-09T22:33
結論是拿5橘的是真天選者,前兩橘非核心砍角色比較快..
.偉哉BZ
David avatar
By David
at 2017-04-11T18:25
比如之前調橘裝的演算法可能是每場 0.1% 過50場0.2%
7.1可能改成每場0.5% 過50場1% 這種極高極低的調整
Necoo avatar
By Necoo
at 2017-04-12T00:40
幾場 是指事件 你只要把每個事件 給予一個屬性 他就
Hedda avatar
By Hedda
at 2017-04-16T19:25
D3也是裝備掉落池不對就重練啊 只是團隊沒想到的是魔
獸重練要多久 更別提還有神兵XD
Zora avatar
By Zora
at 2017-04-17T16:54
屬於那個物件 只要計算物件就知道該種事件發生多少次
我看你回應就知道你根本沒寫過程式 沒啥好聊的lol
Madame avatar
By Madame
at 2017-04-19T13:51
要改機率也不會照你這樣改 我認真的 最近剛好負責
Tracy avatar
By Tracy
at 2017-04-22T07:51
少年別激動
Puput avatar
By Puput
at 2017-04-26T17:51
場次是一定有的 你每進去 最少是一個事件 最少會給你
Jacky avatar
By Jacky
at 2017-04-30T16:03
一個UUID 就是絕對辨識碼 統計場次這些都是小運算
Olive avatar
By Olive
at 2017-05-02T07:00
但float相加 相乘 對cpu的運算是耗蠻大的
機率這種很敏感的東西更不太可能去直接累加
Christine avatar
By Christine
at 2017-05-04T17:07
感覺討論是平行線,原PO這篇文也沒說程式怎麼寫的
只是提出機率可能是怎樣累加而已
Poppy avatar
By Poppy
at 2017-05-05T22:04
說到CPU負載突然想到之前的123Lag會不會其實是同時太
多拾取運算結果卡住了XD
Delia avatar
By Delia
at 2017-05-08T14:42
先推再說以免人家以為我看不懂
Skylar Davis avatar
By Skylar Davis
at 2017-05-10T07:32
應該是這個 但更多原因應該是沒寫好 或CPU不給力
Hedwig avatar
By Hedwig
at 2017-05-14T05:31
其實是同時太多人打123 造成cpu負載過高 導致更多人打123
Valerie avatar
By Valerie
at 2017-05-15T01:17
其實MMO是非常消耗CPU的類型 因為交互這事情 不能
Thomas avatar
By Thomas
at 2017-05-19T13:39
最近沒123,可是延時變長了
Eden avatar
By Eden
at 2017-05-23T08:39
分批處理 很多不能寫成柱列(queue)來處理 要及時
Kumar avatar
By Kumar
at 2017-05-25T13:26
然後弄不好 沒同一frame處理完 跑去下一frame 就會
Jack avatar
By Jack
at 2017-05-26T12:50
有不可預期的情況發生 像WOW機制太多很容易爆
Zora avatar
By Zora
at 2017-05-27T19:52
原文列表有人416KP出4橘 也有人731KP0橘 對BZ失望了
Isabella avatar
By Isabella
at 2017-05-28T18:10
趕快推文免得別人以為我看不懂
Gilbert avatar
By Gilbert
at 2017-05-29T03:30
提出可能性,不代表確信並要說服其他人事情就是這樣,理性
勿戰。 QAQ
Eden avatar
By Eden
at 2017-06-02T14:10
這樣看起來 狂刷H隨機似乎最划算 每一個王都有給KP?
Isla avatar
By Isla
at 2017-06-05T20:35
嗯嗯,喔喔,是醬子啊。
Odelette avatar
By Odelette
at 2017-06-06T01:47
當然是先刷一遍M阿
Iris avatar
By Iris
at 2017-06-07T09:21
0-1 臉 1-2 臉 2-3 臉 3-4 生辰八字
Dinah avatar
By Dinah
at 2017-06-08T01:12
有可能啊 也不是沒有前例 事實上爐石不就是這樣搞..
當然爐石寬鬆許多 越接近40包沒橘機率越大 最差40包
Ula avatar
By Ula
at 2017-06-11T08:10
但原理上應該會是一樣的 同公司用同樣系統也不意外
Sarah avatar
By Sarah
at 2017-06-11T14:21
快推,假裝自己看的懂。
Lucy avatar
By Lucy
at 2017-06-12T02:04
以工程師的角度來看其實可能性真的滿高的
Elizabeth avatar
By Elizabeth
at 2017-06-13T00:55
這太專業了
Harry avatar
By Harry
at 2017-06-14T21:56
說到底這麼多機率的東西還用浮點數運算才叫浪費CPU...
Brianna avatar
By Brianna
at 2017-06-19T08:28
都已經覺得很專業了還不用整數去逼近運算才奇怪
Ingrid avatar
By Ingrid
at 2017-06-19T11:00
上一個祈倫托開到第3 今天開到第4..
Carol avatar
By Carol
at 2017-06-23T10:05
借問,同帳號的橘裝拾取是一起算的?
Ingrid avatar
By Ingrid
at 2017-06-24T21:31
看角色
Kelly avatar
By Kelly
at 2017-06-27T01:41
對阿 所以才說if判斷就能解決的問題 不用機率累加lol

日/屠 God Of Dragon休閒傳奇團隊徵人 備戰暗夜堡

Edwina avatar
By Edwina
at 2016-12-07T18:04
徵人類型:公會/團隊 陣營:部落 公會名稱:God of Dragon 出團時間:四五一二 20:30至23:30 (很少機會加到班,通常都是提早打卡比較多) 需求裝等:855+,無團隊經驗可 分裝方式:Callloot 需求職業:法師/術士/暗牧/補聖/補徳 其他職業對自己有信心者,也非常歡迎與我聯絡 ...

聖騎士職業大廳任務

Charlotte avatar
By Charlotte
at 2016-12-07T17:37
各位好,目前老魯聖騎回鍋15天 三把神器都拿到了 走上雙修之路QQ 到現在為止,裝等817 想請教各位聖騎士前輩,怎麼我職業大廳拿到伊露恩之淚就停了 伊露恩之淚還躺在我包包裡,也不知道該怎麼觸發大戰役 每天都跟無頭蒼蠅一樣打戰場過世界任務,衝夜落聲望 該不會是我聖騎士任務有一項魔化詞典沒過的因素吧? ...

暗牧懶帖 7.1.5 PTR 反饋 [翻譯文]

Hedda avatar
By Hedda
at 2016-12-07T16:16
: → zseineo: 今天HotFIX好像又對暗牧說了一些話 12/07 12:10 : → snowanimal: 正在看,等等抽空翻 12/07 12:16 : → b52618: 沒說啥吧 ...

7.0 野性戰鬥/Feral/Cat/貓 德魯伊 關於5h/m 模擬簡談

Sarah avatar
By Sarah
at 2016-12-07T16:05
求助,貓D大秘傷害過低 想探討調整大秘輸出手法 由於我個人周二、四固定開團打翡翠夢魘 輸出手法都是以團隊BOSS單體目標為主 經常在本版請益,得到許多有用的建議 最近的一次貓D單體輸出資料是勇氣試煉2王 https://tw.warcraftlogs.com/reports/2AkfdKm3WhpNcL7 ...

請問大秘境的環境,德魯依是貓D還是鳥D好

Joe avatar
By Joe
at 2016-12-07T15:40
大秘境的補D隊友,神器已經點滿,接下來想點DPS方面, 不過不太懂這方面,想請問那個比較強勢,或是各有什麼優勢與劣勢, 想請教各位大大,謝謝。 接下來想開始往高層打了。 - ...