Zugg Software :: View topic - CMUD 226 - Running this script bombs CMUD with Access Violation

Posted: Wed Jun 11, 2008 12:26 am

I was experimenting with a script to recast missed spells after triggers were disabled for some reason or I lost my connection. Here is the entire XML for the script, triggers and variables that go with it:

Posted: Wed Jun 11, 2008 12:32 am

I pasted your script into a blank session and then typed "recinit" and all it did was display:

saffects

on the screen. You need to give us something else so that we can test this in a blank session. My guess is that the "saffects" command does something on your MUD that displays something the trigger fires on, but without that data, I cannot reproduce it offline.

Posted: Wed Jun 11, 2008 12:57 am

Yes, it does. If you look at the data in reclist, the key/value pairs contain what the MUD sends which looks like this:

Posted: Wed Jun 11, 2008 1:03 am

OK, that text still doesn't fire the trigger. You need to tell me EXACTLY what the MUD is displaying in response to the saffects command. Come on...it's not like I can read your mind or something. The harder you make this, the less likely it is to get fixed in v2.27.

Posted: Wed Jun 11, 2008 1:06 am

I edited my first reply to show the entire output from the MUD when I type saffects, including the ending blank line.
The main trigger fires when the line You are affected by the following: is displayed. Then the #COND kicks in and stops when the #TEMP detects the blank line.

Posted: Wed Jun 11, 2008 6:25 pm

OK, I was able to reproduce it now, thanks. It does look like a problem with the #TEMP trigger somehow, but at least now I have a way to reproduce it.

Posted: Wed Jun 11, 2008 11:15 pm

Yes, I was going to post that. I found out that the #TEMP trigger was not being deleted. I should point out that the script worked until I added the #ECHO command that outputs the carriage return. I think that the problem lies in that direction. The #TEMP trigger might be getting confused by the CR.

Posted: Wed Jun 11, 2008 11:32 pm

Yep. The #TEMP trigger doesn't get deleted until after it has finished executing. And doing the #ECHO %cr in your recproc alias is causing the #TEMP trigger to fire again.

I think all I need to do is make #TEMP triggers disable the "Trigger on Trigger" option so that they don't cause themselves to fire again. Although I thought I already had code in CMUD to prevent recursive trigger firing like this.
In any case, I hope to get time to fix this before the 2.27 release tomorrow. Still a few other things on my list that I need to fix first.

Posted: Fri Jun 13, 2008 9:19 pm

Actually, Zugg, the #TEMP isn't being deleted at all. I have found a whole stash of them in my session window class. Every time I run a script that uses this type of trigger I create a permanent #TEMP trigger, it seems.
Also, they are very hard to delete. CMUD goes does not remove them from sight until after a class or filter switch takes place. The consolation is that they seem to be reusable.

Posted: Mon Jun 16, 2008 4:43 pm

Manually delete all of your #TEMP triggers. If you have one of them still in your settings, then I think CMUD will use that instead of creating a new one.

After manually deleting your temp triggers, try it again in 2.27. I thought this bug was fixed in that version.