|
kinnoinen Beginner
Joined: 30 Jan 2005 Posts: 26
|
Posted: Fri Dec 26, 2008 9:21 pm
[2.37] %1 in alarm trigger |
Simply enough, if you have a trigger:
#TRIGGER {%x tells you 'enter (%x)'} {#alarm +1 {enter %1}}
it doesn't work. It doesn't expand the %1 before making the alarm. Using local variables works tho, but it's an extra line. :) |
|
|
|
Fang Xianfu GURU
Joined: 26 Jan 2004 Posts: 5155 Location: United Kingdom
|
Posted: Fri Dec 26, 2008 9:36 pm |
Not a bug. If you want to do this sort of thing in CMUD, you need to use local variables. If you want to avoid the extra line, you could use ($localvar:%x) instead of just (%x).
|
|
|
|
Arde Enchanter
Joined: 09 Sep 2007 Posts: 605
|
Posted: Sat Dec 27, 2008 8:34 am |
Fang Xianfu wrote: |
Not a bug. |
Why? |
|
|
|
Fang Xianfu GURU
Joined: 26 Jan 2004 Posts: 5155 Location: United Kingdom
|
Posted: Sat Dec 27, 2008 2:31 pm |
Because you're using %1 in an alarm, and alarms are actually a kind of trigger. If you use %1-%99 inside a kind of setting you're defining, it'll refer to the %1-%99 of that setting. For example:
#alias test {#alias %1 {do %1}}
So test cheese will result in an alias cheese whose script is do %1. This is the only way to get this behaviour now that the %%1-%%99 syntax has been removed, so when you use it, CMUD thinks you're using it deliberately to delay expansion like this.
If you want to get the old behaviour, where all %1s were expanded with the original value of %1, you need to use a local variable, like:
#alias test($localvar) {#alias $localvar {do $localvar}}
So test cheese will give you an alias cheese whose script is do cheese.
Basically, it's not a bug because if it was changed back to the way it used to be, there'd be no way to get the first behaviour. The only weird bit is that alarms are actually a kind of trigger. |
|
|
|
|
|