Problem with triggered scripts:

Posted by Shadowfyr on Fri 02 Aug 2002 03:21 AM — 5 posts, 20,205 views.

USA #0
I am reposting this from the previous thread to better define the problem. The following (numbered for convenience) behaves incorrectly:

1 [sales] Kaster: any poison for sale?
2 HP: [1243/1243] CONC: [2473/2473]
3 [sales] Sparhawk: 234 int, 10k/vial
4 Your body clock is back to normal.
5 [sales]: Kaster waves his hand in disapproval and goes 'bah'.
6 [sales] Sparhawk: try to find as good cheaper...
7 body clock
8 You begin concentrating.
9 Fri Aug 2 03:07:21 2002 Ex = 16416095>
10 Your blessing of Godspeed is lifted from your body.
11 xxXX Godspeed XXxx

What should be happening here is>

4 Your body clock is back to normal.
4a xxXX Body Clock XXxx
5 [sales]: Kaster waves his hand in disapproval and goes 'bah'.

The triggers and script actually involved with this are as follows:

<triggers>
  <trigger
   custom_colour="9"
   enabled="y"
   match="^[sales](.*)"
   name="Sales"
   regexp="y"
   script="setcolorgrab"
   sequence="5"
  >
  </trigger>
  <trigger
   enabled="y"
   match="^Your body clock is back.*"
   name="Body_Clock"
   regexp="y"
   script="PartyTellIt"
   sequence="99"
   sound="C:\My Documents\MUD Files\Clock Ticks Loudly.wav"
  >
  </trigger>
  <trigger
   keep_evaluating="y"
   match="^\S{1,}(.*)"
   name="General2"
   regexp="y"
   script="setcolorgrab"
   sequence="6"
  >
  </trigger>
</triggers>

sub PartyTellIt (name, output, wildcards)
  dim temp, temp2
  temp = world.getvariable("InParty")
  temp2 = Replace(name, "_", " ")
  'world.note name
  'world.note temp2
  if temp = "True" then
    world.send "party tell xxXX " & temp2 & " XXxx"
  else
    world.colournote "#FFE188","#0","xxXX "& temp2 & " XXxx"
  end if
end sub

sub setcolorgrab (trigname, output, wildcards)
  dim exptemp, exptemp2
  exptemp = "^    ([ ]*)(.*)"
  'exptemp2 = "^\S{1,}(.*)"
  select case trigname
    case "Newbie"
      world.addtrigger "colorcode", exptemp, "", 1065, 7, 0, "", ""
      world.enabletrigger "General2", 1
    case "General"
      world.addtrigger "colorcode", exptemp, "", 1065, -1, 0, "", ""
      world.enabletrigger "General2", 0
    case "General2"
      world.addtrigger "colorcode", exptemp, "", 1065, -1, 0, "", ""
      world.enabletrigger "General2", 0
    case "General3"
      world.addtrigger "colorcode", exptemp, "", 1065, -1, 0, "", ""
      world.enabletrigger "General2", 0
    case "Sales"
      world.addtrigger "colorcode", exptemp, "", 1065, 8, 0, "", ""
      world.enabletrigger "General2", 1
    case "Hero"
      world.addtrigger "colorcode", exptemp, "", 1065, 0, 0, "", ""
      world.enabletrigger "General2", 1
  end select
end sub


So.. To step through the problem that 'seems' to be happening..

3 - Trigger colors text and calls setcolorgrab, which turns on coloring of further lines.
4 - Trigger matching on non-indented lines calls setcolorgrab, coloring is turned off. Evaluation continues.
4a - Trigger matches on spell warning, executes the sound, exits without calling the script.
5 and 6 - See 3
7 User command
8 Response to command from mud - calls setcolorgrab and turns off coloring.
9 Prompt + newline
10 Wanring text triggers and calls the previously failed script.
11 Warning from the script.

Looks like this happens for me when two triggers match on the same text and both execute scripts, in which case the second one does not get called. Or at least that would seem to be the case, but considering how rare it seems to be, I can't say with 100% certainty.
Amended on Fri 02 Aug 2002 03:22 AM by Shadowfyr
Canada #1
I will concur that I also had a trigger that I expected to fire, but wouldn't... and I couldn't for the life of me figure out why it stopped. I had not made any changes to my script.

To try and test/fix it... I put something in the send box that had previously been blank. Suddenly the trigger began to work all the time again, even after removed that added command in the send box.

The behaviour was so strange and erratic, that I decided not to report it since I couldn't speculate at all why it was doing so...

Only one trigger gave me that problem.
Amended on Fri 02 Aug 2002 04:38 AM by Magnum
Australia Forum Administrator #2
One comment here ...

If a script has an error (runtime error) it is flagged internally as "flawed" (so to speak) and will not get called again (otherwise you might get the same runtime error thousands of times).

You would need to reprocess the script file to kick execution back for that trigger. That might explain why the trigger is playing the sound but not calling the script.

Alternatively, maybe there is a bug in the trigger script calling process, which is done by building a list during trigger matching, and then walking the list later.
USA #3
There are two problems with the run time error theory.

First, is that all triggers for warnings use the same script, so marking it as defective (as I have seen happen) should effect all of them.

Second, the same trigger that failed will work prior to a double match. However, fails when a double match happens and then starts to work again (without a reload), once traffic to those channels that are colored stops. It then fails again when another double match happens. This can't be a runtime error as you describe it.

I think the problem definitely has to be in the script calling process.

Magnum's problem may be related, though he says he has no trigger situations like this. He may be wrong though, his scripts and triggers are quite complex.
Amended on Fri 02 Aug 2002 07:17 AM by Shadowfyr
Australia Forum Administrator #4
Quote:

First, is that all triggers for warnings use the same script, so marking it as defective (as I have seen happen) should effect all of them.


Not necessarily. :) It stores the "dispatch ID" for the trigger routine on a per-trigger basis, if a particular call fails that dispatch ID (for that trigger) is zeroed, but others would still work (because the dispatch ID is still non-zero for the other triggers).

However I'm inclined to agree from the description of the symptoms that this is not in fact the problem.