[心得] 精靈的CP(或等級)並非隨機

看板PokemonGO作者 (maniaque)時間7年前 (2016/12/09 20:36), 7年前編輯推噓21(23推 2噓 40→)
留言65則, 28人參與, 最新討論串1/2 (看更多)
若要講的簡單,可能要講長篇大論,但直接跳過去(打字也累),講統計心得 (這是以多帳號練功抓寶所得到結論..) 1.不同等級的訓練師們,捉同一隻精靈,[精靈的等級不相同] (CP值不同,透過軟體查,主差別在等級). 2.相同等級的訓練師們,捉同一隻精靈,[精靈的等級,相同] (即使不同隊也是相同)(CP值相同,查也是主差別在等級). 3.精靈的等級[並非隨機],而是一開始就已經定義好,在伺服器 所傳送該精靈的資料串中. 4.精靈的IV值(A/D/S)以及技能值(一技及二技的技能種類)一開始也已經定義好, 屬於可判讀的定值資料,因此捉寶搜尋軟體(如XX找寶貝或XX獵人)可以直接顯示出來. 5.以現有CP計算公式,係納入μ(等級的0.54次方)/A/D/S四組變動參數, 而精靈等級依族屬性,可對應到相對的HP值,不同品種的同等級精靈, 本身的HP不同,所以伺服器傳送出來的精靈資料,應是精靈的等級,方為合理. 6.伺服器定義精靈等級的方式,從現有收集精靈資料歸納判斷, 推論並非直接在資料中賦予精靈特定等級,而是給予一組參數, 因此各捉寶搜尋軟體(XX找寶貝或XX獵人)可能只知一組數值, 但不知數值該如何表達出精靈等級. 7.這組數值參數,技術上可能帶入一組特定公式計算,得到該精靈的等級(簡稱 [公式法]) ,或者是以遊戲裡面精靈等級表查表取得精靈等級(簡稱 [查表法]) (亦即,該參數查對該訓練師本身等級所對應的精靈等級表). 8.以現在的精靈統計資料顯示,精靈的等級,[以查表法較為可能], 畢竟,如精靈等級係以公式法推導,理論上結合多位同等級與不同等級訓練師 所捉到的精靈來統計,應會呈現某種程度的規律性,但統計的精靈數據資料未 有呈現規律性情況; 查表法則可以用較為亂數的方式來給予精靈等級,故以[查表法]為合理推斷. 9.精靈等級表,可能有不同訓練師等級共用精靈等級表情況 (以手上有納入統計的精靈資料顯示,19-20級訓練師捉到的精靈等級相同, 換言之19-20級同一張表,21-22級訓練師共用一張精靈等級表較為可能) 10.推測伺服器所傳出的等級參數長度,大概在2bytes到4bytes之間,如以數字表示 可能是00-99 or 0000-9999,或者是二進位0x00-0xFF or 0x0000-0xFFFF, 遊戲軟體取得參數值,去查精靈等級表的Offset (即該參數對應到等級表的第幾個欄位)便可取得等級. 11.伺服器傳出的野生精靈等級為整數,無小數點的等級 (或者說,精靈等級表裡面均為整數等級). 12.以查表法而言,部分欄位官方可能統一定義為 [所有不同等級訓練師,都能抓到配合訓練師等級的高檔次等級精靈 (訓練師可捉到的精靈等級,最高為訓練師等級+1,且上限為30)], 13.反之,部分欄位則可定義為[所有等級訓練師都只能抓到偏低檔次等級的精靈], 如此一來,官方如要辦理活動統一調高等級或統一調降等級, 只要在野生精靈的等級參數對到該區域欄位便可. 14.至於孵蛋精靈的等級跟IV?由於已知從蛋孵出來的精靈,IV值及精靈等級值 通常偏高(以紅隊隊長的評價,至少Strong甚至是Amazing), 換言之,從這邊推論可知,孵蛋用的精靈等級表,則可能是另外一張表, 此表精靈等級設定上就偏高(但高不會高過20級). 15.不過,有鄉民反映出出現[少數孵出的精靈等級偏低](但沒有聽過蛋曾經孵出 1級精靈或2級精靈),也可以從這邊推斷,孵蛋用精靈等級表是另外一組表, 係以抓到當下的訓練師等級所使用的孵蛋精靈等級表,亦即該蛋轉出時, 便已經確定精靈種類/IV/技能,精靈等級也從轉蛋當下從查表取得 (也有可能訓練師在某等級以下轉不出蛋);是以,即使訓練師等級一直提升, 蛋也不會提升等級,所以孵出來的時候,IV值OK,但精靈等級可能略偏低). 16.有鄉民小智小霞感覺訓練師等級提升後,抓到低等精靈的機會變少, 推測係配合訓練師等級提升而精靈等級表本身納入較多的精靈等級, 也配合提升難度,因此高等訓練師所使用的精靈等級表, 低等的精靈等級比例降低,以納入較高等的精靈等級. -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 180.217.243.164 ※ 文章網址: https://www.ptt.cc/bbs/PokemonGO/M.1481286994.A.038.html
推
12/09 20:43, , 1F
減的簡單？
12/09 20:43, 1F
講 的簡單 已更正... ps.這篇直接先打好,直接貼上.......損失好多 P ..... ※ 編輯: maniaque (180.217.243.164), 12/09/2016 20:45:38
推
12/09 20:45, , 2F
三十等以上是一組嗎？好像CP都一樣
12/09 20:45, 2F
不一定,但因為 30 級以上只有一組(主帳號,用最久的),所以無法查知. ps.用一隻手機來練,真是會累死人....這也是那時練其他三個帳號發現特性 然後再繼續追追追,紀錄記錄,所發現的(也不算久,其他三帳號是11/23開的) ※ 編輯: maniaque (180.217.243.164), 12/09/2016 20:48:55
推
12/09 20:53, , 3F
是同一組沒錯
12/09 20:53, 3F
推
12/09 20:53, , 4F
30級以上看到同一隻等級(CP)都一樣早就確定了
12/09 20:53, 4F
可能要去有很多訓練師捉大怪現場,去做市場調查吧..... ※ 編輯: maniaque (180.217.243.164), 12/09/2016 20:59:04
→
12/09 21:00, , 5F
不用調查啊 30以上都一樣已經確定
12/09 21:00, 5F
噓
12/09 21:01, , 6F
孵蛋不是用表，是看拿到的等級
12/09 21:01, 6F
→
12/09 21:04, , 7F
30以上 最好都一樣 你朋友很少喔 不要見笑轉生氣
12/09 21:04, 7F
推
12/09 21:05, , 8F
30以上不是都一樣嗎？
12/09 21:05, 8F
→
12/09 21:06, , 9F
30以上都一樣 現在追怪大部分都過30很方便XD
12/09 21:06, 9F
→
12/09 21:07, , 10F
同等級看到的寶可夢等級一樣這點倒是挺早就發現了
12/09 21:07, 10F
推
12/09 21:08, , 11F
你自己一個練多帳號跟大多數人同等帳號比對 哪個樣本大..
12/09 21:08, 11F
→
12/09 21:08, , 12F
記得野怪最高到30 孵蛋最高到20
12/09 21:08, 12F
→
12/09 21:10, , 13F
光14點就有問題 孵蛋寵等級不是偏高 而是依拿到蛋時人物
12/09 21:10, 13F
→
12/09 21:10, , 14F
等級決定 <20就同人物等級 ≧20則都是20級
12/09 21:10, 14F
推
12/09 21:12, , 15F
30以上遇到的的確都一樣啊..
12/09 21:12, 15F
推
12/09 21:16, , 16F
30以上遇到的全部都一樣，這確定的。
12/09 21:16, 16F
推
12/09 21:16, , 17F
freeQoo 你的孵蛋理論是對的
12/09 21:16, 17F
推
12/09 21:18, , 18F
希望雷達顯示30級以上遇到的CP
12/09 21:18, 18F
→
12/09 21:18, , 19F
笑了..自己刪掉吧,一堆錯誤
12/09 21:18, 19F
推
12/09 21:23, , 20F
某樓笑死
12/09 21:23, 20F
推
12/09 21:24, , 21F
@vancoffee 原則上無法，雷達帳號等級不會往上練
12/09 21:24, 21F
→
12/09 21:25, , 22F
雖然知道應該是查表但是這個表目前也無法取得
12/09 21:25, 22F
→
12/09 21:26, , 23F
真的要知道大怪CP還是加地區LINE群吧
12/09 21:26, 23F
推
12/09 21:29, , 24F
所以這篇看完沒得到什麼新知...甚至有些有誤...
12/09 21:29, 24F
→
12/09 21:31, , 25F
.......這篇好妙 短話長說
12/09 21:31, 25F
推
12/09 21:32, , 26F
原來孵蛋最高20等.......
12/09 21:32, 26F
→
12/09 21:32, , 27F
我講簡單一點好了 每一隻野怪的IV跟技組為固定
12/09 21:32, 27F
→
12/09 21:33, , 28F
但是等級為根據玩家等級查表 同等時抓到的都一樣
12/09 21:33, 28F
→
12/09 21:34, , 29F
算了突然覺得好懶得講完 總之很多東西網路上早就查得到
12/09 21:34, 29F
→
12/09 21:34, , 30F
你不用把這些用複雜化的方式表達出來
12/09 21:34, 30F
→
12/09 21:34, , 31F
另外雷達不太可能顯示30等以上的固定CP給你看
12/09 21:34, 31F
→
12/09 21:35, , 32F
除非他開的影分身都有30等 做雷達做到這樣也未免太類
12/09 21:35, 32F
→
12/09 21:35, , 33F
就很多東西網路上早就查得到,作者還是要用自己的小樣本推導
12/09 21:35, 33F
→
12/09 21:35, , 34F
*太累
12/09 21:35, 34F
→
12/09 21:35, , 35F
推導就算了還說錯 XD
12/09 21:35, 35F
→
12/09 21:37, , 36F
沒啥用，一堆不是早就知道了嗎
12/09 21:37, 36F
推
12/09 21:40, , 37F
的確 雷達不顯示cp想一下就知道了 使用者的等級都不同
12/09 21:40, 37F
→
12/09 21:40, , 38F
看到的cp就不一樣 那樣搜起來很累
12/09 21:40, 38F
→
12/09 21:41, , 39F
然後你這篇會被某KI戰開分身顆顆
12/09 21:41, 39F
推
12/09 21:41, , 40F
呃，如果再過幾個月，大家幾乎都三十等以上，那…
12/09 21:41, 40F
噓
12/09 21:45, , 41F
鬼島最無恥的就作弊還嗆很大聲是應該的,上兩樓就是範本
12/09 21:45, 41F
→
12/09 21:45, , 42F
那大家抓到的cp就都會一樣 除非N社在30等以上切分出
12/09 21:45, 42F
→
12/09 21:45, , 43F
新的查表區間
12/09 21:45, 43F
推
12/09 21:47, , 44F
召喚成功 哈哈 怎麼用語改變了啊
12/09 21:47, 44F
推
12/09 21:48, , 45F
你現在改用語來不及了啦 之前的事都被檢舉了
12/09 21:48, 45F
推
12/09 21:55, , 46F
說不定到時候雷達也會顯示「30級以上所遇之cp」吧？
12/09 21:55, 46F
→
12/09 21:59, , 47F
有點累 有太多原因不顯示cp了 我就不提了
12/09 21:59, 47F
→
12/09 22:01, , 48F
倘若真的有朝一日，cp(if L30), iv, 技能全顯示
12/09 22:01, 48F
→
12/09 22:02, , 49F
雷達追怪的狀況應該會更兩極吧…完美的卡比人潮
12/09 22:02, 49F
→
12/09 22:02, , 50F
應該非常可觀…
12/09 22:02, 50F
推
12/09 22:08, , 51F
只有我看不懂嗎QQ
12/09 22:08, 51F
→
12/09 22:41, , 52F
12/09 22:41, 52F
推
12/09 23:55, , 53F
比較想知道進化的技能是什麼時候決定的，和進化的時間有沒
12/09 23:55, 53F
→
12/09 23:55, , 54F
有關係？或是抓到的時候就已經決定了。
12/09 23:55, 54F
推
12/10 00:29, , 55F
喬丹的世界與正常人的世界不同，怎麼會知道等級>30 cp
12/10 00:29, 55F
→
12/10 00:29, , 56F
都一樣，天上是孤獨的
12/10 00:29, 56F
→
12/10 00:30, , 57F
>Axcic 記得有實測同等級抓到的同一隻 進化後技能不同
12/10 00:30, 57F
→
12/10 00:30, , 58F
所以至少應該不是一抓到就決定
12/10 00:30, 58F
→
12/10 00:45, , 59F
為了解釋簡單結果做一堆複雜且不知真實性的推論幹嘛呢xd
12/10 00:45, 59F
→
12/10 00:51, , 60F
同等玩家抓到同隻怪等級一樣 反之不一定 可能是查表決定
12/10 00:51, 60F
→
12/10 00:52, , 61F
但也可能不是 除非你找出公式或拆程式不然不知道
12/10 00:52, 61F
→
12/10 00:53, , 62F
但這完全不影響遊玩 另外玩家抽到可抽的每等野怪機率均
12/10 00:53, 62F
→
12/10 00:56, , 63F
等 國外統計幾萬隻野怪證實過了 所以你最後一項是錯的
12/10 00:56, 63F
推
12/10 09:49, , 64F
很努力實驗，辛苦付出
12/10 09:49, 64F
→
12/10 23:22, , 65F
這篇文浪費我3分鐘
12/10 23:22, 65F
‣ 更多 maniaque 的文章
文章代碼(AID): #1OIgLI0u (PokemonGO)
‣ 更多 maniaque 的文章
文章代碼(AID): #1OIgLI0u (PokemonGO)