只要进
入这个房间后，玩家身上就会有了三层有关kill的add_action()。如果这里输入kill，
自然是先执行NPC身上的do_kill()。返回是0的话，再执行房间里的do_kill()，再是0的
话再执行kill.c。所以，在一般我们在房间，NPC以及OBJ里做的add_action()如果与/cm
ds目录下的指令相同的话，都会优先于指令先行。而且如果是后加的，肯定优先于前加
的。而其中任意一层一旦有返回1的话，就会立即中止。
　　LPMUD里基本上所有的谜题和很多特殊效果都需要借助add_action()来实现，认真理
解并掌握它的用法是相当重要的。
　　下面我们来谈谈add_action()的 BUG吧！很多老的玩家都知道它的用法，先由一个A
买一只鸡腿（包子也可以），由另一个B打昏它，然后B从A身上搜走鸡腿，再吃光鸡腿扔
掉。等A醒来输入eat jitui指令，系统便会立即当机。
　　原因分析，传统MUDLIB的eat是一个add_action()，做在食物的标准继承food.c里。
玩家买下一只鸡腿，那么这个eat的add_action()就加到了玩家身上。在正常情况下，这
个物体消失（比如吃掉）或离开玩家所处环境（比如扔掉并离开），那么add_action()
都会正常去掉。但是在玩家昏迷时，其它人从它身上拿走这个带add_action()的物体，
这个add_action()并不能正常地从玩家身上去掉。而当玩家苏醒后，这个eat的add_acti
on()依旧存在于他身上，他依旧可以执行这个指令，如果执行的对象，比如鸡腿还在游
戏中，不论这只鸡腿被玩家B带到了多远的地方，A都可以通过eat jitui吃得到这只鸡腿
。这种情况只是有点滑稽而已。但是如果这个鸡腿已经消失了，比如B吃掉了，那么它只
能消除在B身上的add_action()，这时A再执行eat，系统一下子找不到jitui这个物体，
就会从内存中载入一大堆莫名其妙乱七八糟的东西，迅速进入死循环，直接导致当机。
所以要实现这个BUG的条件有二，一是找一件有add_action()并且可以通过正常方法摧毁
的，比如食物，不值钱的东西。二是用两个ID执行。
　　目前新版本的MUDOS据说已经从底层上修改掉了这个BUG。同时明白了其中的原理也
可以在MUDLIB上用很多方法来避免这种情况的发生。
　　再下面就谈一下较少有人知的另一个BUG，这个BUG表面上看起来问题不大，实际运
用中有时会产生很大的问题，就是sleep对add_action()的影响。大家可以仔细看看slee
p.c文件，玩家进入睡眠状态就会调用一个函数me->disable_player();这个函数原型在/
feature/command.c里，最终调用disable_commands();这个外部函数，disable_command
s()的用处就是让一个活物件变成「非活着」，一是add_actions 失效，二是livingp()
返回0值......也就是说，去掉了身上所有的add_action()。然
后在醒来之后，再次调用me->enable_player();这个函数我在前面文章的第五段里介绍
过用法与作用，它只是恢复了玩家的add_action("command_hook", "", 1);也就是所有
的系统固定指令。比如玩家身上物品的add_action，所处环境的add_action都是在init(
)里加载的，玩家在sleep之后并没有呼叫到init()，自然就没有这些。那么问题就会出
现了。假如我们在一个房间里或是在一个物体上作了一个企图覆盖掉正常指令的add_act
ion（想覆盖掉正常指令，只要让这个add_action()调用的函数总是返回1就行）。那么
，玩家只需sleep一下之后，就会让这个覆盖无效。无效之后产生的问题大小就与你当初
覆盖的目的有关了。要解决这一问题，可以修改sleep.c，在玩家醒来后的一瞬间，让玩
家离开原地再重新move回到所处的环境，再让玩家身上所有的东西也同样移出去再重新m
ove回到玩家身上，这样就让系统再次加载玩家身上应该加载的add_action。
　　总之，MUDOS当初对于add_action的考虑并不是很完善。再加MUDLIB里的处理手法，