這是取自 party 的構想、在實作上較為簡單的方式。 當玩家 wear all 時... suit_ob=({}); wear all 迴圈(obs) { suit=eq->query("suit_ob"); // suit=該套裝統一控制檔 if(suit && member_array(suit,suit_ob)==-1) suit_ob+=({suit}); } foreach(suit in suit_ob) call_other(suit,"check_suit",obs); 它的優點是，假設玩家身上有ｎ件Ａ套裝防具、ｍ件Ｂ 套裝防具時，則此時 suit_ob size 為 2，就會做兩次 套裝判斷。 而若是以前，則會做ｎ＋ｍ次判斷。 它的另一個好處是套裝統一由每一個 suit_ob 定義，透 過適當的設定就可以輕易讓管理者管理並瀏覽所有的套 裝，同時可輕易更動所有套裝的設定。 這個我最近會找時間實裝，完成後會請各 wiz 甚至 ppl 幫忙撰寫檔案(ppl 會撰寫的話給予稿酬，檔案很簡單), 上面也適用 wear 單一物件的情況。 它的進化式，則是各 suit 統一歸納到同一個大 SUIT 中 ，因為 obs 是同一個就能單獨傳過去，變成.. call_other(SUIT,"check_suit",obs,suit_ob); 即變成內迴型式就能增快判斷速度。 理論上上述做法沒有缺點，但要完全將缺點降到零的話， 最好還是為每一個裝備新增 remove_func，這可能也會統 一對 /std/ob/armor.c 做修改。 至於套裝統一控制檔，它的構成基本如下.. mapping suit_data=([ 定義一大堆套裝資料, 便於讀取及迅速觀看理解該套裝屬性 ]); void check_suit(object me,mixed obs) { 判斷套裝; } string get_suit_string(object eq) { 回傳套裝資料; // 這裡大概會用 switch(base_name(eq)) 來判斷 } 指令 view 的修改則以底下為重點.. if(eq->query("suit_ob")) str+=(string)call_other((string)eq->query("suit_ob"),"get_suit_string",eq); 顯示出來的樣子就類似.. 屬性：str+5 con-10 套裝：名稱─[邪靈殺意] 屬性─str+10 con+20 <= 多出來的兩行, 即若變成套裝 各位 wiz 若覺得這樣寫 ok，本週會公佈相關檔案， 有興趣的也可先行試做。 Laechan --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 61.225.160.106 理論上可以，但是 suit_ob 會寫的很複雜，因為它必須先判斷 某 eq 有沒有先被組成 5 件而不是 10 件，再者就是判斷它有 沒有已滿足 10 件套裝。 但是某 eq 可以同時是 A 套裝裝備也可以同時是 B 套裝裝備, 唯一的條件是若 eq 已經變 A 套裝狀態時就不能再是 B 套裝狀 態。 簡單一點假設 A 套裝有三件 eq 分別為 A1, A2, C, B 套裝有 三件分別為 B1, B2, C, C 就是重覆到的 eq。 則 C 的 suit_ob 可設為 SUIT_A 或 SUIT_B，這是因為要真正 執行 check_suit 的程式段一定是同時穿有 A 或 B 的情況，這 時假若穿了 A1, C, B1, B2，則 SUIT_A 會判斷到無法成為套裝 , SUIT_B 則會判斷到可成為套裝，這時 C 就會變成 B 套裝的 一部份，而不會再被 A 套裝影響到。 (因為 wearing 的判斷也會納入, 已 wearing 的東西不會再被 套裝判斷到) 這也是寫成 suit_ob 的優點之一，這個特點的最大好處就是.. A套裝：A1, A2, A3 or A1, A2, A4 or A2, A3, A4 ,.. B套裝：A1, A2, A3, A4 因為 suit_ob 是總和判斷式的，所以它允許玩家穿任三件時可 以是一件套裝，穿上第四件時又是另一個套裝。 (我想 deus 應該會對這種設定感興趣) 我個人比較傾向這樣的方式，而不是五件是一套、十件是一套， 因為那會很複雜。多一件是另一套，這樣比較好寫。 但不管如何 suit_ob 可以突破武防限制，以及不用大幅更動原 先的武防檔，是這東西實作的基本用意。 Laechan ※ 編輯: laechan 來自: 61.225.160.106 (04/07 17:27) ※ 編輯: laechan 來自: 61.225.160.106 (04/07 17:28)