※ 引述《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