[休闲娱乐]连续攻击的实现脚本
本帖最后由 sakuya452 于 2013-11-21 14:31 编辑所有该类脚本所用空间集中到一起，如有问题就名正言顺的使用全局Z变量占用的空间好了。一个全局Z变量占用512字节，平时很少用到那么多，拿来实现一个或几个棘手的问题是非常安全划算的:D这个脚本最多也就占用1个全局Z变量多一点的空间，所以转移到Z变量的空间的话，就有两个Z变量不能使用
主题无关的请PM我，但不一定有空或者有能力做的出来
了解一些ERA的会知道，ERA中有一个接收器可以方便的调用程序中的内部函数(前提是调用时机正确)，而使用UN:C改写程序逻辑的做法，可能会与该接收器冲突，产生预想以外的结果(如果将来ERA在一些时点新增一些触发器，而这个时点刚好能正确调用某些内部函数的话)，这种冲突可轻可重，有一定的担忧不是不合理的。要比个优劣的话，当然是ERA命令的发展性和兼容性更好(如果有的话)。
所以这个脚本多是作为尝鲜性质而存在的
近身的连反与额外的近身反击机会没有一个比较好的标准难以写出相对平衡的效果(这个标准指的是这类问题，单位是每次攻击受到一次反击还是数次反击，是否在数次攻击后被攻击单位才可以反击或数次反击等等)，远反需要解析远程射击子程序，远程连反和额外的远程反击机会在实现远反后同近身的问题一样
;cool;自己最近写的这两个脚本其实和ERA没多少关系，仅仅是变量使用了ERA的语法......
可以的话，不需要修改这个脚本，在其他脚本中的BR后BG1前的触发器中调用相关触发器修改堆栈对应的额外攻击次数地址的值就可以使用了。当然先要理清楚各触发器调用的顺序，不至于会出现意外效果(比如次数不符之类的)
ZVSE
**注 1:该脚本将使用 009A4DB6 - 009A4E5A 的内存地址作为战场上对应的 0-41号堆栈双击后的额外攻击次数 , 每个堆栈使用的内存地址相隔4个字节
**例:009A4DB6开始的 4个字节里存储着 0号堆栈的双击后额外攻击次数, 1号堆栈的为 009A4DBA开始的 4个字节, 依次类推直到 41号
**快速检测效果的方法，直接添加这个额外攻击次数地址修改其值。可以在 BG0,MF1中使用 UN:C来修改对应的值等应用到合适的时候
**注 2:远程射击，远程近身攻击和近程攻击的额外攻击次数地址共用同一段内存区域，也是同一个，反正可以通过检测随意设置，就这样了，节约内存空间
**注 3:每进行一次额外攻击都会减掉一次额外攻击次数，直到 0，所以在需要的时候修改对应地址增加其值就行了，士气后攻击也是一样的
**注 4:攻击方一定要有双击标志，指令的效果是和双击的第二次攻击差不多的, 应该所有双击标志单位都有效了，待测试
**注 5:和野蛮领主的残忍之斧可以叠加，不冲突, 远程单位近身攻击一样无法享有该物品效果
**注 6:远程近身攻击的总次数其实是比非远程近身攻击总次数少1的，因为本来的双击的第二次攻击没打到
!?BF&1000;
!!FU42000:P; 扩展
**将内存特定地址扩展为可以接受2次以上攻击的状态
!?FU42000;
!!UN:C4463612/4/1446076905; [00441BFC指令修改部分
!!UN:C4463616/1/0; ]
!!UN:C4463617/4/1446024937; [00441C01指令修改部分
!!UN:C4463621/1/0; ]
!!UN:C4456341/4/1447867113; [0043FF95指令修改部分
!!UN:C4456345/1/0; ]
!!UN:C10112354/4/3676403688; [新0041BFC跳转指令跳到的地址之后的指令部分
!!UN:C10112358/4/2337362175;
!!UN:C10112362/4/63631;
!!UN:C10112366/4/4106191616;
!!UN:C10112370/4/0;
!!UN:C10112374/4/230415;
!!UN:C10112378/4/3246587904;
!!UN:C10112382/4/2365885205;
!!UN:C10112386/4/10112438;
!!UN:C10112390/4/2215624837;
!!UN:C10112394/4/28;
!!UN:C10112398/4/169;
!!UN:C10112402/4/42209152;
!!UN:C10112406/4/4143972352;
!!UN:C10112410/4/76105944;
!!UN:C10112414/4/2588784269;
!!UN:C10112418/4/3914881280;
!!UN:C10112422/4/4289318363;
!!UN:C10112426/4/1357469785;
!!UN:C10112430/4/2432674254; ]
!!UN:C10112156/4/2224524114; [新00441C01跳转指令跳到的地址之后的指令部分
!!UN:C10112160/4/3238002688;
!!UN:C10112164/4/3270905834;
!!UN:C10112168/4/2659454721;
!!UN:C10112172/4/2332033024;
!!UN:C10112176/4/3531951190;
!!UN:C10112180/4/9670159;
!!UN:C10112184/4/2542469120;
!!UN:C10112188/4/656;
!!UN:C10112192/4/2232406661;
!!UN:C10112196/4/133;
!!UN:C10112200/4/45127563;
!!UN:C10112204/4/3531931648;
!!UN:C10112208/4/7832847;
!!UN:C10112212/4/2542469120;
!!UN:C10112216/4/704;
!!UN:C10112220/4/2232406661;
!!UN:C10112224/4/105;
!!UN:C10112228/4/2236372875;
!!UN:C10112232/4/1586368466;
!!UN:C10112236/4/2332033024;
!!UN:C10112240/4/33943;
!!UN:C10112244/4/48939264;
!!UN:C10112248/4/251773686;
!!UN:C10112252/4/19588;
!!UN:C10112256/4/2542489600;
!!UN:C10112260/4/248;
!!UN:C10112264/4/16039811;
!!UN:C10112268/4/251658240;
!!UN:C10112272/4/900;
!!UN:C10112276/4/365069056;
!!UN:C10112280/4/3063219339;
!!UN:C10112284/4/2231409229;
!!UN:C10112288/4/629411776;
!!UN:C10112292/4/2835349504;
!!UN:C10112296/4/2147483648;
!!UN:C10112300/4/164879;
!!UN:C10112304/4/3640066048;
!!UN:C10112308/4/2500102472;
!!UN:C10112312/4/10112438;
!!UN:C10112316/4/3345373784;
!!UN:C10112320/4/1142664965;
!!UN:C10112324/4/3918565376;
!!UN:C10112328/4/4289318457;
!!UN:C10112332/4/3345373784;
!!UN:C10112336/4/1142664965;
!!UN:C10112340/4/3897586944;
!!UN:C10112344/4/4292236053;
!!UN:C10112348/4/2848892393;
!!UN:C10112352/2/37119; ]
!!UN:C10112076/4/2846478312; [新0043FF95跳转指令跳到的地址之后的指令部分
!!UN:C10112080/4/2337493247;
!!UN:C10112084/4/63622;
!!UN:C10112088/4/4106126080;
!!UN:C10112092/4/0;
!!UN:C10112096/4/230415;
!!UN:C10112100/4/3229810688;
!!UN:C10112104/4/2233240341;
!!UN:C10112108/4/10112438;
!!UN:C10112112/4/2215631749;
!!UN:C10112116/4/29;
!!UN:C10112120/4/50167;
!!UN:C10112124/4/2215608320;
!!UN:C10112128/4/2;
!!UN:C10112132/4/2303450103;
!!UN:C10112136/4/1303807260;
!!UN:C10112140/4/1482358938;
!!UN:C10112144/4/2847074793;
!!UN:C10112148/4/3914882047;
!!UN:C10112152/4/4289311486; ]
!!UN:C4463535/2/20597; 不知道会不会有逻辑意义上错误的地方，以防万一
!?BA53&1000;
!!FU42001:P; 还原
!?FU42001;
!!UN:C4463612/4/827514344;
!!UN:C4463616/1/0;
!!UN:C4463617/4/746875880;
!!UN:C4463621/1/0;
!!UN:C4456341/4/4294346472;
!!UN:C4456345/1/255;
!!UN:C10112354/4/0;
!!UN:C10112358/4/0;
!!UN:C10112362/4/0;
!!UN:C10112366/4/0;
!!UN:C10112370/4/0;
!!UN:C10112374/4/0;
!!UN:C10112378/4/0;
!!UN:C10112382/4/0;
!!UN:C10112386/4/0;
!!UN:C10112390/4/0;
!!UN:C10112394/4/0;
!!UN:C10112398/4/0;
!!UN:C10112402/4/0;
!!UN:C10112406/4/0;
!!UN:C10112410/4/0;
!!UN:C10112414/4/0;
!!UN:C10112418/4/0;
!!UN:C10112422/4/0;
!!UN:C10112426/4/0;
!!UN:C10112430/4/0;
!!UN:C10112156/4/0;
!!UN:C10112160/4/0;
!!UN:C10112164/4/0;
!!UN:C10112168/4/0;
!!UN:C10112172/4/0;
!!UN:C10112176/4/0;
!!UN:C10112180/4/0;
!!UN:C10112184/4/0;
!!UN:C10112188/4/0;
!!UN:C10112192/4/0;
!!UN:C10112196/4/0;
!!UN:C10112200/4/0;
!!UN:C10112204/4/0;
!!UN:C10112208/4/0;
!!UN:C10112212/4/0;
!!UN:C10112216/4/0;
!!UN:C10112220/4/0;
!!UN:C10112224/4/0;
!!UN:C10112228/4/0;
!!UN:C10112232/4/0;
!!UN:C10112236/4/0;
!!UN:C10112240/4/0;
!!UN:C10112244/4/0;
!!UN:C10112248/4/0;
!!UN:C10112252/4/0;
!!UN:C10112256/4/0;
!!UN:C10112260/4/0;
!!UN:C10112264/4/0;
!!UN:C10112268/4/0;
!!UN:C10112272/4/0;
!!UN:C10112276/4/0;
!!UN:C10112280/4/0;
!!UN:C10112284/4/0;
!!UN:C10112288/4/0;
!!UN:C10112292/4/0;
!!UN:C10112296/4/0;
!!UN:C10112300/4/0;
!!UN:C10112304/4/0;
!!UN:C10112308/4/0;
!!UN:C10112312/4/0;
!!UN:C10112316/4/0;
!!UN:C10112320/4/0;
!!UN:C10112324/4/0;
!!UN:C10112328/4/0;
!!UN:C10112332/4/0;
!!UN:C10112336/4/0;
!!UN:C10112340/4/0;
!!UN:C10112344/4/0;
!!UN:C10112348/4/0;
!!UN:C10112352/2/0;
!!UN:C10112076/4/0;
!!UN:C10112080/4/0;
!!UN:C10112084/4/0;
!!UN:C10112088/4/0;
!!UN:C10112092/4/0;
!!UN:C10112096/4/0;
!!UN:C10112100/4/0;
!!UN:C10112104/4/0;
!!UN:C10112108/4/0;
!!UN:C10112112/4/0;
!!UN:C10112116/4/0;
!!UN:C10112120/4/0;
!!UN:C10112124/4/0;
!!UN:C10112128/4/0;
!!UN:C10112132/4/0;
!!UN:C10112136/4/0;
!!UN:C10112140/4/0;
!!UN:C10112144/4/0;
!!UN:C10112148/4/0;
!!UN:C10112152/4/0;
!!UN:C4463535/2/20597;
!!DO43000/0/41/1:P;
!?FU43000;
!!VRy1:Sx16*4+10112438;
!!UN:Cy1/4/0;
**以上请不要随意修改
**新加指令还原额外攻击次数的时点不方便，比如死亡后额外攻击次数清0，不能行动后清0等(按照指令执行顺序，在这些异常状态下，会保留相应堆栈剩余的额外攻击次数的)
**考虑到在触发器中还原就足够了，所以没有写到新指令中
**以下是根据实际游戏的逻辑对指令在控制额外攻击次数方面的补充，理解处理逻辑的也可以自行设置
!?BF&1000;
!!DO43000/0/41/1:P; 双击后的额外攻击次数清0
!?BR&1000/v997>=0;
!!DO43000/0/41/1:P; 双击后的额外攻击次数清0
!?BG0&1000;
!!BG:N?y1;
!!SN:W^Combo.Stack^/y1;
!?BG1&1000; 任意一次行动后额外攻击次数清0
!!SN:W^Combo.Stack^/?y1;
!!VRy2&y1>-1/y1<42:Sy1*4+10112438;
!!UN&y1>-1/y1<42:Cy2/4/0;
效率好高，赞一个先。;hap;
测试过吗。:nianjing: 高手！！！
又一个难题解决了，不知道可不可以解决100%死眼与100%致命一击啊。现在这二个经验特技100%几率无效啊 本帖最后由 贤知有您 于 2013-10-18 09:30 编辑
看了这段代码,我只能说
楼主你真是太用功了.佩服佩服.(跟梦魇一样,楼主是个晚上工作的神秘家伙)
有空得测试以下.
另外,为何要攻击方有双击标志?
能不能单纯的增加攻击,在非双击标志下也能实现?
我在HC论坛问过增加攻击次数都没人答复.
没想到咱们论坛还真有完成这项的高人.
:good_job: 接二楼的.我也不客气了.
希望楼主能是用修改内存的方法解决以下问题:
1.堆栈的吸血标志.
2.堆栈的死亡凝视标志.
3.堆栈的真正远程反击
4.堆栈的真正抢先反击
5.堆栈的反击连击
致命一击其实没多大意义,实际上直接在MF触发器改更加容易.
其它诸如施法也容易做,单单吸血和死亡凝视属于内部技能,无法直接调用. 高人请加入到359的开发中来吧 兽哥哥 发表于 2013-10-18 12:35
高人请加入到359的开发中来吧
;cool;对不起啊，我不会php
而且我也没有足够的时间全用到WOG上面的
加入到开发队伍可能做不到了 本帖最后由 sakuya452 于 2013-10-18 16:25 编辑
贤知有您 发表于 2013-10-18 09:28
看了这段代码,我只能说
楼主你真是太用功了.佩服佩服.(跟梦魇一样,楼主是个晚上工作的神秘家伙)
有空得测 ...
因为连击的效果就是这样的吧，而且这样已经可以做到任意攻击次数了，如1次、2次、3次等等。想要攻反->攻反->攻反->...这种模式的话，就要再深入下去找地址 本帖最后由 sakuya452 于 2013-10-23 16:26 编辑
贤知有您 发表于 2013-10-18 09:36
接二楼的.我也不客气了.
希望楼主能是用修改内存的方法解决以下问题:
1.堆栈的吸血标志.
;cool;看看吧，以后有空的话，要是没有别人写过，我再试试写吧
吸血，死亡凝视之类不能当作标志能力添加给生物的，一般都是程序作特殊处理的效果，严格上来说，是没有这些标志的，但是却有一个字节类似于标志的效果。比如造成伤害时，检测到给予伤害的一方为雷神领主，则进入附加闪电的指令处理，如果是地狱九头蛇，就进入附加酸液的指令处理等等。难的是，这些不是独立的，而是都在同一个子程序里完成的，只不过是条件不同就执行不同的部分，而这些就是通过那个字节的数值来控制的。仅通过这个字节来给予特殊效果是行不通的，因为附加效果处理程序执行了一种生物的附加效果后就返回了，就相当于，如果修改这个字节，给雷神吸血的话，那原来的闪电便不会执行了。
所以要把这个吸血独立出来，当作标志来给予别的生物而不影响别的生物自身的附加效果，要改的地方也不少，而且就算测试成功几次，也不确定未测试过的会不会出现问题，我没有全部理清楚那些指令逻辑的。另外一个就是又要多占用内存空间来当作吸血标志了。
单单修改血龙吸血几率的话，修改00756D6E(十六进制)这个地址开始的1字节的数值就可以了(例: !#UN:C7695726/1/50;则血龙的吸血几率为50%
sakuya452 发表于 2013-10-18 15:22
看看吧，以后有空的话，要是没有别人写过，我再试试写吧
楼主强淫，无限膜拜:good_job::good_job:
如此超级的技术不多为WOG造福大众实在可惜了。。。
如果能实现远程反击、抢先反击、反击连击就更牛B，
另外，我猜想生物致命一击、幸运一击或触发火盾时类似吸血这些应该有特殊的标志才对，这些都能找到吗？ @sakuya452
真诚希望你能常来论坛;hap;;hap;;hap; 沧海一粟 发表于 2013-10-18 22:00
楼主强淫，无限膜拜
如此超级的技术不多为WOG造福大众实在可惜了。。。
如果能实 ...
不用这样过分抬举啊(笑)
:shangxin:比起这个我倒是更想知道写的脚本能不能成功用到别的地方，是否有BUG
我会对自己做的事尽量负责的，当然不知道问题在哪就无所适从了，难道所有人都能完美无错么
;bf;我还要应付生活，顺利了再来谈爱才对啊(迷之音1:很多地址不是想找就那么好找的，要找到方法才行，慢慢来吧，心急吃不了热豆腐。迷之音2:与其靠楼主这么个不稳定的家伙，不如自己有空学习学习，自力更生也不错啊) 本帖最后由 sakuya452 于 2013-10-19 15:32 编辑
其实远程射击子程序的地址也找到了，但是如果真要实现远反，攻击反击->攻击反击->攻击反击这种模式的话，逻辑结构可能要改动，所以我就没写到。目前在分析远程射击，单位近身攻击这二个子程序中，单位近身攻击无论远近程都是共用一个子程序的，只不过在检测双击通过后再检测射击标志，有的话直接跳到结束而已......不知道能不能看懂。不管这个的话，可以很快实现远程N连射 LZ，我用了1楼的代码，发现有时候的攻击次数不对，没有加上额外的攻击次数。 本帖最后由 sakuya452 于 2013-10-19 14:04 编辑
神圣炽天使 发表于 2013-10-19 13:40
LZ，我用了1楼的代码，发现有时候的攻击次数不对，没有加上额外的攻击次数。
是否堆栈号对上额外攻击次数的地址了呢？攻击方是否有双击标志呢？攻击方或被攻击方是否处于异常状态了呢？根据战场生成时部队位置和种类的不同，战场上它们所对应的堆栈号也会发生变化的。可以的话，我希望你用CE添加对应堆栈号的额外攻击次数的内存地址来检测，这样你可以清楚的看到这个数值是怎么变化的，也许测试上更方便些 本帖最后由 神圣炽天使 于 2013-10-19 13:52 编辑
sakuya452 发表于 2013-10-19 13:43
是否堆栈号对上额外攻击次数的地址了呢？攻击方是否有双击标志呢？攻击方或被攻击方是否处于异常状态了呢 ...我不懂编程的，也不太懂ERM。攻防我都是用十字军测试的。
!?FU43000;
!!VRy1:Sx16*4+9780936;
!!UN:Cy1/4/0; 就是把0改成2， 神圣炽天使 发表于 2013-10-19 13:46
我是用十字军测试的。
!?FU43000;
!!VRy1:Sx16*4+9780936;
这个触发器在战场生成时只被执行过一次啊......我本意是用来初始化的，只改动这里的话，那你只有十字军的第一次攻击行动是有4连击，后续都是正常的2连击。我这样写是面向脚本作者的，可以让他们自由发挥，所以要先理解我这个脚本 本帖最后由 sakuya452 于 2013-11-22 22:49 编辑
你可以将以下脚本添加到一个新的脚本中，我只是简单写了下，没有把检测条件补完整，不过测试也足够了
ZVSE
!?BG0&1000;
!!BG:N?y1;
!!BMy1:T?y2;
!!VRy3&y2=7:Sy1*4+10112438;
!!UN&y2=7:Cy3/4/2;
sakuya452 发表于 2013-10-19 13:54
你可以将以下脚本添加到一个新的脚本中，我只是简单写了下，没有把检测条件补完整，不过测试也足够了
谢谢，明白了，我加上这个代码后再把!?BF&1000改成!?BR&1000试试。 神圣炽天使 发表于 2013-10-19 13:58
谢谢，明白了，我加上这个代码后再把!?BF&1000改成!?BR&1000试试。
嗯，这样也是会出现点意外效果的，具体等你以后补上更多的ERM知识后再自行理解吧
