|
talonnb Apprentice
Joined: 30 Oct 2004 Posts: 127
|
Posted: Sat Jun 12, 2010 4:44 am
Problem with multistate triggers |
I wish to trigger a set of lines, but it's turning out to be more complicated then I wanted so I need some advice.
Example of the triggers
Lycian slashes into you with an ornate steel rapier.
Your mind feels suddenly slow and dull.
Lycian slashes into you with an ornate steel rapier.
You feel your limbs seeze up.
These aren't actual triggers, but they illustrate what the 'optimum' thing would be. I would create a trigger off the slash line, then just do a 'within' 1 line and capture the full line. I then compare it to a string database and it gets me a value. Now, this works this way. Here comes the headache.
So, there are other things that can show up between the lines I have shown you above.
Lycian slashes into you with an ornate steel rapier.
The illumination aura discharges and returns health to you.<-------------annoying line, not to be trigged.
You dodge the attack slightly, lessening the blow.<-------------annoying line, not to be trigged.
Your mind feels suddenly slow and dull.
Lycian slashes into you with an ornate steel rapier.
You dodge the attack completely. <-------------annoying line, not to be trigged.
You feel your limbs seeze up.
So these things show up randomly, so I made 3 withinline trigs, one for 1,2,3 lines away from the trig BUT if it was only like the first example, the second slash message does not fire since the withinline gets it and screws up the entire capture. Is there an easier way to do this? My brain hurts too much to think creatively tonight, so any input would be great. |
|
|
|
charneus Wizard
Joined: 19 Jun 2005 Posts: 1876 Location: California
|
Posted: Sat Jun 12, 2010 5:31 am |
Easiest way is to trigger off the string database/list that you have.
#TRIGGER {whatever the slash line is}
#COND {{@stringdatabase}} {value} (change it to param Within 3, if it'll always show up within the next three lines. Otherwise, we will have to do something different.)
That way, you don't need to check to see if it's an existing key, as it won't trigger on anything BUT something in that string database.
Charneus |
|
|
|
talonnb Apprentice
Joined: 30 Oct 2004 Posts: 127
|
Posted: Sun Jun 13, 2010 3:58 am |
Problem is my trigger database is database record, not a stringlist. I have it set up so I just do
#var AfflictionResetVar %db( @SecondaryAfflictTrigs, @AfflictLine)
Where AfflictLine is captured with a ^(&AfflictLine)$ as the trigger line in the within line.
Any further ideas? I think I might have one, but testing is required so any further ideas will be appreciated. |
|
|
|
ralgith Sorcerer
Joined: 13 Jan 2006 Posts: 715
|
Posted: Sun Jun 13, 2010 1:36 pm |
Sure, listen to Charn and just MAKE a stringlist of the annoying lines. His way really is best.
|
|
_________________ CrossOver: Windows Compatibility on Mac and Linux CMUD Advocate |
|
|
|
MattLofton GURU
Joined: 23 Dec 2000 Posts: 4834 Location: USA
|
Posted: Sun Jun 13, 2010 5:37 pm |
His first post prevents the use of a Within 3 condition. He might get two slashes in, and if the first slash has less than 3 lines then the condition will either pick up the second slash's affect or will cause the second slash to not get matched and therefore the second affect doesn't get captured.
He may be better off using a manual state for the condition, and then using #switch and #call %match to determine what to do with each line. |
|
_________________ EDIT: I didn't like my old signature |
|
|
|
Rahab Wizard
Joined: 22 Mar 2007 Posts: 2320
|
Posted: Mon Jun 14, 2010 5:32 pm |
By the way, it doesn't matter whether the variable is a stringlist or a database variable. Using {@mydbvariable} within a trigger pattern will use the keys of the variable as if it were a stringlist. A very useful capability.
|
|
|
|
talonnb Apprentice
Joined: 30 Oct 2004 Posts: 127
|
Posted: Tue Jun 15, 2010 11:17 pm |
So I found a way to do it, cause I was bored and looked up the #STATE command.
Basically now, I have a trigger for
^(%w) {slashes into|smashes} (*) with (*)!$ --->name is Slashed and #vars TriggerType Slashed
within 1: ^(&AfflictLine)$ --> This does #call @HandleAfflictLine()
Function HandleAfflictLine has this code at the start
#var SecondaryAfflictVar 0
#if (%match( @AfflictLine, "H:(%d) M:(%d) E:(%d) W:(%d) B:(%d~%) Spark:(%d~%) Stance:(%w) XP:(%d~%) ~[(*)~]")) {
#echo [TAS]: System didn't get an afflict! Maybe hidden or they are a moron! DIAG anyhow!
#STATE @TriggerType 1
#var SecondaryAfflictVar 9999
}
#var SecondaryAfflictVar %db( @SecondaryAfflictTrigs, @AfflictLine)
#if (@SecondaryAfflictVar != 0) {#STATE @TriggerType 0} {#STATE @Triggertype 1}
This works wonderfully from what I've tested. Cheers for anyone who needed this info |
|
|
|
talonnb Apprentice
Joined: 30 Oct 2004 Posts: 127
|
Posted: Sat Jun 19, 2010 3:05 am |
Problem with the #STATE command. For some reason #State @TriggerType 0 when @triggertype = scythe does not change the 'scythe' trigger back to its original trigger, it just keeps firing off state 1 instead.... Any ideas or is this a bug?
|
|
|
|
Rahab Wizard
Joined: 22 Mar 2007 Posts: 2320
|
Posted: Sat Jun 19, 2010 1:55 pm |
I'm not sure that #STATE will expand a variable into a trigger name. Is there a reason you can't use the actual trigger name instead of a variable?
|
|
|
|
talonnb Apprentice
Joined: 30 Oct 2004 Posts: 127
|
Posted: Sat Jun 19, 2010 4:16 pm |
Only real reason I don't want to use the specific name is because I wanted to make all of my multistate trigs to be able to be controlled through a single function.
So Trigger one fires, sets TriggerType to the id of the trigger, goes through subbing the line, then does a wildcard capture on the next line assigning the line to AfflictLine. It then calls @HandleAfflictLine() function which does the check to see if it's in my affliction database record and reset the current trigger based on that. If it's a member, it knows the trigger got an affliction and resets it's state to 0, if not, it resets the trig to state 1 and captures another line. Rinse and repeat till the affliction line or prompt is caught.
Problem is, some triggers reset properly, some don't.
Code is like this:
Trigger
-Sub
-#var TriggerType whatever
Multistate ^(&AfflictLine)$
-#call @HandleAfflictLine
HandleAfflictLine
- #Var afflictlinevariable %Match(blah, blah)
- #If (@Afflictlinevariable = "") {#state @TriggerType 1} {#state TriggerType 0}
Basically the above line says, "Ok, if I don't find this afflict line in my database the state will go back to 1 and fire again (which works) but if I get a trigger line within the database it sets the trigger to state 0 which will fire the original pattern instead of the wildcard capture (which doesn't currently work, it keeps firing the wildcard)."
Now, since I'm not at home, my question would be, if I just put this:
- #If (@Afflictlinevariable = "") {#state @TriggerType 1}
would the pattern reset itself on it's own, rather than me having to put it to state 0? |
|
|
|
MattLofton GURU
Joined: 23 Dec 2000 Posts: 4834 Location: USA
|
Posted: Sat Jun 19, 2010 4:25 pm |
Manual state = does not get reset until you use #STATE command
everything else = automatically reset by CMud after the state finishes firing
Basically, you should only be using #STATE to move out of a manual state. Using it on Patterns, Loop Lines, and other text-matching types generally indicates you are doing something really wrong and that there's a much better way. |
|
_________________ EDIT: I didn't like my old signature |
|
|
|
talonnb Apprentice
Joined: 30 Oct 2004 Posts: 127
|
Posted: Sat Jun 19, 2010 4:38 pm |
Well see, my reason for using states is because the affliction line I want is a random distance from the initial trigger (1-3 lines, example indicated at start of initial post). State has actually proved useful to basically just make it capture the next line in the system until it captures the affliction, but I think I will get rid of the #state 0 part as it will probably allow the trigger to reset the within line on it's own.
This way, I only have to have 'one' within 1 line and it is only asked to fire the next line if it doesn't find an afflict line. |
|
|
|
|
|