Re: [wizs] debug.log

看板mud_sanc (Sanctuary - 聖殿)作者 (wenwen)時間16年前 (2010/01/02 10:09), 編輯推噓1(103)
留言4則, 3人參與, 最新討論串4/17 (看更多)
※ 引述《laechan (小太保)》之銘言: : 今天早上看的時候 debug.log 大小是 119,下午看的時候 : 變 145,有增肥情況,所以挑出來 debug 一下。 : 新的一年..最好臨時站主機不要出什麼意外。 : =================================================== : 執行時段錯誤: *Bad argument 1 to lower_case() : Expected: string Got: 0. : 程式: d/ppl/quest/dark/room/c.c:113 : 物件: /d/ppl/quest/dark/room/c : /d/ppl/quest/dark/room/c "gamble14" d/ppl/quest/dark/room/c.c:113 : 通常是 lower_case 裡面接的東西沒有被指定, 或者是做 : 物件 query 時根本沒這物件存在造成的. : quest 你可以檢查看看 c.c 的第 113 行。 : Expected: string or array or object Got: 0. : ", : "file" : "d/ppl/quest/dark/room/die.c", : "trace" : ({ /* sizeof() == 1 */ : ([ /* sizeof() == 7 */ : "arguments" : ({ }), : "line" : 22, : "object" : /d/ppl/quest/dark/room/die, : "function" : "die", : "locals" : ({ /* sizeof() == 1 */ : 0 : }), : "file" : "d/ppl/quest/dark/room/die.c", : "program" : "d/ppl/quest/dark/room/die.c", : ]) : }), : "program" : "d/ppl/quest/dark/room/die.c", : ]),0) : 會出現這種敘述是新版 mudos 支援的,即以前的 mudos : 遇到這種障礙時不會吐訊息、or訊息吐的不清不楚。 : 上面的意思是 die.c 的第 22 行有問題。 : 我剛看了一下程式,因為 quest 在 init 裡頭呼叫 call_out : ,然後被 call 的函數有定一個 object ppl=this_player() : 問題:若觸發的物件消失,die 函數會不會出現 bug? : 答案是肯定的,因為有一行 ppl->die(); : 若 ppl(即觸發 init 的物件)消失,這行就會出問題。 : 物件消失的通常例子.. : 一、玩家 quit : 二、怪物被殺 : 執行時段錯誤: *Bad argument 1 to call_other() : Expected: string or array or object Got: 0. : 程式: adm/simul_efun/member_group.c(adm/obj/simul_efun.c):24 : 物件: /adm/obj/simul_efun : /u/q/quest/objs/wizobj#548744 "cmd_moveall" u/q/quest/objs/wizobj.c:1271 : /std/user#440774 "move_player" std/user.c:373 : /std/user#440774 "move" std/ob/user.c:166 : /std/ob/user_d "move" std/ob/user_d.c:49 : /std/user#440774 "move_to" std/ob/user.c:172 : /d/ppl/quest/dark/room/a "init" d/ppl/quest/dark/room/a.c:16 : /adm/obj/simul_efun "wizardp" adm/simul_efun/member_group.c(adm/obj/simul_ : efun.c):24 : 一般若出現 member_group 的錯誤,通常是 wiz 相關的判斷 : 出問題造成的。 : 而 wizardp 函數裡面接的則是物件,因此跟上面類似,通常 : 是該物件已消失,不然就是該物件被殺→destruct。 : 再從 debug 訊息來看,應該是某人使用了 wizobj 欲移動到 : 某處(a.c),觸發了該地點的 init 函數.. : void init(object ppl) : { : ppl=this_player(); : input_to("choice",2,ppl); : } : 呃,我是不確定你這樣寫有沒有問題,一般程式不會這樣子寫 : ,目前已知有在 init 裡面加 input_to 的只有各公會,就是 : 在選擇是否設定主公會的判斷部份。 : 很少這樣子寫的原因,是因為 init 函數的過大適用性─只要 : 有「物件」進入該房間,就觸發 init 函數。 : 所以一般都會在 init 函數中設定過濾條件,例如.. : void init() : { : object ppl=this_player(); : if(!ppl || (ppl && !userp(ppl))) return ; // 只有玩家適用底下 : ... : } 依照目前的寫法說明一下,其主要 gamble 的方式: 1. 新區域必須經過城鎮,然後請三魔塔的封印者,為你開啟一道尋寶之門 2. 然後經過各職業的努力打敗三小魔塔主 騎士、劍士、拳士 一塔 戰士、刀客、盜賊 一塔 牧師、魔法師、警察 一塔 冒險者為皆可 3. 塔頂可以取得一解謎物件,二個趣味 obj 大地導引->解謎物件,回到木橋上見發呆的 小嘟嘟 (2次) 回歸之翼->可以讓玩家回到上一格 (10次) 煙霧魔仗->自由傳送世界各房間 (50次) 4. 塔頂的尾端,守護者 banks (它是鎮上賭場的老闆),但因為答應復仇之神的手下 所以自願守護在"封印者之間" 5. 在與 banks 戰鬥過程中,有可能因為賭場老闆過於沉悶的守護,會把你拉入 賭博間,進行賭博遊戲。 (1)賭博過程中,無需任何代價 (2)贏的話,需要幫 banks 取回它失去的物品,就可以得到一件賭場裝備(要先打好) 賭完後自動回到戰場上,繼續跟 banks 戰鬥,有可能會再度進入賭局 (3)輸的話,也不見得會死,可以選擇機會、命運,兩張紙牌,選對就可以回到戰場 上,繼續跟 banks 戰鬥,有可能會再度進入賭局 (4)在賭局一開始時可以選擇願意或不願意參與賭博,若此時放棄,不會有代價直接 回戰場上,繼續跟 banks 戰鬥,有可能會再度進入賭局 (5)在賭局已開始後換你丟骰子時,如果你放棄丟骰子的話,會有一定的代價抵消 然後再回去戰場上,繼續跟 banks 戰鬥,有可能會再度進入賭局 6. 一切的寫法都是經由 banks 機率邀請賭局,後然進入 gamble 房間 所以當一開始進入該 gamble 房間就是以 init 進入該 room 的任何物件(已判斷 必須為 ppl),init 執行後,就會以 input_to 詢問是否參與賭局,接下在,banks 會先跟你對話完,並先丟出骰子,然後會再度以 input_to 詢問是否要放棄或丟骰 子。 結果如果是贏的話,玩家就會有一個 add_action("give_xx",give); 玩家如果給 banks 物品就可得到一件賭博裝備。 結果如果是輸的話,賭場老闆會再度給玩家一次機會選擇機會、命運兩張紙牌, 此時會再度以 input_to 詢問玩家,選對就可以回到戰場上,但選錯的話,會進 入等死的 room,此 room 無法 recall and return 以及 quit,所以最好不要施 有 pray 的效果,不然會在裡面等人救你。 所以總過程中會先以 init 觸發,再執行 2 ~ 3 次的 input_to 指令。 /d/ppl/quest/dark/room/gamble.c /d/ppl/quest/dark/room/die.c input_to 沒人用過,想在此封魔地帶用看看,加上為釋出賭場裝備而準備, 目前並增加了"肉粽形狀的禮物箱"為賭場裝備之一。 Quest -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 219.69.110.219 ※ 編輯: horry7 來自: 219.69.110.219 (01/02 10:13)

01/02 10:28, , 1F
三小塔..冒險者到王那一格會被強制送回recall...
01/02 10:28, 1F

01/02 10:35, , 2F
設定是不會,你會不會看錯了....
01/02 10:35, 2F

01/02 12:33, , 3F
與 add_action 相對的是 remove_action,可看有無需要
01/02 12:33, 3F

01/02 13:10, , 4F
Thanks, 我還不知道有這相對應的 remove_auction.
01/02 13:10, 4F
文章代碼(AID): #1BFghRo2 (mud_sanc)
討論串 (同標題文章)
本文引述了以下文章的的內容:
1
4
以下文章回應了本文
1
4
完整討論串 (本文為第 4 之 17 篇):
0
1
0
2
1
1
0
4
1
8
5
14
文章代碼(AID): #1BFghRo2 (mud_sanc)