Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD General Discussion
talonnb
Apprentice


Joined: 30 Oct 2004
Posts: 127

PostPosted: 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.
Reply with quote
charneus
Wizard


Joined: 19 Jun 2005
Posts: 1876
Location: California

PostPosted: 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
Reply with quote
talonnb
Apprentice


Joined: 30 Oct 2004
Posts: 127

PostPosted: 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.
Reply with quote
ralgith
Sorcerer


Joined: 13 Jan 2006
Posts: 715

PostPosted: 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
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: 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
Reply with quote
Rahab
Wizard


Joined: 22 Mar 2007
Posts: 2320

PostPosted: 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.
Reply with quote
talonnb
Apprentice


Joined: 30 Oct 2004
Posts: 127

PostPosted: 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
Reply with quote
talonnb
Apprentice


Joined: 30 Oct 2004
Posts: 127

PostPosted: 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?
Reply with quote
Rahab
Wizard


Joined: 22 Mar 2007
Posts: 2320

PostPosted: 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?
Reply with quote
talonnb
Apprentice


Joined: 30 Oct 2004
Posts: 127

PostPosted: 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?
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: 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
Reply with quote
talonnb
Apprentice


Joined: 30 Oct 2004
Posts: 127

PostPosted: 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.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD General Discussion All times are GMT
Page 1 of 1

 
Jump to:  
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

© 2009 Zugg Software. Hosted by Wolfpaw.net