哀冬新版：虛空之花V1.52-源碼公布，深入魔獸世界插件框體系統設計

來自哀冬大神4月新作，小編注：我知道大家看不懂，想要直接的拿來就按的一鍵傻瓜式，正在整理

喜歡研究的可以看哀冬這次的源碼：https://cn.wago.io/0jyJ6PFcF

不喜歡研究等喂飯的一兩天整理好發布引言插件系統是《魔獸世界》開放性的基石，游戲的設計師們在玩家創造力與游戲公平性之間，也構建了一道看似不可逾越的屏障。而虛空之花正扎根在這道屏障上的裂隙優雅綻放。本文將基于虛空之花的歷代內核原理介紹逐步向大家揭示魔獸世界插件系統中的高級框體設計技巧，也作為第五代內核源碼開放的序幕。第一章 移形換影-框體和安全框架隔離系統簡介

魔獸世界的插件系統建立在嚴格的安全框架之上。而整個UI設計中的框體分為兩類：普通框體（Frame）和安全框體（SecureFrame）。普通框體可以自由修改大小、位置、紋理等屬性，但無法綁定任何戰斗動作；安全框體（如SecureActionButtonTemplate）則能綁定技能、物品、宏命令，卻受到“限制環境”（Restricted Environment）的嚴格約束——戰斗中，任何來自“非安全代碼”（通常指來自玩家的插件代碼）的修改企圖都會被系統拒絕。該安全框架系統自TBC開始上線一直持續至今，用以保護游戲的開放API不被濫用于破壞公平性的插件。

第一代虛空之花的方案十分的簡單，因為當時安全框體雖然不允許修改綁定的技能但是居然可以在戰斗中調用SetPoint修改位置。我們只需在戰斗前，通過CreateFrame創建數十個綁定好技能的安全按鈕，并將其預先放置于屏幕可視區域之外。而戰斗中，當APL（輸出優先級循環邏輯的縮寫）計算出當前最佳釋放技能時，直接將對應的按鈕通過SetPoint函數瞬移到屏幕中的固定位置。玩家只需持續點擊該位置，就會自動點中當前最優技能按鈕。始于簡單粗暴終于簡單粗暴，在WLK懷舊服更新幻化的版本后，安全框體無法再在戰斗中被非安全代碼移動了。

第二章 光暗交織-安全框體回調系統簡介

安全框體并不是完全無法在戰斗中修改的，它只是不能被“非安全”代碼修改，那么什么是安全代碼呢？安全代碼包括了游戲UI自帶的代碼以及，重點來了——還包括玩家在戰斗之外通過開放API接口預先綁定在特定安全事件上的預設代碼片段！看似復雜，但是我們參考一下安全回調注冊API的解釋（https://warcraft.wiki.gg/wiki/API_SecureHandlerWrapScript）。這個接口允許為安全框體的事件（如OnClick、OnEnter）注冊一些代碼片段以字符串形式注入安全框架內執行。唯一的限制是這串代碼必須在戰斗前預設，且安全區內與安全區外的執行環境完全不同，只允許有限的函數被玩家調用，具體參考（https://warcraft.wiki.gg/wiki/RestrictedEnvironment）。

同時，雖然在戰斗中無法通過“非安全”代碼修改安全框體屬性，但是我們可以修改普通框體的屬性來干擾玩家對安全框體的操作。比如將一個普通框體覆蓋在安全框體的上層，通過控制普通框體的尺寸大小來控制玩家是否能點擊到安全框體。結合函數列表查閱我們又注意到了SetPropagateMouseClicks，這個函數允許將框體設置成可以點擊穿透。那么一切就緒，第二代方案思路已經構成。將一大堆框體按照“普通-安全-普通-安全”這樣交叉疊放，其中普通框體是否穿透受APL控制，安全框體始終可以穿透。當一次玩家點擊可以穿透多少層普通框體就代表可以觸發幾次安全框體的OnClick事件，然后我們記錄這些事件的發生次數就可以在安全區內得到非安全區傳遞的信息。

該方案發布一個月后，游戲中修改了戰斗中的點擊穿透機制，從此在戰斗中安全框體無法再被穿透了，為此不惜連帶影響了一批UI插件。但這次經歷讓我們深刻理解了安全框體的事件回調機制，并證明安全框架并非絕對安全——只要存在交互，就存在信息傳遞的可能性！

