记录插件的学习过程

碎碎冰先生

这次我仔细研究了一些插件，比如Scorpio、Ploop、AethysRotation、VuhDo、Ovale、Hekili等插件。
https://github.com/kurapica/PLoop/tree/master 这个写的是真好，再结合游戏增加wow专用层比如事件系统、UI相当给力。通过修改P大12.0的scorpio插件，适配魔改了7.35的版本。

玩的是735空大的单机服

7.3.5空穴来枫单机服现在跑通了3种方法确定是可以的
1、插件把游戏内容映射到像素点+图色脚本先读再运算再按键，治疗脚本用安全按钮。（7.35是可以游戏内运算的，不像12.0这样麻烦点）
2、找游戏内污染的原因83个nop点，解锁了安全函数，通过1的插件把模拟按键模块改成castspellbyname函数
3、类似ewt的dll注入

讲一下2和3，wow的污染机制是检查调用栈的身份，比如说castspellbyname用插件的身份调就弹污染禁用。
2、操作就是插件调用，从内存找到了地址禁止一个游戏就闪退，全禁止nop把taint写入焊死了。
3、dll劫持之后c代码在wndproc里直接luapcall执行lua，信任等级和暴雪UI同级不经过插件加载器。
我在7.2的时候接触到了论坛，论坛的玩具从7.2一直玩到9.1。 真是一段很美好的回忆啊。
做完这些事情以后反而不在乎具体的脚本了，写了增强萨的很流畅很完美。跑通后就没怎么想玩了。
暂时不想动脑了，玩手游去了就这样吧

vshrd

碎碎冰先生 发表于 2026-3-27 06:54 PM
不是啊就是爱好，每天一到两小时一点点喂给ai，一直改一直reload能拿到结果这个过程很开心。现在还是在 ...

技能类型可以做抽象   释放条件也能做抽象= =
慢慢加油吧

vshrd

看来你意识到了
铺得开,也要收的住.
不要动不动就什么什么牛逼方案什么什么牛逼框架,一味的追求高级,成熟,大体量.
真正意识到项目痛点在哪儿
需要用什么手段才能以最低成本最高效率最好表现效果去解决就行了.

这一块儿如果太过于依赖AI,就很容易被它带到坑里面去爬不出来
特别是针对于经验不是很足得新人而言.当然.学习阶段多了解和学习点自己技术栈外的东西也是极好的.
只是不要过于钻牛角尖.
还有萌新会觉得,既然都这样说了.那为什么不干脆就打地鼠呢.按照这个逻辑打地鼠才是最优选择.
不,不是的.即时是打地鼠,会的和不会的写出来的脚本也天壤之别.
因为认知层不一样.
比如了解过cpp底层原理的人去些py和直接起手学py只写py的人就完全是两码事.
有些知识,知道了过后,即时你不去主动使用这些知识.
这些知识也会成为你未来的思路,趋势着你往更健全更可靠的代码方向发展
而不是自己随手一写功能就出来了.虽然功能出来了,但是更多奇奇怪怪想不明白的bug也跟着出来了.

vshrd

首先GCD是公共的- -所以只需要在外部检查一次就好.
如果说你做在技能类方法canUse里.那不就成了每个技能都要检查一次了吗
当然,也可以做成静态成员变量,让类共享.
但感觉没啥必要.

另外关于技能抉择这一块儿
.我举个例子.比如一个角色有ABCDEFGHIJKLMN技能
状态1里我只分配ABCDE作为该状态的技能池
状态2里则只有FGHIJK作为该状态的技能池
状态3就只有LMN技能
这是静态的.

运行时刻.每当GCD快要归零时,开始执行技能抉择策列.
选出一个将在下一次GCD释放的技能
那么再创建一个临时技能池.
遍历该状态技能池所有技能是否符合执行条件,满足释放条件的加入临时池
比如状态1.检测释放条件后只有ACE三个技能在临时池里.

最后就在这个临时待施法技能池中判断这三个技能的优先级选出最佳技能.
这时就可以把这个最佳技能加入或插队加入待释放技能队列了.

复杂倒不算特别复杂.对比传统地鼠脚本的话,节约出的开销可不是一点半点.
对于常规地鼠脚本用户来说其实体验上根本没啥区别.
但是当接触到高级解锁器.并且需要进行大范围几十甚至上百个周围目标检测并进行技能决策逻辑时.
这里省下来的开销可就是肉眼可见的性能提升了.

vshrd

