嘛，明後天解析這個東西，用跟以前不同的方法。未來有一個重要 的東西要做，就是 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 個差不多，副本隨便找一個簡單 的來改。 (編輯中) --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.46.142.104 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/mud_sanc/M.1503067685.A.80C.html ※ 編輯: laechan (111.253.175.38), 08/19/2017 20:37:46