嘛，明後天解析這個東西，用跟以前不同的方法。未來有一個重要
的東西要做，就是 quest 內有 instance、instance 內有 quest,
但是這兩個東西我都遺忘了重要的部份:
quest: 與搜集物品及打怪有關的部份(當初寫給 norr 的)
這部份我看能不能透過法師進階轉職任務去找到蛛絲馬跡
instance: 全部忘得一乾二淨, haha......
quest 先不管(反正到時可以寫外掛硬幹)，instance 必須先找回過
去的 coding 記憶。
第一部份 全部(或大部份)重要的函數及變數列表
static mixed instance_files=({});
static mapping instance_comm=([]);
static mapping instance_data=([]);
static mapping instance_mobs=([]);
static mapping instance_mob_datas=([]);
static mapping instance_npcs=([]);
static mapping ppl_instance=([]);
static string instance_names,instance_paths;
static string instance_ob,instance_author,
instance_virtual,instance_map2data,
instance_id1,instance_id2;
static int instance_multi,instance_cd_times;
int map2data(string tmap);
int instance_set(object room,mixed tmps);
int instance_del(object room,mixed tmps);
varargs mixed instance_data(string str1,string str2);
varargs void instance_channel(object room,int k,string str);
varargs int create_instance(string ppl_name,mixed usr,string diff,string mode);
varargs int birth_npcs(object room,string npc_files,string tmp);
varargs int birth_mobs(object room,mixed tmps,string names,int lv,string diff);
varargs int init_instance(object room,object ppl);
mixed random_map(int Width,int High,int p);
int instance_set(object room,mixed tmps);
int instance_del(object room,mixed tmps);
object find_npc(object room,mixed tmps);
第二部份 回想與猜想
01、理論上這東西是「每一個副本控制物件」的繼承檔，而它有
create_instance 代表玩家「進副本時」就是呼叫控制物件
去產生對應的副本區域，一個玩家同一時間只能在同一副本
產生一個副本區域，所以產生的副本區域一定被儲存在某處
，推測是 /std/new_ob/instance_rooms.c (不是這次重點)
02、在 create_instance 內，ppl_name 一般是 this_player()
，mixed usr 是包含 ppl 在內的全部玩家(例如同隊玩家),
diff 是難度字串，mode 是 single/非single 字串。
03、依這種寫法，任務內要使用到副本的話，就一定要寫相對應
的副本控制物件，這部份避無可避；副本控制物件寫好後，
自然就可 create_instance，this_player() 呼叫該函數後
就會產生副本區域「同時」自己也會被 move 進副本區域內
04、instance_ob 的大部份東西不用看了，create_instance 會
用就行了。
05、大抵上，仍是採借用現存區域房間的做法較方便，但要使用
虛擬房間也可以:
laechan/001.c : 實體房間範例
laechan/002.c : 虛擬房間範例
laechan/003.c : 借用實體房間但地圖路線自訂的範例
laechan/004.c : 多層式副本(類似幻想神域某一類型區域)
06、理論上，若在 quest 的某步驟呼叫 create_instance 的話
，在呼叫的同時會視為玩家已完成該步驟，這時玩家若在副
本內 recall 或 quit 的話，再回到任務觸發處試圖再接該
任務時就會無法接(因為該步驟已完成)。
所以最好還是別這樣寫。
另一方面，則最好在玩家「闖過」該副本後，直接設定玩家
已闖過該任務某一步驟的標記，讓玩家得以繼續解該任務，
是比較合理的做法。實務上，stepX_npc 可設定為玩家絕對
無法抵達的房間，玩家自然無法 quest here about xxx 去
完成該步驟─只有「闖過」副本，系統才會標記玩家已解完
該步驟。
實驗主要針對的是這個部份，第 n 步驟會提示玩家去哪裡下
instance -enter，我會找現存副本來測，並修改最後一格的
判斷:
1.沒有相關任務標記的玩家: 照原本的副本流程結束
2.有著相關任務標記的玩家: 會跑不同的流程
闖過後會設定任務標記
然後再測試被設定完任務標記的玩家，能否繼續接任務
(我可能會修改 _quest.c 為 stepX_npc 增加第三種型態，
這個主要用在 quest show 及 quest shows 上面)
第三部份 實驗
暫定明天再做，任務步驟大概 4 個差不多，副本隨便找一個簡單
的來改。
(編輯中)