預計新增該指令。
構想是，當房間存在 unboxing/ppl_name 時，即:
room->set("unboxing/"+ppl_name,n+time());
則該 ppl 在該房間下 look 時，會看到可以 unboxing 的訊息。
n+time() 即該 ppl 可下 unboxing 的時間判斷。
指令的結構大致如下:
int cmd_unboxing(string str,object me)
{
object env;
string ppl_name=me->query("name");
if(!env=environment(me)) return 0;
if(env->query("unboxing/"+ppl_name)<time()) return 0;
write("unboxing 的訊息。\n");
return call_other("/open/cmds/unboxing","unboxing",me,ppl_name,env);
}
int unboxing(object me,string ppl_name,object env)
{
string paths=env->room_path(),files=base_name(env);
// 先做能否 unboxing 的判斷
// 通過判斷就把 unboxing 刪掉
env->delete("unboxing/"+ppl_name);
// 然後可根據 paths
switch(paths)
// 也可根據 files
switch(files)
// 來對映要做什麼事情
return 1;
}
理論上做得到。它具有以下好處;
一、unboxing 是全域指令，所以具可控管性。
二、/open/cmds/unboxing.c 方便修改，進一步來說，讓它
再呼叫特定的 unboxing 分支.c 是比較適合的做法。
各 wiz 就可依需要自定 unboxing 分支.c 檔)
或者在 room 的 unboxing 裡面就寫死只能呼叫什麼。
(一般我會採這樣的做法)
三、指令可進一步寫成參數回傳式，也就是各 unboxing 分支.c
檔雖然是自訂的，但只要求這些分支檔回傳必要的參數回來
，後續動作依然是該指令去做。
(這也是一般我會採行的做法)
缺點是會比較欠缺變化性，較不好寫，但非常易於控管。
目前我新增東西的習慣都是以易於控管為較優先的考量，這東西
若寫出來了會公告試用，初期會先在零落的王墓的BOSS房試用。
Laechan