|
|
楼主 |
发表于 2013-10-23 23:09:32
|
显示全部楼层
本帖最后由 FFUR2007SLX2_5 于 2014-2-10 17:15 编辑
171楼，武装突袭3——FSM全教程（六）
上一讲中我们深入剖析了FSM条件，下面我们继续讲讲条件的剩下两个语块，action与precondition。
这两个语块是BI在FSM编写中不会使用的，但既然保留了这两个块，我们的高级教程就有义务帮大家解释个水落石出。
我们知道BI Wiki的解释有时不清楚：http://community.bistudio.com/wiki/FSM_Editor_Manual
这些仅仅是概念上的描述，过于宏观的描述往往帮不了我们什么，所以回到教程。
先看看action。Action中的所有代码记住只会被执行一次，它不是循环，当然同样也不支持延迟。它只有在其所在的条件栏被激活后运行一次，相当于另立门户，与接下来的state是同时运行的。其实这个语块比较鸡肋，但会使用的人可以减免以下步骤：
当中的Action状态和其下的true condition可以直接省略，Action的代码可以直接并入condition的action，同样支持spawn形式的sqf语法。
再来看一下条件中的precondition语块，其实这语块和state的precondition一模一样，我们不要被bi wiki误导什么“该语块内的代码在条件执行之前触发”，这种解释太不负责任了。
其实它就是一个循环，在条件还未被激活的情况下只要引擎检查到它了就会自动运行这个循环直到条件激活后循环自动结束。（所以不要把代码写在永远都不可能被激活条件的precondition中，否则会造成死循环）
在FSM全教程的结尾中，还有几个与FSM相关的命令得和大家解释下：
先是doFSM与commandFSM。这两个东西或许会杀掉我们一些脑细胞。其实在FSM家族中他们本身并不复杂，问题往往出在priority（优先等级上）。我们必须明白ARMA3中的所有代码都不是独立的，他们每一个都有各自对应的家族，只不过是有大有小罢了。如果我们将UI家族的控制命令作为第一大家族的话，那么AI控制命令则可以称为第二大家族。上手直接就讲doFSM与commandFSM则心急吃不了热豆腐。我们还得从家族的诞生开始说起。
还记得DevBranch同步那一讲吗？在那一篇中我只给了大家一个ArmA3的wiki代码链接，或许你觉得够用了，其实不然，这些wiki的链接仅仅只显示了记录在案的arma3代码。我们用supportInfo可以得到所有的DevBranch代码，但问题是不便归类。
对于开发者来说我们还可以通过这些途径来获取ARMA3的最新资讯：
1、 脚本编辑块，其实不在ArmA3 – Script and editing中，最新的代码实验室其实也是“神”最常出没的地方。像Dwarden，japapatramtara，Kylania，Kju，DarkDruid，KillZone_Kid等等，喜欢的朋友千万不要错过这块风水宝地！http://forums.bistudio.com/showt ... cripting-Discussion
2、 对于开发者版本的玩家，如果你连游戏更新了什么都不知道还要贴上来追问的话，请到这里来：
http://forums.bistudio.com/showt ... ch-Changelog/page16 DnA和RoyaltyinExile每天都会贴出Dev的更新内容。
3、 对于那些没日没夜抱怨ARMA3的AI如何如何的“喷友”，我想说的是，还是潜下心来逛逛DEV的AI更新日志吧，看着AI每天都在变得更加聪明，难道你不会感到欣慰吗？ http://forums.bistudio.com/showt ... tain-s-AI-Log/page2
4、 如果你想提意见，表示一下你对ARMA3的看法却有抱怨“投诉无门”的朋友，赶快来这里，想要和BI Dev直接对话得找好板块咯，这里其实也是众“神”出没的地方：http://feedback.arma3.com/my_view_page.php
BI DEV对问题的接手往往也有优先秩序，不要提那些非常幼稚的问题。“我要脚架”神马的，这种属于Feature类的需求除非过了项目经理那一关，否则Dev是不会回复的。
说到这儿似乎扯远了，赶紧回到正道儿上来，我们刚才讲到了ARMA3的代码，这当然不是整个ARMA的所有家族成员，记录在册的全体成员在这里：http://community.bistudio.com/wi ... ing_Commands_Arma_3 （据不完全统计有毛1700个了，大家不用担心，就当是学习一门语言，每天学习20个也就3个月的时间）
还没完，这些只不过是注册在案的代码，还有一些最新来的朋友WIKI来不及更新就放到了这里： http://community.bistudio.com/wiki/All_Arma_Commands_Pages （那些红色的代码就是新代码了）
在欢迎了所有成员后我们得分家族了：http://community.bistudio.com/wi ... ds_by_Functionality
接着让我们进入http://community.bistudio.com/wi ... Group:_Unit_Control Unit Control家族，这里有所有关于AI控制的命令，现在来看一下最基本的三个前缀：do, command和To。为什么我要举这些例子？DoMove, CommandMove, Move和MoveTo。我们能不能区分它们的不同之处？其实这和FSM是一样的：DoFSM, CommandFSM, execFSM。虽然FSM并没有归入这一类但也有异曲同工之妙。
在没有区分它们的优先等级之前我们都是乱入的，想到什么就用什么。但是到了高级阶段了就不能这么做。在分等级以前先考考大家对UnitReady的理解，什么时候Unit才是空闲的？只有在没有路径，没有command，do和原始命令的情况下Unit才会“闲”起来。那么首先就排除了MoveTo，显然它是低级别的成员，唯一的朋友也只有是MoveToCompleted了。接下来doMove, commandMove要和Move分个高低，显然是do和command的家族位置更高。那么他们在实际中的表现又如何？Move可以轻易乱入MoveTo，doMove和CommandMove何以轻易乱入Move。MoveTo作用于单位但会被组长叫回，Move只作用于组但组长可以根据战场形式做出调节，CommandMove和DoMove作用于所有人并且享有最高指令，在DoMove的指令不完成前没有任何人能够在中途下达退出或撤离的命令。
现在回到FSM。在DoFSM，CommandFSM和ExecFSM中，前两者享有同等的优先权。再来看一下他们的结构，是相同的。只能作用于AI实物。所以DoFSM和CommandFSM是不能写任务框架的，同样不适于写脚本，因为凡是参与DoFSM的AI引擎会自动将其归入“繁忙”状态并且在完成这件事之前AI不会接受任何其他无线电指令。所以DoFSM和CommandFSM常被BI用于内部FSM如救治伤病员，或特殊任务需要单兵脱离群体执行的。
我们先来看看DoFSM和CommandFSM的结构，与execFSM不同的是它们不能传递_this，这就意味着我们在这两个命令中无需定义_this相关的变量，直接使用特殊私用变量即可：
既然结构明白了，现在我们再回过头来看Rube的那段补充就不难理解了，DoFSM和CommandFSM作为优先执行项优先于所有普通FSM和SQF，包括低级别Unit Control的命令，对于正在执行的对象全部被赋予UnitReady False值直到End State才会重新可用。所以唯一可以更改Busy值的命令只有DoFSM本身和高优先权命令，这就是为何我们可以在DoFSM中使用除限制AI移动的所有命令，像doStop这种会覆盖DoFSM本身的作用，那么这个AI就永远也达不到End State，doFSM也就无意义了。FSM还有几个尾巴，如Handler，setFSMvariable就留到FSM的最后一讲中去。再见。
209楼继续教程，武装突袭3——代码优化追加篇 |
本帖子中包含更多资源
您需要 登录 才可以下载或查看，没有账号？加入VME
x
|
楼主: FFUR2007SLX2_5
[复制链接]
发表于 2013-10-22 15:48:24
。
