Posts by hoshinokanade

Fizzbuzz湊談

Fizzbuzz湊談

由於找不到方向繼續寫SagaECO 深入淺出系列,先行隨筆。在Google沒有收錄的網站刷SEO是不是搞錯了甚麼 相信大家有聽過傳說中的Fizzbuzz問題,全地表最因難的問題。上一篇”整潔代碼湊談“的文末有提到不應在Fizzbuzz問題紏纏clean code,在此解畫。 The “Fizz-Buzz test” is an interview question designed to help filter out the 99.5% of programming...

整潔代碼湊談

整潔代碼湊談

湊談系列第二期…才不會告訴你湊談系列是用來刷SEO吸引潛在的ECO私服的白武士的哼 很多人知道代碼要寫得整潔,很多人知道有Clean Code這本書…我不記得我有沒有看過這本書了,好像有,好像沒有,好像直到專程談一次整潔 代碼之道的一刻介於有和沒有之間… 好吧,你可以當我沒有。 篇幅有限。首先這本書的側重點不在於爭論花括號到底要不要開新行、用tab還是用space、縮進2格抑或是4格,老實說我很久以前真的以為是關於編排的。(如果 編排 = 整潔代碼,生活真是容易多了~)GO語言自帶了編排器(formatter),然而編排好的代碼不代表它整潔(clena)。用上了再嶄新的工具,再尖端的框架,還是需要駕駛員(派駱駝)的。編排器充其量只是提醒的作用,一行是不是太長了? 括號是不是開太多了? 簡而明了的是,給所有東西起名,三思而後行。Think beyond twice for naming everything. 變量、函數、類別,統統要起名。如果起名實在起得太辛苦,那麼一定有東西是不妥當的,要打醒十二分精神重新檢視,十有九都是抽象(abstraction)問題。名字不一定要短,嘗試使用縮寫只是逃避問題的一種手段,反而長的名字不一定壞。最後檢查一下拼字有沒有錯誤(還真有看過中國大陸人連github repo名字本身已經拼錯了XD)。印象中SagaECO的DB有一個名字就是串錯了,那要改回來是往往更費神的breaking change。 我的看法是註釋不一定要有,前提是有單元測試(unit...

深入淺出SagaECO RPC篇(五) “揚帆啟程”

深入淺出SagaECO RPC篇(五) “揚帆啟程”

以下討論基於SagaECO svn ~400版本 源代碼可以從這裡下載 RPC篇終於來到第五篇… 上回提要是每當與伺服器連接時首要的鑰匙交換事項,換言之通信確立後馬上開始通信(傳送門)。 這次介紹登入的詳細步驟,手把手完成最基礎的登入ECO的過程。跟上一章同樣,登入的步驟是由癌炮指定的,跟SagaECO沒有關聯咯。 仔細看很多重覆的流程,無非是檢查版本->登入->做其他事的模式。這裡使用了SagaECO的命名方式。Gate Server的角色很簡單,就是用來做用戶認證,引導到用戶選擇遊戲伺服器的列表裡(C, L ,F , Z服)。 好像盤古開初的時候沒有這個Gate Server。從server.lst可以看出,本來就是讓玩家自己選遊戲伺服器。server.lst中加一行就能在登入畫面選伺服器。可能是後來意識到server.lst裡直接寫IP,容易被DDOS,於是把第一重登入交給Gate Server去做; 或者是Login Server負載大而需要多幾台伺服器,擔當負載平衡(分流)作用。後者推測比較合理,因為這種沒有代理作用的負載平衡器不見得能避免直接去DDOS後面的伺服器。 當伺服器列表交出去之後 Gate...

八二定律湊談

八二定律湊談

不知道為甚麼,軟件界常常提及八二定律例如是優化工作,卻往往不知所云。 八二定律的全句是: 約20%的變數控制了80%的結果 80/20的法則認為:原因和結果、投入和產出、努力和報酬之間本來存在著無法解釋的不平衡 出處 或曰: 二八定律又名80/20定律、帕累托法則(Pareto‘s principle)也叫巴萊特定律、朱倫法則(Juran’s Principle)、關鍵少數法則(Vital Few Rule)、不重要多數法則(Trivial Many Rule)最省力的法則、不平衡原則等,被廣泛應用於社會學及企業管理學等。 百度百科 不管叫怎樣的名字都好,共通點皆表達出少數比多數重要,甚至被包裝是”最省力法則”。 現在開始破題,掀開八二定律的葫蘆裡賣甚麼藥。 八二定律的抽象點在於原因和結果皆沒有定義好,所以是一個萬能KEY,甚或是只要分布看起來像八二開,那就運用八二定律orz 比如說人類80%時間都在睡覺和吃飯,剩20%時間有用,那你是不是不睡覺了~ 這裡給出一個例子: 扔飛鏢。我也不懂扔飛鏢,假設正中間是50分,外面綠色圈是30分,內圈都10分,外圈5分,扔不中板子當然是0分,最高分的勝出。...

異常狀態特效表

異常狀態特效表

嚴禁轉載Republishing is strictly prohibited転載はご遠慮ください 異常狀態生效時的特效一覽如無意外是首發

深入淺出SagaECO RPC篇(四) “不滅之握”

深入淺出SagaECO RPC篇(四) “不滅之握”

以下討論基於SagaECO svn 900版本源代碼可以從這裡下載 注意: 被分發SagaECO源代碼並不代表你被授權使用、修改、發布衍生的程式換言之SagaECO團隊仍然保留一切權利(雖然SagaECO團隊早就消失了… 這篇主要覆蓋SagaECO中的NetIO和Encryption類,比較沉悶,是失眠的良藥。 已經去掉無關代碼,但是還是太長了。要表達的其實是客戶端和伺服器確認連線的流程: 客戶端發送長度為8的封包 伺服器啟動鑰匙交換 ,準備私鑰 ,向客戶端發送含有公鑰、長度為529的封包 客戶端收到伺服器的公鑰,準備私鑰,製作共享鑰匙,並向伺服器發送含有 公鑰、長度為260的封包 伺服器收到客戶端的公鑰製作共享鑰匙 連接成立 想當年我自行斷斷續續去湊關鍵字花了幾個月最後才得出是DH交換書本和大神的文章是可以省掉以年為單位的時間可謂不誇張…每每醍醐灌頂每天生活在他們的陰影中實在不要太幸福 具體可以自行參照wiki對應交換所需要的資料。(謎之聲: 再說一次! Ecore是日本的網站非指ECO-Re私服) DH鑰匙交換的計算...

深入淺出SagaECO RPC篇(三) “解耦封包”

深入淺出SagaECO RPC篇(三) “解耦封包”

以下討論基於SagaECO svn 900版本源代碼可以從這裡下載(約svn 400版本) 注意: 被分發SagaECO源代碼並不代表你被授權使用、修改、發布衍生的程式換言之SagaECO團隊仍然保留一切權利(雖然SagaECO團隊早就消失了… 上文我們已經處理好輸出數據的格式和流程了,我們還有接收封包(Packet)的部分未解說呢。時間關係,讓我們一次過掀開完整的流程。 上一篇說的從Packet類的虛擬方法三巨頭 public virtual bool SizeIsOk 近乎沒有用到、忽略 public virtual Packet New() public virtual void...

深入淺出SagaECO RPC篇(二) “封包結構”

深入淺出SagaECO RPC篇(二) “封包結構”

以下討論基於SagaECO svn 900版本源代碼可以從這裡下載 注意: 被分發SagaECO源代碼並不代表你被授權使用、修改、發布衍生的程式換言之SagaECO團隊仍然保留一切權利(雖然SagaECO團隊早就消失了… 這篇主要討論繼承自Packet類的各個封包遊戲客戶端和伺服器透過不同封包來傳遞不同的信息,有玩家出現的通知,有組隊邀請的請求,有聊天信息通知…是聯繫世界中的一切的基礎。SagaECO這個ECO私服也不是例外。 這次我們從伺服器通知某人作出了坐下動作的封包入手。 每一個封包有對應的ID,這時要找的ID是121C。 除了ECore之外,se-a Packet Struct Tools也能查看封包結構。*站主曾經封鎖日本以外的IP,必要時請使用VPN。 可見兩者的記載並不吻合,在這時候建議使用Se-a的結構,它上面的資料是最新的。如果沒有理解錯誤的話,se-a的網站是從2017年起由大家分享封包紀錄。對於121C封包,舊的封包結構不兼容於新客戶端,新客戶端試圖讀取新增的第二個DWORD時舊封包就不夠長了。更常見的不兼容狀況有類型變更,例如金錢從DWORD延長為QWORD,也會導致上述的舊封包不夠長而失效。比較另類的變更涉及OpCode的變更。 兩個工具各有優缺點,整理成如下:Ecore優點– 對於資料的注釋較多、齊全、而且有提供相關連封包和流程– 是除了代碼之外唯一有覆蓋網絡層資料的文獻缺點– 資料比較舊 部分資料不適用於新版客戶端 新系統例如AAA之類 很可能會沒有相關資料–...

深入淺出SagaECO RPC篇(一) “序列爭戰”

深入淺出SagaECO RPC篇(一) “序列爭戰”

約4年前,機緣巧合地,SagaECO的源代碼輾轉落到我這個不懂編程的閑人手上…現在能跟大家一起解秘SagaECO,實是百感交集。詳解ECO私服運作的深入淺出SagaECO系列,在此出發~ 以下討論基於SagaECO svn 900版本源代碼可以從這裡下載 注意: 被分發SagaECO源代碼並不代表你被授權使用、修改、發布衍生的程式換言之SagaECO團隊仍然保留一切權利(雖然SagaECO團隊早就消失了… 這篇的主角是Packet.cs,SagaECO中所有封包皆繼承自Packet類。 Defines the base class of a network packet. Packets are send back and...

免IE進入遊戲(上):用以窺探launch.dat的一句代碼

免IE進入遊戲(上):用以窺探launch.dat的一句代碼

日服的啟動流程和港台服的很不同。日服需要先到IE登入後從IE啟動更新程式,版本檢查完成後遊戲啟動時會自動登入。這個設計的用戶體驗是很不錯的,但是隨著時代的變遷”必須使用過時的IE”這點十分令人頭痛(beanfun:在說我嗎) 於是這裡就是要把這個惱人的設定去掉~ 這裡要介紹的第一個方法是白撞XD 首先準備老版本的啟動器(沒有被強迫打開IE的),打開launch.dat 使用notepad下開,顯示如下: ????????????????????????????????????????????????????  明顯是沒有用的,打開 010Editor 00 01 DC FF DF FF D8 FF DC FF D8 FF 93 FF 96 FF91 FF 9A FF DF FF 96 FF 8C FF DF FF 9C FF 90 FF92 FF 92 FF 9A FF 91 FF 8B FF D1 FF F2 FF F5 FFDC FF DF FF 9A FF 91 FF 9C FF 90 FF 9B FF 96 FF 這裡可以抓到一個模式,除了起首的00 01之後全都是XX FF 然後我們開始白撞XDD 把其中一個FF換成FE會怎樣 足夠歐洲的話,我們會打開網頁失敗。仔細看一下發現網址錯誤了,當中的一個”i“被換成了”ũ“,因此推斷 這些 XX FF全是字符中的一部分 一個字佔用2 byte,大機率是 UTF16 然後查一下ASCII編碼表...