所以长痛不如短痛，就按照正规的语法写吧，以前 sanc 的 code
可以这样写
test_func() <= 不必宣告其型态
{
.
.
}
set("long",@^_^ <= 这样子也可以后来就不行一定要像 @LONG 或 @DESC 这样
^_^
);
ppl->move("/d/wiz/room/disc");
return notify_fail("你被移动到了这里.\n"); // 不能 return 0 一定要 return 1
#define XXX "/x/x/xxx"
int a,b,c; <= 改成一定要在 inherit 后
inherit ROOM;
诸如此类的，sanc 共换过至少三次的 mudos，第一次跟第二次换
的时候最痛苦，因为都要大修 code，但等到第三次起就轻松了，
code 几乎不太需要再改什么。反之，如果第一次、第二次都不想
大改，等越后面的 mudos 版本要求越严格时，处理就会越麻烦。
那也是因为有这些经验，越到后期写区域相关物件才会越借重产生
器，因为产生器的原理就是
原稿→产生器→实体
换言之如果将来产生出的实体有问题，只要把实体砍掉，产生器改
一改，再把原稿丢进去，出来的新的实体物件就会是符合格式的物
件，这样至少就不用再一个一个去改，而且也尽量让产生出的物件
继承共通样本，这样有时只需改继承样本就能解决。
基本上写法越符合 mudos 的要求，就执行效率上来说也会比较好。