Zugg Software :: View topic

Enchanter Joined: 10 Oct 2000 Posts: 656 Location: USA

using the debugger to try to track down a problem, I find it very hard to identify the line where an error occurred, thus making it difficult to figure out what trigger/mud text causes the issue.

I would suggest adding a message to the debugger or highlighting the line where an error resulted. For example, every once in a while (2-3 times an hour) I get a pop-up error message saying "the parameter is incorrect". I have not yet been able to track this down. If I leave the debugger on while mudding, as soon as the messagebox appears, I try to quickly insert a line break and disable the debugger (even then the debugger window has already scrolled a few pages), then I scan back a few pages, but nothing helps me identify where the problem occurred.

Posted: Mon Jun 09, 2008 4:57 pm

I'll give that some thought in the future, but it's hard to do. Because scripts are compiled, often when the error occurs CMUD only has the compiled low-level code and not the original script text. The popup error box should be *trying* to display the script that the error occured in. But I haven't seen the "parameter is incorrect" error myself. In fact, that doesn't sound like a CMUD error message...it sounds more like a cryptic Windows error message. Can you post a screen shot of this error message? Also, does it have a space for showing the script causing the error, or is it a crash-dump error box (with the Send error, Show error, etc buttons)?

But the Script debugger window really has no idea that an error has occured, so I'm not really sure how the debugger could show anything else that would help with this.

Enchanter Joined: 10 Oct 2000 Posts: 656 Location: USA

I tracked down when this occurs, I'm just not sure why.

It occurs each time my mud sends the autosaving message, about once every 15 minutes.

If I perform a #sh and echo the same autosaving message, the error does not occur.

Here is a debug showing it.

Posted: Fri Jun 13, 2008 2:06 am

Umm, why are you capturing everything? chances are your trigger that is capturing everything has a bug that's throwing the error.

Posted: Fri Jun 13, 2008 2:21 am

Alluran is correct...you should never have a (*) trigger pattern. That will run on every line received from the MUD and will tremendously slow down your session. It would also be really easy to accidentally get into an infinite loop if your trigger causes any sort of output at all.

Try disabling that trigger and see if that fixes the problem. Generally, the only real way to track down a problem like this is to start disabling your triggers one by one to determine which one contains the problem.

But it the above trigger is responsible, then you'll need to post the full trigger for us to see to figure out the problem.

Finally, if the message box is a plain "OK" messagebox, then it's not coming from CMUD, it's coming from Windows or something else. CMUD error messages always have buttons like "Send error", "Show error", etc.

Enchanter Joined: 10 Oct 2000 Posts: 656 Location: USA

Thanks for the help, I know this topic has gone outside the original scope, being a beta forum post.

To answer the question, essentially I have been trying to help a relative who has reading problems by setting up this trigger that would gag majority of the spam, throw the important text to a separate window and also call out to a dll to speak the important stuff through the speakers. That way he can read the text and hear it at the same time, and since he is playing a game, the reading is less like homework. --I know most players don't use proper grammar and have lots of spelling error, but I think it would still be helpful.

I know this type of trigger slows the system way down, but in this case I don't care.

If the error is not a CMUD error, then it is probably coming from the dll, but that line is supposed to be gaged, so it should not be calling the dll.

trigger (*)
script:
#IF (%replace(%line,'*','') =~ %concat("{",@StuffToGag,"}")) {#CAP GagedStuff
#GAGSPACE} {xSpeak %param}

alias xSpeak
#var sapi %comcreate("Sapi.SpVoice")
#call @sapi.Speak(%param,1)

On a side note, if I could integrate CMUD with a speech recognition program and a wireless headset, I could use it to mud while doing chores around the house. The problem with most speech recognition programs is they speak everything they see, so a trigger like this would still be required to reduce the amount of spam so that following what is going on in the mud would still be possible.

This makes me think about the possibility of cmud on a window mobile phone or blackberry, although I'm not sure if they support telnet communications.

Personally I think this is an important future for muds, to remove the monitor completely so that we don't have to be stuck inside during a nice day, we can still enjoy a walk around the block and mud at the same time using a headset. I could see this bringing mudding back into a popular fad if something like this ever went mainstream.