|
Ashur Novice
Joined: 25 Jul 2011 Posts: 39
|
Posted: Thu Sep 26, 2013 5:34 pm
WAIT Question |
I'm working on the following trigger:
Code: |
#TRIGGER ({no such living*|died.}) {
#IF %match(%1,"died.") {
kill @target
} {
#IF %numitems(@currentkillpath) {
#WAIT 750
#EXEC %pop(currentkillpath);
kill @target
} {
#T- Grinding
}
}
} |
currentkillpath is a 'string list' variable containing one or more directions to move (ie. n;w;se;). I've run into a scenario where I need to WAIT after providing it a command (ie. n;w;se;dig;#WAIT 15000), but the problem is that the trigger does not know how to wait for that. It simply pops the value off the list and then 'kill @target' is executed, which causes the trigger to fire again on 'no such living*'.
WAITFOR seemed promising, but won't work for my case because not all values are going to return text that I can wait on. I need #EXEC to see the command it's executing and wait for that command to finish. It looks like I could accomplish this with WAITSIGNAL, but i would need to add signalling to every value in my string list(s) and handle resetting the signal in the trigger. Not the end of the world, but it seems a little too brute force. Is there a more elegant command/function that I'm not seeing, or is WAITSIGNAL my best bet? |
|
|
|
MattLofton GURU
Joined: 23 Dec 2000 Posts: 4834 Location: USA
|
Posted: Fri Sep 27, 2013 12:26 am |
You're making this trigger handle too much logic, break it down a bit and your problem should go away. Specifically, remove the kill command and make a new trigger that matches on the popped command. This trigger would then be able to evaluate the command to determine if and for how long to wait and could then send the kill command.
|
|
_________________ EDIT: I didn't like my old signature |
|
|
|
Ashur Novice
Joined: 25 Jul 2011 Posts: 39
|
Posted: Fri Sep 27, 2013 2:01 am |
The trigger isn't really handling that much. It handles the two options for a foe being present in the room: If I killed something, try to kill another one, if I killed the last one, move to the next room and kill something.
Additionally, there's nothing for in a popped command that could be triggered on. In some scenarios there might be, but 85-90% of the time, a popped command is something like "#3 n;#4 e;ne;se;e;e;". The rooms that I might land in are all different, so I'm not sure what I would even trigger off of. Now, I could write the second trigger to fire off an #ALARM or something, but I'd still be adding code to my path variables.
Unless, of course, after all that I'm missing your point complete, which I would not put past me. |
|
|
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|