第三章 量子糾纏-框體聯動關系簡介

前兩代方案都依賴鼠標交互，戰斗中不斷點擊鼠標在走位頻繁的戰斗中非常不便。這讓我們思考是否存在非交互型的技術路線，而直接從安全框架設計的邏輯上找到突破口。我們仔細研究框體的每一個API（https://warcraft.wiki.gg/wiki/Widget_API）。

注意到CreateFrame接口的第三個參數叫做parent，這是給一個框體創建時指定它的父親。這個設計的存在可以讓新創建的框體繼承父框體的屬性并讓他們建立依附關系。比如一個大界面下可以依附許多按鈕，當你關閉界面時界面內依附的按鈕也會一起消失，這種同進同退的聯動關系極大的方便了界面開發，不再需要細枝末節的控制每一個框體的細節動作。你可以在游戲中輸入/fstack來觀察游戲界面內的每一個框體和他們的依附關系。那么能否將非安全框體和安全框體聯動起來？SetParent接口進入了視野，這個接口允許我們在戰斗中動態的修改框體父子關系。但它也存在巨大的限制，即當安全框體設定普通框體作為父節點時，系統為了防止非安全代碼通過父節點影響安全子節點，會將整個父節點升格為安全框體。這種“安全提升”機制本意是為了防止玩家濫用，但實際上卻成了一根筋兩頭堵。

第三代方案基于對此機制的利用，我們在戰斗前創建普通父框體，設置其各種屬性（比如以大小尺寸數值作為信息傳遞通道），然后讓其領養一個安全按鈕作為子節點。在父子綁定的瞬間，父框體被提升為安全框體，其當前所有屬性被連帶進入到安全環境中。戰斗中我們就可以直接讀取這個升格為安全框體的普通父框體屬性作為信息傳遞通道在安全區內直接使用！

第三朵虛空之花在ICC開放前夜發布，由于其完全不依賴鼠標純鍵盤驅動的良好體驗，引發了社區劇烈震蕩，乃至于全網貓德外掛都頂著哀冬的名號蹭熱度。直到一個多月后，開放API的版本更新，戰斗中任何修改安全框體父子關系的操作都會失敗，但邏輯路線的突破口已經證明了所謂的“安全框架”表現并不理想。

第四章 無中生有-污染系統簡介

第四套方案的故事開始之前，我們要先提到一個重要的概念“污染”。前面提到的“安全”和“不安全”，是面向框體這類數據結構的屬性概念，它標記了一個框體能辦到什么不能辦到什么。而污染則是面向執行狀態的概念，標記著當前執行流程能辦到什么不能辦到什么。插件系統總是從游戲原生代碼開始執行，一直保持干凈狀態直到調用到玩家的第三方插件代碼就會變成污染狀態。污染狀態下寫入的數據也會被污染，而原本干凈狀態執行的代碼讀到這些被污染的數據又會被傳染成污染狀態，被污染的代碼和數據將無法在戰斗中正常工作。這套機制嚴格的保證了原生代碼不會被第三方代碼劫持從而實現一些不合規的操作。

過去的多個版本我們一直期待著有一個“信使”能夠從非安全區出發把信息傳遞到安全區，或者反過來從安全區出發把非安全區信息帶回，但是安全框架隔離機制阻止了這個過程，讓“信使”總是無功而返。那么仔細想一想一個問題——沒有信息本身是不是一種信息？結合前面提到的“污染”再思考一下呢？4.x內核的方案原理就基于【這段文字好像覆蓋滿了觸手，所以我們決定暫不揭曉】，從而實現了信息的傳遞。

第四朵虛空之花的根深深的扎在了整個安全框架之上，猶如上古之神的根須已與艾澤拉斯的中樞糾纏在一起難解難分，為什么當年阿曼蘇爾拔掉亞煞極之后不繼續拔掉克蘇恩、尤格薩隆、恩佐斯呢？

第五章 時空轉換-原生UI之殤

