Zugg Software :: View topic - Spell Re-attack Trigger Problem

Beginner Joined: 08 Jun 2004 Posts: 10

Hi All, I have a script which re-casts a spell based on the MUD message saying i hit the mob. The problem I am having is the spells which can hit 2-4 times (on 1 cast), and i get the 'trigger' message that many times!! So I end up casting 2-4 times per round when I really want to cast just once. Here is what it looks like:

Eventide attacks the Milestone Statue.
Hp:797 Mo:255 Ma:478 Sec:67 [Good] [ne] AC:[-9] Dr:[10] Hr:[4]>
mana = 478 and lastspell=fr
ca 'fists of rock' statue
kill statue
The Milestone Statue is here, fighting Eventide.
Ok.
Your fists of rock hit the Milestone Statue hard.
Your fists of rock hit the Milestone Statue hard.
Your fists of rock hit the Milestone Statue hard.
Your fists of rock hit the Milestone Statue hard.
Silverwind attacks the Milestone Statue.
Erin assists Eventide.
Keano attacks the Milestone Statue.
Thingol assists Eventide.
Hp:797 Mo:255 Ma:430 Sec:67 [Good] [ne] AC:[-9] Dr:[10] Hr:[4]>
Fighting: [the Milestone Statue/Small wounds]>
mana = 478 and lastspell=fr
mana = 478 and lastspell=fr
mana = 478 and lastspell=fr
mana = 478 and lastspell=fr
mana = 430 and lastspell=fr
ca 'fists of rock'
ca 'fists of rock'
ca 'fists of rock'
ca 'fists of rock'
ca 'fists of rock'

The main problem here is that the cast attempts stack up and I am still casting when the mob is dead. And very bad when the group is ordered to recall!!
Any suggestions on how to fix this?
Thank you,
Mario

Wanderer Joined: 31 May 2004 Posts: 54 Location: USA

Ok first of all, put this in a Class Folder (ReCast, for example) and put all your triggers that relate to it.
Then, for the very FIRST line of your VALUE box, put #T- ReCast (Or whatever you name it) and put #T+ ReCast for the LAST line.

!EXAMPLE!
Expression: ^Your fists of rock hit the %1 hard.
Value: #T- ReCast;cast @lastspell;#T+ ReCast

Doing this will instantly disable your trigger that activates the Re-Cast but will not stop the normal flow, preventing you from casting 3 extra times than you wanted.

~Zener

Wizard Joined: 15 Jan 2002 Posts: 1644 Location: USA

That is not really what you want and will not work

It can be handled easily handled with a class put all your recast spells in the class reCast and at the bottom of every trigger put this #T- reCast

Then make PROMPT trigger
#TR {Hp:%d Mo:%d} {#T+ reCast} {prompt|nocr}

So since most muds you will get a prompt between seperate castings this does ONE recast then disables the class asn soon as the prompt comes its reanabled and the spell is recast in the second round repeating. I hope this made sense cause I am uber tired.

now what this does is TURNS off recasting until

Wanderer Joined: 31 May 2004 Posts: 54 Location: USA

I am pretty sure the way I explain would work as I said it would Nexela.

I have a trigger that will greet a person upon entering my room, but I do not want my trigger to greet EVERY single person, and therefore I used my method above to prevent the trigger from spamming myself and everyone else if a group of people came rushing through.

Here is the trigger I use, and how it executes.

#TRIGGER {^(%w) {arrives|flies in|floats in} from {the west|the southeast}} {#VAR PC %1
:Character2: #VAR PC %1
:Character3: #VAR PC %1
#CASE %random {:Name:sayto @PC Message} {#NOOP} {:Name:sayto @PC Message} {:Name:save} {:Name:save} {#NOOP} {:Name:save} {:Name:sayto @PC Message} {:Name:sayto @PC Message} {#NOOP}
#WAIT <Time>
#T+ ClassFolder
}

This is what I see when a group comes into my room.

Player1 flies in from the southeast.
Player2 floats in from the southeast.
Player3 flies in from the southeast.
Player4 floats in from the southeast.
Player5 flies in from the southeast.
Player6 arrives from the southeast.

Of course my trigger activates on Player1 flies in from the southeast.

This is what I see when I have my ECHO TRIGGERS, ECHO SCRIPTS, ECHO MESSAGES on.

