Trigger/script execution order mixup?

Posted by Ked on Sun 09 May 2004 06:37 PM — 5 posts, 21,174 views.

Ked Russia Sun 09 May 2004 06:37 PM #0

In trying to make a small setup for channeling chat out of my output window and into a notepad one I stumbled upon something that surprised me - I use a prompt trigger with a sequence of 0 to disable a * trigger with a sequence of 1, and both triggers call the same script sub. It seems that this script is called only after all triggers have matched on a line, so the sequence 1 trigger is disabled already after it matches, even though it is being disabled by a trigger with sequence 0. Here's the actual setup:


<triggers>
  <trigger
   keep_evaluating="y"
   match="^[0-9]+h, [0-9]+m \D*?-.*$"
   name="chat_end"
   regexp="y"
   script="ChannelChat"
  >
  </trigger>
  <trigger
   match="^(.*)$"
   name="chat_middle"
   omit_from_output="y"
   regexp="y"
   script="ChannelChat"
   sequence="1"
  >
  </trigger>
  <trigger
   enabled="y"
   lines_to_match="2"
   match="^(?:[0-9]+h, [0-9]+m \D*?-|)([A-Z][a-z]+? (?:say|says), &quot;.*)$"
   name="chat_start"
   omit_from_output="y"
   regexp="y"
   script="ChannelChat"
   sequence="100"
  >
  </trigger>
</triggers>

And the script:


sub ChannelChat(name, output, wildcs)
	select case name
		case "chat_start"
			world.AppendToNotepad "Chat", wildcs(1) & vbCRLF
			world.EnableTrigger "chat_middle", 1
			world.EnableTrigger "chat_end", 1
		case "chat_middle"
			world.AppendToNotepad "Chat", wildcs(1) & vbCRLF
		case "chat_end"
			world.AppendToNotepad "Chat", vbCRLF
			world.EnableTrigger "chat_middle", 0
			world.EnableTrigger "chat_end", 0
	end select
end sub

The problem goes away if the prompt trigger sends its portion of the job to scripting, instead of calling the sub directly. This seems odd and I don't think it worked that way previously, though I might be wrong. In any case - the problem isn't major or immediate in this particular case, just wanted to clarify what is happening.

Nick Gammon Australia Forum Administrator Mon 10 May 2004 07:13 AM #1

Triggers that call a sub have the sub calls queued, whereas "send to script" does it immediately. This was really done so that "omit from output" can omit the lines, and then the trigger scripts run, so that the world.note will add after the output is omitted. Also, if a trigger fires more than once on a line, the script is only called once.

Thus it would not surprise me if "send to script" ran before script subroutines.

Ked Russia Mon 10 May 2004 12:10 PM #2

So that is expected then? Okay. I guess it's not too much of a problem, since I can always just send to scripting as a workaround, and maybe use 2 triggers for the same line if I want to both omit the line from output and execute a script on it.

Shadowfyr USA Mon 10 May 2004 07:27 PM #3

Hmm.. Interesting Nick. So a person could make one low numbered trigger using 'send to script' to read in the information for a line, then a second to omit it, but if you try to use a script to handle reading in the line before omitting it, it would fail, since it will have cleared the line before it is able to retrieve the styles and other information?

Not exactly consistent behaviour, but knowing that it behaves in such a manner, instead of more logically executing each trigger event as they happen, before testing against higher sequenced triggers is helpful. Knowing this you can trick the client into doing some things that are impossible otherwise, but it does introduce some interesting complications when you are not aware of it. In fact, for the above situation, you could have 'send to script' merely call a sub directly:

<send>call StoreLineInfo(getlinesinbuffer)</send>

so that the line you need is available for use when the omit trigger hits and calls its own sub to replace the original with a new one. Very interesting...

Nick Gammon Australia Forum Administrator Mon 10 May 2004 09:59 PM #4

Ah yes, true.

This behaviour is why you cannot do world.Note in "send to script" in triggers that omit from output. The way it works is to omit from output from the start of the line that did the triggering, and if your notes happen to be on the end of that they get omitted too.

Thus, the sequence is, if a trigger matches:

Play trigger sound if wanted.
Do "send" stuff. Note that "send to output window" is actually queued into a string for later appending to the output window. However "send to script (or world etc.)" will be executed right now.
Do any line colouring requested (ie. change triggered line colour).
Queue up the name of the trigger script (if any).
Log the trigger if wanted.
Omit from the first trigger line to end of output buffer (if multiple-lines, eg. soft line breaks).
Append any "send to output window" text saved in the earlier step to the output window in the current note colour.
Execute trigger scripts queued up earlier.