之前第二代方案是基于玩家鼠標與框體空間上的互動來實現的，即一次操作多重觸發。在版本更新后，一次用戶操作（比如點擊、移動）只能讓一個安全框體響應一次了。那有沒有辦法讓信息不經過用戶操作而觸發變化的呢？我們視野回到安全區內的函數列表（https://warcraft.wiki.gg/wiki/RestrictedEnvironment）的第一個函數SecureCmdOptionParse，它的作用是用來解析宏命條件的。宏的解析不需要玩家的實際操作，當你的鼠標指向敵人時候SecureCmdOptionParse("[@mouseover,harm]0;1")的結果就是0，反之就是1。所以我們以時間換空間，創造一個類型為“SecureUnitButtonTemplate”的敵對目標框體，再在它的之上覆蓋一層不可指向的普通框體，從而控制玩家鼠標是否能指向這個敵對目標框體來影響宏條件判定進行一連串1和0的信息的傳遞。方案成功了？

不，還沒有成功，上述方案還欠缺重要的一個環節，安全區內沒有觸發源來驅動SecureCmdOptionParse的宏判定。如果讓人手工來狂按鼠標鍵盤進行觸發的話體驗太糟糕了（之前的B站up主@隱幻殺曾經嘗試到了這一步）。我們需要找到一個在安全區可以穩定的觸發源，那么一定有聰明人想到了SecureHandlerWrapScript不是可以注冊OnHide和OnShow事件嗎？我們讓框體在觸發OnShow回調的時候調用Hide函數，然后再在觸發OnHide回調的時候調用Show函數。豈不是可以讓一個安全框體一直閃爍，在閃爍的安全回調代碼中判定SecureCmdOptionParse。方案成功了？

不，還沒有成功，因為聰明的游戲設計師也考慮到了這一點。SecureCmdOptionParse的判定依賴于界面的真實繪制，憑空在lua代碼里控制消失和顯示并不會真的讓框體馬上消失和顯示，會影響SecureCmdOptionParse的判定。所以第五朵虛空之花綻放的真正核心要素是要在安全區邏輯內找到一個穩定的異步觸發源。于是我們把目光轉向了原生UI代碼，從中尋找機會。

我們發現原生UI接口中，為了解決安全框體自動隱藏接口，后臺設定了一個叫做SecureHoverDriverManager的系統框體對注冊自動隱藏框體的狀態管理，當沒有需要關注的狀態時他會隱藏，于是我們利用一個誘餌框體在安全區內調用RegisterAutoHide引誘其現身后，利用它無事自動隱藏的特性綁定了SecureHoverDriverManager的OnHide回調作為我們的異步觸發源。在經歷了一段時間的原生UI渲染管線時序摸索后，我們找到了穩定每3幀渲染tick觸發一次1/0bit位傳輸的窄信道。

至此第五朵虛空之花湊齊了宏命令判定、框體遮蓋技巧、安全區異步觸發源這套OTK卡組，實現了跨越安全框架的信息傳遞！

第六章 凋謝與新生-插件系統的設計哲學之變

回顧這幾朵虛空之花的綻放之姿，我們看到的不僅僅是一連串代碼的進化，更是一群業余插件開發者們在游戲劃定的紅線邊緣試探的極致體現。結合近期正式服大量禁用戰斗類插件API的動作，這類WA的存在引發了一個深層次的社區爭論：虛空之花這到底算不算外掛？

對于普通玩家而言，此類WA實現了近乎完美的自動化輸出，功能極其強大，在表現形式上與傳統的按鍵精靈或內存掛十分接近，因此很多人將其視為破壞平衡的“外掛”。但從技術合規性的角度來看，該系列WA從頭到尾沒有讀取任何非法的內存數據，沒有注入任何外部程序，其每一行代碼、每一個機制，都是利用魔獸世界原生提供的合法API和UI機制編寫的。基于這種現實，虛空之花不是掛！

但插件真正的邊界究竟應該劃在哪里？這或許是游戲自身需要去解答的問題。我們很高興看到在正式服中，插件系統的設計哲學已經做出了改變，游戲內推出的一鍵輸出解決了新手上手困難問題，12.0插件開發API大幅度刪減也幾乎終結了BOSS難度和插件軍備競賽的螺旋。而懷舊服作為一段凝固的時光，其插件框架被鎖定在過去。過時的設計和玩家的新需求錯配之下，我們看到的是游戲生態的持續惡化，如果繼續置之不理放任崩壞，那虛空之花也將永不凋謝~

點下方留言 分享你的觀點