嘛，明后天解析这个东西，用跟以前不同的方法。未来有一个重要
的东西要做，就是 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 个差不多，副本随便找一个简单
的来改。
(编辑中)