 |
Caled
Sorcerer
Joined: 21 Oct 2000
Posts: 821
Location: Australia
|
 Posted: Thu Jul 12, 2007 3:26 am
[1.34] Duration trig types
|
#AL jobs {#sh %ansi(12) Jobs recently completed:
#showdb @jobsCompleted
#sh %cr
#sh %ansi(12) Jobs to be completed:
#showdb @jobstodo}
#TR {^ Jobs recently completed:$} {}
#COND {%w: (*)$} {#PCOL grey %x1} {duration|param=200}
This colours everything fine, but the duration trigger does not time out. I'll demonstrate with some output:
| Quote: |
Jobs recently completed:
hclearaffs: add function to clear affs of herb type when no result gained form eating.
Jobs to be completed:
mossaffs: Add them to prio-build / change names to idiocy etc
afftrigs: Class by class porting from zmud
venomaffs: venomcuring weapons and syssin. Anti-illusion with fail-safe mode for traps etc
blademsl: port over all blade messages for 'venomaffs' job
salvebal: Create all trigs needed to track salve balances
|
Then, I wait a few seconds to be sure the 200ms duration has gone by, and use:
#say salvebal: Create all trigs needed to track salve balances
directly into the command line, to get the following:
| Quote: |
salvebal: Create all trigs needed to track salve balances
salvebal: Create all trigs needed to track salve balances |
Basically, the trig doesn't go back to #state 0 until it fires once AFTER the duration is up. I think this is a bug, but I couldn't find the help file on trigger types to make sure its not an intended effect. Which might also be a problem, by the way. I am positive it exists as I've viewed it before, but I couldn't find it anywhere :(. Maybe there should be a link to it from the trigger pages in scripting help, and in #TRIGGER from the Command List?
Incidentally.. hehe, like my new project management thingy >_>? |
|
_________________
Athlon 64 3200+
Win XP Pro x64 |
 |
|
|
Thinjon100
Apprentice
Joined: 12 Jul 2004
Posts: 190
Location: Canada
|
Posted: Thu Jul 12, 2007 4:41 am
|
Wouldn't this be much simpler if you simply rebuilt the condition trigger as a normal trigger, with an id... something like:
| Code: |
#TR "trig_colorjobs" {%w: (*)$} {#PCOL grey %x1}
|
Then change your jobs alias to #T- / #T+ the trigger as necessary? Perhaps:
| Code: |
#AL jobs {
#sh %ansi(12) Jobs recently completed:
#T+ "trig_colorjobs"
#showdb @jobsCompleted
#sh %cr
#sh %ansi(12) Jobs to be completed:
#showdb @jobstodo
#T- "trig_colorjobs"
}
|
I'm not sure if you'd need a #WAIT before the last #T- but I doubt it.
As for the root issue of the duration trigger not expiring, I haven't looked into it yet to confirm... just thought I'd offer this workaround. |
|
_________________
If you're ever around Aardwolf, I'm that invisible guy you can never see. Wizi ftw! :) |
|
|
|
Caled
Sorcerer
Joined: 21 Oct 2000
Posts: 821
Location: Australia
|
Posted: Thu Jul 12, 2007 12:28 pm
|
I know there are workarounds; there are almost always several ways to do things. Thanks for the suggestion though.
I found the help file by the way. Its called 'Editing Triggers' and can be found at:
Feature Reference>Package Editor>Editing Triggers.
Also by searching for 'duration' or as a link from the text content of the "Getting started>Scripting>Introduction to triggers" file.
I really think the link should be from every page that talks about triggers, and perhaps as a smaller page, with just information on the trigger types and other options. Buried the way it is, a lot of people will never know they exist. |
|
_________________
Athlon 64 3200+
Win XP Pro x64 |
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Jul 12, 2007 5:41 pm
|
| Quote: |
| Basically, the trig doesn't go back to #state 0 until it fires once AFTER the duration is up. |
Yes, this is one of the limitations of the #COND system. Conditions are only tested when a new line is received from the MUD. The Duration option is not handled like a background timer. It doesn't expire by itself...it only expires when a line is processed. You'll see this if you use a "Wait" condition as well...the condition after the wait doesn't get executed when the wait time expires...it only gets executed when a new line of text is processed after the wait time has expired.
Basically, the #COND system is a state-machine which is tested each time a line of text is received from the MUD. There is no background processing for it. |
|
|
|
|
Zhiroc
Adept
Joined: 04 Feb 2005
Posts: 246
|
Posted: Thu Jul 12, 2007 6:06 pm
|
I can understand that the state is not checked for the duration timeout until a line is received... but can't that check be made before that state tries to match?
|
|
|
|
|
|
|
|
