 |
Dwoggurd
Wanderer
Joined: 29 Jan 2008
Posts: 63
|
 Posted: Sat May 02, 2009 3:11 am
Is there a trick to override "stop further processing"?
|
I have a high priority trigger that "stops further processing". In most cases that's what I want, but sometimes I want to let other low priority triggers fire (to process exceptions from a common rule). Is there a way to override "stop further processing" option for a given specific line run-time?
Or, alternatively, is there a way to stop further processing from the inside of a trigger that normally allows other triggers to fire?
I don't want to make exception-triggers higher priority than the main one (for speed purposes), I would rather prefer to control "further processing" dynamically. Any ideas? |
|
|
|
|
wrym
Magician
Joined: 06 Jul 2007
Posts: 349
Location: The big palace, My own lil world
|
Posted: Sat May 02, 2009 3:19 am
|
Hmm not that i'm aware of, You might beable to do that with a lua script, but I think there is a better way.
I'm assuming that several of the lower priorty triggers get enabled and disabled for whatever reason. So you probably could:
1) Put all your scripts for that line into one trigger and check if a certain set needed to be executed
2) Use Custom events and the #raiseevent command, and enable/disable events as needed |
|
_________________
"To the engineer, all matter in the universe can be placed into one of two categories: (1) things that need to be fixed, and (2) things that will need to be fixed after you've had a few minutes to play with them" - Scott Adams, The Dilbert Principle |
 |
|
|
shalimar
GURU
Joined: 04 Aug 2002
Posts: 4692
Location: Pensacola, FL, USA
|
Posted: Sat May 02, 2009 3:26 am
|
would a reparse state accomplish this, or does the 'stop further processing' apply to conditions as well?
|
|
_________________
Discord: Shalimarwildcat |
|
|
|
wrym
Magician
Joined: 06 Jul 2007
Posts: 349
Location: The big palace, My own lil world
|
Posted: Sat May 02, 2009 3:35 am
|
Hmm i'm not too familiar with reparse trigger states, but...
| Code: |
<trigger priority="7450" case="true" stop="true" id="745">
<pattern>^TeStTeSt$</pattern>
<value>#print state 0</value>
<trigger type="ReParse">
<pattern>testtest</pattern>
<value>#print state 1</value>
</trigger>
</trigger>
|
Prints from both trigger states, still you'ld have to do some kinda check in the primary trigger to determine if you want to execute other trigger states, so... i don't really see an advantage over putting it all into the primary trigger |
|
_________________
"To the engineer, all matter in the universe can be placed into one of two categories: (1) things that need to be fixed, and (2) things that will need to be fixed after you've had a few minutes to play with them" - Scott Adams, The Dilbert Principle |
|
|
|
|
|
|
