|
Fergal1982 Wanderer
Joined: 08 Aug 2005 Posts: 70
|
Posted: Tue Aug 16, 2005 2:58 pm
Prioritising Triggers |
Apart from using the alarm command, is there another way to set certain triggers to activate first?
for instance, if you get hit with two status effects (i.e. paralysation, and fatal toxin), if the toxin trigger goes off first, then it wont work since you are paralysed: you would need to cure the paralysation before the toxin would work.
the only way i can think of doing it is to delay (with #alarm) the less critical triggers by a second or two and put no delay on the more critical triggers, but i was wondering if there was a priority system in zmud???
Fergal |
|
|
|
geosmith Wanderer
Joined: 23 Apr 2005 Posts: 57
|
Posted: Tue Aug 16, 2005 4:54 pm |
Hmm, this might work. I'm no expert though, so I'd welcome some feedback from one of the more experienced forum users.
#V paralysis 0
#V fataltoxin 0
#TRIG {your paralysis message} {#V paralysis 1}
#TRIG {your fataltoxin message} {#V fataltoxin 1}
#TRIG {your paralysis-cured message} {#V paralysis 0}
#TRIG {your fataltoxin-cured message} {#V fataltoxin 0}
#TRIG ((@paralysis=1)) {#IF (@fataltoxin=0) {however you cure paralysis}}
#TRIG ((@fataltoxin=1)) {#IF (@paralysis=1) {however you cure paralysis} {however you cure the fataltoxin}}
Let me know if it works? |
|
|
|
Vijilante SubAdmin
Joined: 18 Nov 2001 Posts: 5182
|
Posted: Tue Aug 16, 2005 8:54 pm |
If you set the view in the Settings Editor you can move triggers up and down to affect the priority of them. While this is supposed to work beyond classes, using a view for all classes I don't really like that method. My programming experience causes me to think of classes a grouping, and if a trigger requires a much higher priority then those in the rest of the class then it likely doesn't belong in that class.
Another method of doing this is to create your own priority queue system. This is generally done by having the triggers receieve data about events and set variables accordingly. Then a single prompt trigger preforms all valid actions at that time. This can casue the logic for your prompt trigger to be very complex, but once done it actually becomes quite easy to maintain and provides the best method for controlling all aspects of your character by script. This how I generally design full automation bots, the biggest advantage being that you really are not able to take action until after being prompted. While network delays often hide actions sent before the prompt, from the mud, it makes logs harder to read. |
|
_________________ The only good questions are the ones we have never answered before.
Search the Forums |
|
|
|
|
|