|
gmueller Apprentice
Joined: 06 Apr 2004 Posts: 173
|
Posted: Wed Apr 18, 2007 8:41 pm
auto deleting update trigger |
ok, so I've had the same combat reflexes for like 4 years now, and have been adding more and more triggers to it as it gets older... and now it's really big, but I dont want to just delete triggs that might be useful.
Here's the idea: I want to add a #COND to every trigger that will always fire and say #ECHO this trigger should still be in the system
#TRIGGER {^Sticky strands of webbing come out from %w and cover you all up.$} {entangled_set}
#COND {*} {#ECHO this trigger should still be in the system.}
Here's the problem with this.... There are tons of triggers, so I'd have to manually delete all these cond statements as they were seen.
Is there a way to have the #COND statement delete itself after it fires once?
#TRIGGER {^Sticky strands of webbing come out from %w and cover you all up.$} {entangled_set}
#AUTODELETINGCOND {#ECHO this trigger fired, yay, no need to delete this one because it's still in the updated system.}
Perhaps there is a way?? If there is a different suggestion I'd be open to hearing it. |
|
|
|
gmueller Apprentice
Joined: 06 Apr 2004 Posts: 173
|
Posted: Wed Apr 18, 2007 9:21 pm |
What techniques have people tried to remove the fluff (acurately) of an old system?
|
|
|
|
gmueller Apprentice
Joined: 06 Apr 2004 Posts: 173
|
Posted: Wed Apr 18, 2007 10:01 pm |
oh yes, and the goal of this... after about a month or so, I'd look thru the system and remove the triggers that still had a #cond. i.e. A systematic way of identifying which triggers are still useful.
|
|
|
|
Fang Xianfu GURU
Joined: 26 Jan 2004 Posts: 5155 Location: United Kingdom
|
Posted: Wed Apr 18, 2007 10:06 pm |
Normally by the time a system's got to the point where it needs that amount of cleaning up, I've learnt three or four ways to do the actual processing better as well and prefer just to scrap the whole thing and import triggers one by one, manually, to use the new system. If it's got into that state in the first place it usually means that your trigger library is badly organised and needs a proper class structure, something else that a script can't do for you. Once you've got your triggers sorted into very specific classes it's easy to spot duplicates and to go through your triggers systematically checking them. It's easy to create a trigger (or any other setting) and think "I'll file it later" and then never bother - a proper structure like this makes it very easy just to drag and drop it into the right place.
Unfortunately, there's no #uncond command like there's an #untrig command to do this kind of deletion from within a script. |
|
|
|
Tech GURU
Joined: 18 Oct 2000 Posts: 2733 Location: Atlanta, USA
|
Posted: Wed Apr 18, 2007 10:24 pm |
I don't think there is any command to remove just a condition from a trigger.
I've manually gone through and edited them myself, but I don't use too many trigger for actions I didn't initate so that may not be feasible for you.
I'm coming up with some ideas but I'm confused about a few things? How are you going to add a condition to these triggers? How does it benefit you if you can remove the condition automatically? How will you determine a trigger you don't use from a trigger that's used but not very often?
One idea that's a bit of kludge is to have each trigger add it's priority to a list, and after a while everything in the trigger is something you know you use.
Another 'bolder' approach is to have each trigger have a condition that deletes itself, and uses #ALARM to recreate itself. In other words the #ALARM would issue the #TRIGGER command as if you were doing it from the command line. Needless to say I would reccomend a backup (or two for that matter) before you try this. |
|
_________________ Asati di tempari! |
|
|
|
gmueller Apprentice
Joined: 06 Apr 2004 Posts: 173
|
Posted: Wed Apr 18, 2007 11:23 pm |
I actually thought about having the cond recreate the original trigger using #TRIGGER, or #REGEX, and then untriggering the original using #UNTRIGGER, but that forces me to create a lot of custom code. If it's possible I'd like to minimize the human error aspect of this.
EX:
#TRIGGER {%w tells you,} {do something here...}
#COND {#ECHO trigger update;#TRIGGER {%w tells you,} {do something here...};#UNTRIGGER}
hmm this actually might not be toooooooooo bad. Still though, if anyone has suggestions that'd be great.
Also Tech, as to deciding if the triggers are old, that wouldn't happen till later. I'm guessing after some serious FFA's or sparring happened.
Maybe about a months worth of these trigger updates?, More time in the case that it's a rare trigger, like fighting mean nasty dragons on remote islands. |
|
|
|
gmueller Apprentice
Joined: 06 Apr 2004 Posts: 173
|
Posted: Wed Apr 18, 2007 11:28 pm |
Thanks Fang, You're right that it could be better organized. Things almost always can be ^^. You're right that there are a lot of things that I've learned along the way, but I usually write script to the top of my abilities and then worry about backwards compatability as it fails. At any rate, I guess I'd like to make this thread very specific.
the purpose being, how to automate a cleanup of a current very large system. |
|
|
|
|
|