Player1 flies in from the southeast.
[^(%w) {arrives|flies in|floats in} from {the west|the southeast}-> #T- FolderName
#VAR PC Player
:Character2: #VAR PC Player1
:Character3: #VAR PC Player1
#CASE %random {:Name:sayto @PC Message} {#NOOP} {:Name:sayto @PC Message} {:Name:save} {:Name:save} {#NOOP} {:Name:save} {:Name:sayto @PC Message} {:Name:sayto @PC Message} {#NOOP}
#WAIT <Time>
#T+ ClassFolder]
Player2 floats in from the southeast.
Player3 flies in from the southeast.
Player4 floats in from the southeast.
Player5 flies in from the southeast.
Player6 arrives from the southeast.

The above is as close to what Nastasim was describing as you can get. Like Nastasim, I wanted my trigger to only activate 1 time. But in my case, I wanted spam protection so I put a #WAIT in there. Nastasim was describing, if I read his post correctly, exactly opposite of what you were explaining. When he casts Fist of Rocks, he receives 4 messages ALL AT ONCE. And unless I am mistaken, you were thinking something like this.

ca 'fists of rock' statue
kill statue
The Milestone Statue is here, fighting Eventide.
Ok.
Your fists of rock hit the Milestone Statue hard.
PROMPT: Hp:797 Mo:255 Ma:430 Sec:67 [Good] [ne] AC:[-9] Dr:[10] Hr:[4]>
Your fists of rock hit the Milestone Statue hard.
PROMPT: Hp:797 Mo:255 Ma:430 Sec:67 [Good] [ne] AC:[-9] Dr:[10] Hr:[4]>
Your fists of rock hit the Milestone Statue hard.
PROMPT: Hp:797 Mo:255 Ma:430 Sec:67 [Good] [ne] AC:[-9] Dr:[10] Hr:[4]>
Your fists of rock hit the Milestone Statue hard.
PROMPT: Hp:797 Mo:255 Ma:430 Sec:67 [Good] [ne] AC:[-9] Dr:[10] Hr:[4]>

Which is much different from this.

ca 'fists of rock' statue
kill statue
The Milestone Statue is here, fighting Eventide.
Ok.
Your fists of rock hit the Milestone Statue hard.
Your fists of rock hit the Milestone Statue hard.
Your fists of rock hit the Milestone Statue hard.
Your fists of rock hit the Milestone Statue hard.
PROMPT: Hp:797 Mo:255 Ma:430 Sec:67 [Good] [ne] AC:[-9] Dr:[10] Hr:[4]>

BUT of course I could be wrong its 4am and I need to get to sleep. I can't believe I bothered to type this out being this tired...heh.

~Zener

Beginner Joined: 08 Jun 2004 Posts: 26 Location: USA

hmm personally i would just think to try a multi state trigger

first state recognizes "Your fists of rock hit the Milestone Statue hard." abd recasts and instantly sets the trigger to state 2
and state two just waits x ammount of time. and then sets the trigger back to state 1 (which is actually #SET triggername 0 or #SET triggername 1 (for state 1 or 2 respectively)

Id give you the nice copy n paste into the command line thing, here, but just check out the help files. look up advanced triggers, trigger states, and the wait command in zMud help. You'll learn alot more that way. :) have fun, but personally i think that would be the most simple way. sometimes things can get messy disabling things. it has its place. but ive had it happen to me where it says something is enabled, and it really wasnt.

MASTER Joined: 28 Nov 2000 Posts: 4817 Location: USA

That's not your trigger, Zener, it's mine. I wrote it for you only yesterday and you've made only one significant modification -- the use of #WAIT rather than a Wait multistate -- which made the trigger worse not better. Don't use #WAIT in triggers. There's a reason I used #CONDITION in the original version of that trigger which I wrote for you yesterday even if you don't understand it.

Nexela's approach (re-enabling on the prompt) is better for this problem than a timed delay. My approach (using #CONDITION to provide a timed delay) is better for the problem from yesterday.

Beginner Joined: 08 Jun 2004 Posts: 26 Location: USA

thanks for the clarification lightbulb. i didnt want to be upsetting someone two days into the forum for me. then again i didnt think i took credit for something... so yeah, maybe im more tired then i thought.. hey do you have any new ideas on my trig,, the search and replace one?

Wanderer Joined: 31 May 2004 Posts: 54 Location: USA

quote:
Originally posted by LightBulb

That's not your trigger, Zener, it's mine. I wrote it for you only yesterday and you've made only one significant modification -- the use of #WAIT rather than a Wait multistate -- which made the trigger worse not better. Don't use #WAIT in triggers. There's a reason I used #CONDITION in the original version of that trigger which I wrote for you yesterday even if you don't understand it.

Nexela's approach (re-enabling on the prompt) is better for this problem than a timed delay. My approach (using #CONDITION to provide a timed delay) is better for the problem from yesterday.

First of all, if you're going to take it personally about me stating that it is my trigger, I am not sure I am really sorry since it's just a trigger, which has no value, monetary or otherwise.

Also, Never did I state that Nastasim had to use a #WAIT in his, I was the trigger I posted as an EXAMPLE alone.

I make use of #T+ and #T- often because it works for me and you know what? I have had NO problems with such and such triggers being disabled when it wasn't supposed to be, and vice versa. So, please, don't go around telling people not to use it, because it works fine for me and it might for others. Instead, if you see something that can be made better, suggest the change and maybe also explain what the change does in the process, rather than just saying, don't use that, without plausible reasons why.

Anyways, enough of this, I am still wondering why I bothered to type this out, and whoever reads it might also wonder. Good thing is, I can type it out if I feel so inclinded to do so, which I did.

~Zener

ps. Anyone care to explain how #CONDITION {} {} {Wait Praram=time} works? :)

Wizard Joined: 15 Jan 2002 Posts: 1644 Location: USA

Xphere Lightbulbs quote was not directed to you but to Zener there is a perfectly good reason why not to use #WAIT in triggers and in your case Using it could get you killed on your mud :P Its explaind a little below and even more in the support file I mention.

quote:
So, please, don't go around telling people not to use it, because it works fine for me and it might for others. Instead, if you see something that can be made better, suggest the change and maybe also explain what the change does in the process, rather than just saying, don't use that, without plausible reasons why.

In My sig line there is a link to Understanding alarms and #WAIT Please read this. When the CREATOR of a program says NOT to use something in triggers its generally a good idea not to use it and he explains it well.

#TR {Trigger on This.} {#SAY TRIGGERED}
#CONDITION {} {} {Wait|Param=3000}

The first line is the trigger Whenever the text Trigger on This. comes across the screen it fires.
then the Condition simply tells it to NOT fire again for 3 seconds no matter how often Trigger on This. comes across the screen (I think the param is milliseconds its explained in the help files). But if you read the Understand alarms and #wait file this is explained.

Wanderer Joined: 31 May 2004 Posts: 54 Location: USA

quote:
there is a perfectly good reason why not to use #WAIT in triggers and in your case Using it could get you killed on your mud :P Its explaind a little below and even more in the support file I mention.

Killed as in, gotta go get my corpse back? If so, there is no chance for that as far as my situation goes. The reason is, the characters I do use, to run, level, gold and such. I use as few triggers, aliases, macros, and buttons as possible, it makes playing boring if a person runs off of them more than anything. Though some have good uses, such as a script I use to keep track of what I have killed, and another to keep track of tells in a smaller window, which these in no way make playing easier. Very Happy

(None of my characters I "play" use #WAIT)

quote:
#TR {Trigger on This.} {#SAY TRIGGERED}
#CONDITION {} {} {Wait|Param=3000}

The first line is the trigger Whenever the text Trigger on This. comes across the screen it fires.
then the Condition simply tells it to NOT fire again for 3 seconds no matter how often Trigger on This. comes across the screen (I think the param is milliseconds its explained in the help files). But if you read the Understand alarms and #wait file this is explained

Nexela, many thanks, I never understood #CONDITION {} {} {Wait|Param=Time) and how it works. But the way you simply explained it made it totally clear.

Beginner Joined: 08 Jun 2004 Posts: 10

I set up nexala's solution and just have to wait to test it out (the MUD is slow!). I have a question on the trigger:
#TR {Hp:%d Mo:%d} {#T+ reCast} {prompt|nocr}

when I entered this into the command line, it created a directory called prompt and a subdirectory called nocr (this is where the trigger ended up). Is that what nexela meant to happen? Or does the {prompt|nocr} part mean something else?

Thanks for all the replies on this!!
Mario

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Nexela meant something else. The correct trigger would be:
#TR {Hp:%d Mo:%d} {#T+ reCast} "" {prompt|nocr}

Hopefully everyone is done hijacking this topic, and is does not continue down the path of flaming that was started...hint, hint.

Beginner Joined: 08 Jun 2004 Posts: 10

"Nexela meant something else. The correct trigger would be:
#TR {Hp:%d Mo:%d} {#T+ reCast} "" {prompt|nocr}"

Then what does the "" {prompt|nocr}" do?

Mario

Enchanter Joined: 10 Oct 2000 Posts: 698

Syntax: #TR [id] pattern command [classname] [options]

classname = ""
"" is just a place holder for 'no class name given'. This trigger will be created in the current class.

options = {prompt|nocr}
prompt trigger fires on a prompt
nocr trigger does not fire on newline