很多时候。
其实东西很简单
ai有个弊端。喜欢简单问题复杂化
它给你最好的方案不一定是最合适的你最需要的
另外ai只能当工具
驾驭ai的前提是你已经对他给出的方案有认知或者说掌握

回到你的业务中来
很简单
队列0和队列1之所以做两个
就是为了插队技能服务的
为了在添加插队技能时，不丢失我本来要释放的技能的数据
为什么只做两个
是因为1.5秒的gcd下。太过遥远的技能预测没有意义


所以问题就简单了
当需要插入技能时
检测技能队列1是否为空
如果不为空说明已经有一个紧急技能插入了队列
那么只需要比较需要插队的技能和技能队列0的优先级来确定是否替换

我们在脑子里大概过一下流程
如果你需要插队。当前技能队列已经满了。并且你想要新插入队列的技能优先级并不高于当前技能队列0
那么直接不管了，跳过等插队技能0被释放后，插队技能变成已释放技能，技能队列0变成了之前的技能队列1，之前的技能队列1变成了空。此时满足插入条件。那么你次优先的插入技能又插入进0，同时又把常规技能给再次挤回技能队列1。没毛病。符合预期。
假如你要插队的技能高于当前插队技能。那么技能队列0被赋值为新的插队技能。然后又变回根上面一样的情况
是不是不会有任何问题
那么技能队列扩充的必要性在哪儿呢？

vshrd

= =关于你提到的.打断和急救放不出来这方面的方案
可能我更倾向于在技能决策器里面做文章

我们都知道.技能输出过程为 (无CD技能释放) + 技能释放 + (无CD技能释放) + 内置CD等待
设想我们有一个容器 上次成功释放技能 等待释放技能_0 等待释放技能_1
每发生一次技能释放,每一个位置往前进一.
上次成功释放技能 = 等待释放技能_0
等待释放技能_0 = 等待释放技能_1
等待释放技能_1 = 空

我们可以不用把技能释放当作即时行为.
而是申请往我们的施法队列中添加.
但不是无限添加.我们正常的添加待施法技能的行为只会在等待释放技能_0为空时进行.

那么等待释放技能_1是拿来干嘛的呢?
这时你可能就会联想到插队了.
我们在主循环的比较靠上的位置,也就是优于一般技能抉择逻辑的地方再放一个特殊的代码域
用来检测一些紧急的特殊的全局的情况.
而这里一旦有条件达成.我们就可以尝试往当前的施法队列里插队,
那么就变成了
等待释放技能_1 = 等待释放技能_0
等待释放技能_0 = 插队技能.

而技能决策机这边 就只会正常的等待到下一次内置CD归零时.
正常的进行技能释放.
完全不会破坏现有队列.

vshrd

另外进阶区审核这块儿我已经完全没管了= =
你就正常渠道申请就行.
不会经过我这块儿了

vshrd

另外起手式为什么要用特殊的硬编码呢.

你想想.FSM对于状态的切换条件.是你自己实现的.你可以随意的编写条件.
我只需要创建一个起手式行为被状态机管理,
而起手式行为里的业务逻辑可以使用到的技能池,就只限定爆发流程所涉及到的技能.
自己简单编写编写逻辑,或直接粗暴的直接1-1-1-1...形式的无脑队列释放
然后加上一个正常自动退出行为的条件,既爆发手法中最后一个技能的成功释放
再加上一个非正常情况的自动退出行为的条件.如中途退出战斗、缺乏有效目标等等...
再加上一个进入该行为的条件,比如检查是否所有技能CD都为0.或者当前对象的目标是否符合爆发条件等

碎碎冰先生

vshrd 发表于 2026-3-9 05:14 PM
= =关于你提到的.打断和急救放不出来这方面的方案
可能我更倾向于在技能决策器里面做文章

插队好哎，明白了。原来的状态机的进入和退出的条件我想的太简单了。

vshrd

碎碎冰先生 发表于 2026-3-9 05:40 PM
插队好哎，明白了。原来的状态机的进入和退出的条件我想的太简单了。

是的
想想我当时给出的脚本范例里
为什么要做三个阶段
进入。持续。退出

老血

加油

碎碎冰先生

vshrd 发表于 2026-3-12 12:26 AM
很多时候。
其实东西很简单
ai有个弊端。喜欢简单问题复杂化

是的，谢谢大佬分享。当时没有判断好卡顿的原因，拓展好以后晚上也测了发现都排不上队就打完了。当时是问了一个ai换着法子问了两遍结果也不一样。