Zugg Software :: View topic

Novice Joined: 26 Apr 2007 Posts: 44

Here's my trigger:

^Holding (&currentWeapon) poised at an angle overhead, (&preAttacker) unleashes

#VAR currentModifier 0
#t+ InnerKnighthood
addCloseClass InnerKnighthood
warriorAttack

InnerKnighthood contains the other half of the same line this trigger would respond to. The full line I want to get working is:

Holding a finely serrated greatsword poised at an angle overhead, Anisu unleashes a violent assault at your right arm. You are struck in your right bicep and blood freely flows down your arm.

The trigger "your (%w) bicep and blood freely" is found in the InnerKnighthood class, which is always closed unless opened by this type of trigger. All of the other similar triggers work, but this is the latest one created. Is this a priority issue? Do I need to recreate the inner triggers so it will match correctly?

Edit: This ^Holding trigger is definitely firing. I tested it by putting a #SAY in there. However, it does a #SAY after the full line rather than the word "unleashes".

Posted: Sun Jul 29, 2007 7:30 pm

This is a pretty strange way of solving this problem. Personally, I wouldn't play a MUD that didn't let me turn off server-side word wrapping and avoid this problem altogether, but that's just me :P Turning off word wrapping also solves problems where someone with a really long name or a really long weapon name pushes the word "unleashes" onto the next line.

That said, this is an ideal place to use multistate triggers:

#trig {^Holding (&currentWeapon) poised at an angle overhead, (&preAttacker) unleashes} {}
#cond {your (%w) bicep and blood freely} {} {within|param=2}

This one uses the within setting to make sure the second line comes within two lines of the first. You can adjust that how you like.

If you'd rather get it working with the way you're doing things now, you're going to need to explain what exactly isn't working. Is the class not being enabled, or is it being enabled, but the triggers aren't firing? Is it not being disabled properly afterwards?

Novice Joined: 26 Apr 2007 Posts: 44

It's wrapwidth 250, so I usually don't run into linebreak issues. There are about 30 things that could follow, so it's easiest to use a separate class since multiple things can have the same second parts.

This is what happens when I add a say to the Holding trigger:

Holding a finely serrated greatsword poised at an angle overhead, Anisu unleashes a violent assault at your left arm. You are struck in your left bicep and blood freely flows down your arm.
****FIRST TRIGGER FIRING***
5116h, 6400m, 5500e, 10p, 27900en, 30900w esSilrxk<>-|FREE|On!|HP: -684|*

It should activate the inner class once it matches the pattern. The inner class contains patterns found in the second part of the line. It's being disabled just fine with my addCloseClass alias, which automatically disables temporarily opened classes on the prompt line. I tested this again with the inner class open - it worked fine, so the trigger patterns themselves seem to be right. The problem is that it seems to be opening the class after it needs to.

EDIT: What it looks like for it to properly fire...

Holding a dull iron katana poised at an angle overhead, Anisu unleashes a violent assault at your head. Anisu strikes your neck, and blood fountains out in a thick spray.
adding pre wounds add head 450 1.8
****FIRST TRIGGER FIRING***
5370h, 6400m, 5500e, 10p, 27900en, 30900w esSilrxk<>-in processwounds modifier is 1.8
Just added 810 wounds.

Posted: Sun Jul 29, 2007 8:06 pm

Yeah, the trouble is that the trigger fires and enables the InnerKnighthood class, but it doesn't parse those triggers against the line it already recieved if their priority number has already gone past. One thing you could try is setting the priority of the triggers outside the class to a lower value than the triggers inside the class.

The #say command always puts its string on a new line, so that's not bug.

EDIT: Yep, my tests show that this works like you want:

#trig {starting part} {#say start fired;#t+ test}
#class test
#trig {ending part} {#say end fired;#t- test}
#class 0

#t- test

#say starting part some other random test ending part

If you change the priorities round, it stops working.

Novice Joined: 26 Apr 2007 Posts: 44

Problem solved - lowering the priorities from 60xxx to 40xxx solved it. Hooray! Thanks!

Magician Joined: 25 Oct 2000 Posts: 461 Location: USA

Posted: Sun Jul 29, 2007 10:35 pm

Actually, you'd be surprised how many MUDs don't actually have any server-side wrapping at all.

Magician Joined: 25 Oct 2000 Posts: 461 Location: USA

Interesting... must be my LPmud background (where server side wrapping without the option to turn it off is prevalent). Trigger creation is MUCH easier with the ability to turn it off. So much so that I'm tending to agree with your bias :)

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

Lusternia has a wrapwidth 0 option now, and I'm basing my new CMUD scripts on using it. Get with the program, Forren! Razz

Novice Joined: 26 Apr 2007 Posts: 44

Posted: Mon Jul 30, 2007 5:25 pm

There's a version of MudBot around that fixes that segfault. It might be on the LMTS sourceforge site.

And yeah, they would in this case but some things (like gobby people on channels and rooms with tons of stuff in) will change.

Novice Joined: 26 Apr 2007 Posts: 44

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I'll have to try it on my LMTS, and if it does break (in a spammy stockroom or something), then I'll find a way to fix it. I've found other issues with LMTS that I really haven't had time to fix, like not being able to 'map load,' and it's driving me nuts.

Novice Joined: 26 Apr 2007 Posts: 44