※ 引述《tenyfish (何时才有发言权?)》之铭言：
: 就我看了一下档案内容及说明文，几点回馈:
: (以一个入门者的观点来讲)
: 1. 说明档
: 十分详细，函数及变量都有标出来，
: 我个人会建议，把"特别系统"的说明分成一个文件
: ->相关档案
: ->修改会影响的其他系统
: ->游戏内相关指令
: 而.h里面直接注解说明宣告(我发现你vobj.h有做了)
: .o里面范例注解每个字段
如果确定会写系统的说明文件，那么 .h 档的注解就不会写得
太详细。一般会先写完系统才写说明文件，若在写系统的过程
中耗费太多时间在注解上，会影响系统的撰写。
注解一般是我写给自己以及 more 的人加减参考用的，因为如
果系统没有一气呵成完成，隔几天后我可能会忘记一些重要的
段落，注解的用意就是避免我忘记那些段落，或是我认为那是
很重要的段落这样，例如 vobjd.c 里面有一段..
void set_ob_data(string keyname,string tmp)
{
mixed tmps=explode(tmp,";");
int i,j=sizeof(tmps);
string tmp2;
mapping ob_data=([]),keydata=([]);
// ({"名称","编号","单位","种类","叙述",价格,携带量,能否交易,能否贩售})
if(j>0)
ob_data["name"]=tmps[0];
标亮绿色那一段就是很容易忘记其顺序与代表的意义，才会注
解在那边。
至于 .o 档要注解....很困难，但我会在说明文件里面补上栏
位说明，并请使用者与系统档对照。
我也会在同一说明文件里面加上“系统的建立、使用及移除”
一项，说明建立系统的过程，以及哪些东西会使用到这个系统
，以及怎么使它无效化。但以 chinesed.c 来说其实我就不可
能建议使用者“移除”它，因为太多东西都跟 chinesed.c 有
关，在这情况下在“建立”与“使用”上我会讲得比较详细，
而这其实就是建议使用者“顶多修改它就好而不要移除它”，
“如果真的要移除它，那干脆连 tmi2_v3_改 也一起移除”。
: 2. 关于LPC入门者
: 以DS的方法是，他Q&A建议你以非wiz身份完成一些范例任务
: 并在中间观察相对应档案的内容，了解room的设定
: 然后自己设计自己的一个区域和任务，它的文件有一些lpc教学
: 像是ob->的用法之类的
Spock@FF 以前有写了一系列的 LPC 使用教学，写那些是很累
的，而且看完后能不能懂、懂了是否就因此会了，都是因人而
异。
LPC 教学也不是 tmi2_v3_改 应该包含的东西，从“改”这个
字就可以知道，如果说 tmi2_v3 原生就有 LPC 教学相关，那
么 tmi2_v3_改 就会有，反之，tmi2_v3 本来就没有这东西的
话，tmi2_v3_改 要有就得花时间新增。
我也不建议完全没 LPC 基础的人架 tmi2_v3_改，那太花时间
，而且违背我释出 tmi2_v3_改 的本意─我不希望拿它架站的
人必须花很多时间才能架出一个站。对于一个完全没基础的人
来说，tmi2_v3_改 跟 tmi2_v3 事实上是一样的东西。
所以我还是比较建议有 LPC 底子并实际当过 wiz 的人，才较
适合使用 tmi2_v3_改 来架站。花时间写 LPC 教学文件是 ok
的，但以重要性及优先度来说它并非我现阶段的优先选项，而
且我以前也写过，根据我自己对自身的了解，我常常写到一半
就突然不写了。(那真的很烦..)
: 3. 关于一些较常见的系统
: 可以以"参见XXX mud 某系统使用"
: 例:一开始先建议使用者体验Sanc并且使用哪些功能
: 毕竟说明文件是开发工作上很花心力的部份
我之所以没说出“如果对当 wiz 有兴趣，sanc 也欢迎大家来
当 wiz”这样的话，是因为有前车之鉴，我曾收过一个 wiz，
结果他一来就自己四处 more 导致“不该看的也看了”，然后
就产生误解，例如他看了某个房间:
#include "mudlib.h"
inherit ROOM;
.
.
根据 #include 规则当使用 " " 时，它会先找物件所在目录
下有没有 "mudlib.h"，没有的话才去 /include 目录下找，
所以这房间是可 update 的，但是它的 #include 写法是错误
的，对一个来之后想自己 more 的 wiz 来说就会令他产生误
解，认为房间就是要 #include "mudlib.h"。或是:
void init()
{
add_action("push_xxx","push");
}
int push_xxx(string str)
{
if(!str || str=="")
{
write("你要 push 什么?\n");
return 1;
}
正确应该是要 return notify_fail("你要 push 什么?\n");
诸如此类的东西非常多。
sanc 存在太久规模也太大了，导致 sanc 并没有真正适合新
手 wiz 的教学环境(最大的原因是因为我自己很懒)。
但是 tmi2_v3_改 就不一样了，如果我以后用 tmi2_v3_改 架
站的话，我就欢迎完全没基础的人来当 wiz，因为我不必担心
他四处 more 会看错什么、误会什么，所有的 code 也都会公
开，并欢迎已架站的人引用。
: 4. 以我自己开发的需求来说，这版有map或wizmap的功能吗
如果是指指令 map 的话，tmi2_v3_改 有塞一个我在 2001 年
写的 /cmds/std/_gps.c 指令:
> map <= 透过 global_aliases 的设定 map = gps $*
GPS 卫星定位系统
目前所在位置: [水池广场]
｜
口─口
｜
口─口
｜
口 口 口
｜ ｜ ｜
口─⊕─口─口─口─口─口
｜ ｜ ｜
口 口 口
｜
口
｜
口─口
｜
只要是超过 10 年的东西，很容易看到一个“特色”就是我很
少用宣告 mapping 的方式去储存资料，而多半是把 mapping
资料 "set" 到物件本身，例如:
if(mark==1)
set("pos/"+x+"#"+y+"#",HIC"⊕"NOR);
else if(mark!=1 && env_name==base_name(home_env))
{
set("pos/"+x+"#"+y+"#",HIC"⊕"NOR);
return 1;
}
else if(query("pos/"+x+"#"+y+"#"))
set("pos/"+x+"#"+y+"#",HIC"口"NOR);
所以 /cmds/std/_gps.c 基本上也算是会造成误解的存在，但
因为我在改 tmi2_v3 的过程中需要它，所以才暂时放上去。
(所以那个档才没有 // laechan@sanc ... for tmi2_v3_改，
相同的情况还有 /cmds/std/_note.c，都是很早以前写的，但
note 在 2005 有经过改版，情况就比 gps 好一点)
如果要重写一个新的...老实说我看过别的 mud 也有这东西，
它们指令的执行结果，比我写的好多了，因为我没受过程式的
正规训练，有受过正规训练的人对“递回”的使用会更得心应
手，没受过训练如我“反正写出来能用就好了管它那么多”。
(包括 findmob 也是，justinj@sanc 写的也比我写的好)
不过如果你就是指 map 这个指令的话，我可以花点时间重写
一个新的，但有一点必须说明的是，map 的最大弱点就是无法
正确显示“exits 设定为传统迷宫类型的区域”，例如:
往002←001-002→往001 循环式出口设计
所以实际上 tmi2_v3_改 的 map 是与其它 mud 不同的，它是
一种新的 map，在目前的 sanc 也已实装，底下是 demo:
http://imgur.com/QBaTwVG.jpg
这个才是我理想中的 map，也是 tmi2_v3_改 会内建的东西，
但即便如此它还是有包含传统的显示方式，这个 _gps.c 指令
里面就有:
if(!map_d)
if(catch(map_d=find_object_or_load("/adm/daemons/map_d")));
if(map_d)
if(tmps=map_d->get_path_and_num(base_name(home_env)))
{
map_d->show_maps(tmps[0],tmps[1]);
return 1;
}
map_d 就是用来管理类似上面那种地图的，如果所在位置符合
map_d 所管理的那种新型态区域，它就做 show_maps 的动作，
不符合时就显示传统的 map 型式。
现阶段 tmi2_v3_改 是没有 /adm/daemons/map_d.c 的因为还
没实装到那里。
LAechan