 |
gamma_ray
Magician
Joined: 17 Apr 2005
Posts: 496
|
 Posted: Wed Aug 29, 2007 3:50 pm
[2.01] Variable triggers not updating.
|
| Code: |
<trigger priority="1630" id="163">
<pattern>(@{room.title})</pattern>
<value>#psub {%1 %ansi(white)Exits: @{room.exits}} %x1
#show matches</value>
</trigger> |
If the content of the variable in the pattern (@room.title) changes, the trigger no longer matches, until I open the Compiled Code or Compiled Pattern tab. I assume this forces a recompile, simply sitting with that tab open does not work, I have to switch to some other tab or something and then open that tab.
Yes, I do check that the variable changes and that it actually matches the text I'm getting.
And yes, I did check across a restart this time. |
|
|
|
|
Larkin
Wizard
Joined: 25 Mar 2003
Posts: 1113
Location: USA
|
Posted: Wed Aug 29, 2007 4:32 pm
|
From what I understand of expression triggers, it should evaluate as true or false. What you've got here should only fire if @room.title is changed to 0 (false) and then back to something else non-false. Am I wrong in that assumption? It's been a long time since I used expression triggers (found them unreliable for what I was trying to do).
Edit: Just looking at this XML, I don't see how it's defined as an expression trigger. Is it simply implied by the parentheses around the pattern? |
|
|
|
|
gamma_ray
Magician
Joined: 17 Apr 2005
Posts: 496
|
Posted: Wed Aug 29, 2007 4:43 pm
|
Sorry, this isn't an expression trigger at all, should've been more clear.
Here's another example, one which actually works reliably as it should (this trigger = not broken, first trigger posted = broken):
| Code: |
<trigger priority="81440" id="103">
<pattern>(@tar)</pattern>
<value>#pcol red %x1</value>
</trigger> |
What it does is take my target (whatever is in @tar) and colour it dark red. If I switch my target, it stops colouring the previous target and starts colouring the new one. |
|
|
|
|
Larkin
Wizard
Joined: 25 Mar 2003
Posts: 1113
Location: USA
|
Posted: Wed Aug 29, 2007 7:21 pm
|
Ah. I see now. The term "variable triggers" confused me, I suppose.
These don't look like regex triggers, though, so shouldn't the pattern be ({@tar}) to expand and capture properly? |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Wed Aug 29, 2007 8:29 pm
|
The @{varname} syntax isn't supported within a trigger pattern. It needs to be just @varname.
|
|
|
|
|
gamma_ray
Magician
Joined: 17 Apr 2005
Posts: 496
|
Posted: Thu Aug 30, 2007 6:14 am
|
The pattern @room.name doesn't compile correctly, it looks for the contents of @room plus the string .name. @{room.name} appears to compile correctly, except for when it stops working (when the variable contents change). I'll start using a workaround with a non-db variable and report back about how that works, but I also think it would be great for some kind of fix for simple use of db vars as patterns, because I'm a sucker for db vars.
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Aug 30, 2007 5:39 pm
|
I'll see what I can do. Just keep in mind that the parser for trigger patterns is completely different from the normal CMUD parser. It's a separate parser that tries to convert your trigger pattern into a Perl regular expression. I've added these bugs to the bug list, but I just wanted people to be aware of this difference in parsers.
|
|
|
|
|
|
|
|
