 |
GeneralStonewall
Magician
Joined: 02 Feb 2004
Posts: 364
Location: USA
|
 Posted: Mon Apr 06, 2009 9:41 pm
[3.05] #state bug
|
It appears that #state does not work without an ID. In the following case the #state command fails to do anything:
| Code: |
<?xml version="1.0" encoding="ISO-8859-1" ?>
<cmud>
<alias name="test">
<value>#say Begin Testing!</value>
</alias>
<trigger priority="21990">
<pattern>Begin Testing!</pattern>
<value>#say State 0 fired!</value>
<trigger>
<pattern>State 0 fired!</pattern>
<value>#say State 1 fired!
#state 0</value>
</trigger>
<trigger>
<pattern>State 1 fired!</pattern>
<value>#say State 2 fired!</value>
</trigger>
</trigger>
</cmud> |
Also, if you use the #alarm command and then proceed it with #state 0, the alarm is immediately disabled. The only way to get around this is to give the trigger an ID which can be cumbersome when dealing with a large group of triggers. |
|
Last edited by GeneralStonewall on Mon Apr 06, 2009 10:48 pm; edited 1 time in total |
 |
|
|
wrym
Magician
Joined: 06 Jul 2007
Posts: 349
Location: The big palace, My own lil world
|
|
|
|
|
GeneralStonewall
Magician
Joined: 02 Feb 2004
Posts: 364
Location: USA
|
Posted: Mon Apr 06, 2009 10:46 pm
|
I had posted it on the general cmud forums but realized this was the more appropriate forum. Yes though, it appears that this is also an issue with zmud. |
|
|
|
|
ReedN
Wizard
Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon
|
Posted: Tue Apr 07, 2009 2:18 pm
|
How odd that I was just looking at this yesterday as well. The documentation for #state shows an example of its use without an id and I was playing around with that yesterday. It should either work as it shows in the example in the documentation, or the documentation should be changed to correct the impression it can be used without an id present.
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Apr 07, 2009 5:09 pm
|
I'll add this to the CMUD bug list. The #state command is supposed to work without an id.
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Fri Apr 17, 2009 9:10 pm
|
Well, the old bug post is fixed now. ( http://forums.zuggsoft.com/forums/viewtopic.php?t=27449&highlight=%23state )
However, in the first post in this thread, I think people are a bit confused about the execution order of triggers and states. As soon as the state of a trigger matches, the trigger is set to the next state. So in the state above where you do:
#say State 1 fired!
#state 0
the trigger state is already set to the next state, so the #say command immediate matches the pattern. So the trigger displays "State 2 fired!" in response to the #say command BEFORE the "#state 0" command is executed.
So, the actual order in which the commands are executed in this example are:
#say Begin Testing!
#say State 0 fired!
#say State 1 fired!
#say State 2 fired!
#state 0
which is working fine now in v3.06. Just already remember that displaying text to the screen via #SAY (or #SHOW, etc) causes any matching trigger to be executed immediately, interrupting the current script flow. And multi-state triggers are advanced to their next state immediately when a match of the current state is detected. So when a state is running it's script, the trigger is actually set to the NEXT state already, waiting for matching text. |
|
|
|
|
|
|
|
