 |
Liath
Novice
Joined: 25 Aug 2009
Posts: 38
|
 Posted: Fri Sep 18, 2009 5:40 am
Multistate Triggers in cMUD
|
Okay, I have this simple test trigger, and it never goes to the second state:
| Code: |
<?xml version="1.0" encoding="ISO-8859-1" ?>
<cmud>
<trigger type="Expression" priority="2160" copy="yes">
<pattern>@HP_cur < %eval(@HP_max*0.30)</pattern>
<value>#noop
#ECHO FIRE!!!!! @HP_cur</value>
<trigger type="Wait" param="10000" newline="false">
<value>#echo Hey what?</value>
</trigger>
</trigger>
</cmud>
|
When I change @HP_cur it fires when it should, but it never enters the second state (the wait). When I do a "#20 {#va @HP_cur %i}" I get 1-20, when it should be stopping for 10 seconds and not firing till the wait state is complete and it rolls back to the first state?
Am I setting up the multistate trigger wrong? |
|
|
|
|
shalimar
GURU
Joined: 04 Aug 2002
Posts: 4690
Location: Pensacola, FL, USA
|
Posted: Fri Sep 18, 2009 12:33 pm
|
it looks good to me... but I would assume you would end up with 20 threads each waiting 10 seconds to fire the next trigger state.
On another note '#WAIT 10000' would work in the main state.
I really see no reason to use states in this example. |
|
_________________
Discord: Shalimarwildcat |
 |
|
|
Liath
Novice
Joined: 25 Aug 2009
Posts: 38
|
Posted: Fri Sep 18, 2009 11:54 pm
|
The reason to use the state is that I dont want the trigger to fire again till after the wait.
I have a temporary workaround... trigger disables itself, sets and alarm that enables the trigger in 5 seconds.
messy but works |
|
|
|
|
Liath
Novice
Joined: 25 Aug 2009
Posts: 38
|
Posted: Sat Sep 19, 2009 8:14 am
|
| shalimar wrote: |
it looks good to me... but I would assume you would end up with 20 threads each waiting 10 seconds to fire the next trigger state.
On another note '#WAIT 10000' would work in the main state.
I really see no reason to use states in this example. |
Erm... **shouldn't** open 20 threads:
| Quote: |
OK, for the second example, what happens when there is no text pattern for the Wait state? Here is the example:
#TRIGGER {Zugg} {#CW high,red}
#COND {} {#BEEP} {Wait|Param=5000}
Well, first we wait for the text "Zugg" from the MUD to arrive. Then the trigger colors the text in bright red, and advances to the Wait part of the trigger. The trigger waits for 5 seconds. When it's done, it notices that the pattern is empty, which causes the trigger to fire immediately, sounding the #BEEP.
Now that the #wait command is working, this sort of solution is of limited use, except that Wait states don't create new threads. They can be used without fear of causing thread-related problems. |
Okay, I'm not getting it.
I thought that multistate triggers went like this:
State1: fires, disables self, enables next state
state2: fires, disables self, enables next state
state3....etc
stateN: fires, disables self, enables State1
So State1 would fire, but wont fire again until the last state in the trigger was reached and fired?
That *is* how it seems to be in the help files...???
| Quote: |
Wait
For the "Wait" trigger type, we will look at two examples. First, an example similar to the last one:
#TRIGGER {Zugg} {#CW high,red}
#COND {Hello} {#CW high,blue} {Wait|Param=5000}
In this case, Param is the number of milliseconds the trigger should wait before starting to match. So the MUD must first send the text "Zugg" to fire the first pattern. Now we are on the second pattern and waiting for 5000 ms, or 5 seconds. Any text received from the MUD during this 5 seconds is ignored. Once the 5 seconds is up, the trigger waits to receive the "Hello" text. When it does, it is colored in bright blue, and we advance to the next trigger state, which wraps back to the first state. |
|
|
|
|
|
Liath
Novice
Joined: 25 Aug 2009
Posts: 38
|
Posted: Tue Sep 22, 2009 5:48 pm
|
So that I can get my head right and be able to use multi-state triggers in the future, can someone clue me in if I'm misunderstanding this, and why the trigger I had doesn't work?
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Sep 22, 2009 6:31 pm
|
Sorry it took me a while to respond to this thread.
I just tried the example in the help file:
| Code: |
#TRIGGER {Zugg} {#CW high,red}
#COND {} {#BEEP} {Wait|Param=5000} |
and it worked perfectly for me here.
Looking at your XML code, why do you have the "newline=false" option? Maybe that is causing the problem.
Also, the problem might be that Expression Triggers were not originally designed to work with multi-state triggers, so this hasn't really been tested. Multi-state triggers are designed to respond to text received from the MUD, like the examples in the help file.
And no, it *won't* create 20 threads. In fact, multi-state triggers do not normally create any new threads at all. The sub-states of a trigger use the thread of the main trigger. |
|
|
|
|
Liath
Novice
Joined: 25 Aug 2009
Posts: 38
|
Posted: Thu Sep 24, 2009 5:43 am
|
Just so I know for the future, since you have all the code there to look at... can ya give a definite yea or nae to the multistate trigger being able to be in a multi-state trigger?
I can already cook up 3 really cool applications for it if it *could* work. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Sep 24, 2009 3:40 pm
|
If you are asking about using a multi-state trigger with an *expression* trigger, I can confirm after additional testing that the Wait state does NOT work with expression triggers. My guess is that other multi-state trigger conditions also do not work with expression triggers.
So only use multiple trigger states when the first initial state is a normal text pattern trigger. |
|
|
|
|
Liath
Novice
Joined: 25 Aug 2009
Posts: 38
|
Posted: Fri Sep 25, 2009 9:17 am
|
Do expression triggers work as the initial state at all?
Durr nvm... i re-read your post and it finally sunk in.
So, use a normal test pattern of some sort, or a trigger with an ID like I showed up a couple posts ago, and perhaps get the trigger to fire off a normal trigger if I just *have* to use an eval as a prime trigger?
ie:
trigger1_name: eval @somevar = somevalue
#echo trigger1_name fired;#t- trigger1_name
trigger2_name: pattern "trigger1_name fired"
do stuff
trigger2_state2: something else
yada; yada
...
...
#t+ trigger1_name
I know its twisted, and all, but *if* i came up with a use for it, it seems feasible. |
|
|
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
