所以长痛不如短痛，就按照正规的语法写吧，以前 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 的要求，就执行效率上来说也会比较好。 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 1.165.196.230 ※ 文章网址: http://webptt.com/cn.aspx?n=bbs/mud/M.1400198723.A.3F1.html