Auto-Rescue Triggerset

[ShadowDrake]

Perfected the autorescue set. Also has a nice list of commands to add,remove, or reset the rescue list!

A nice little bonus I included was an alias called 'groupres' that automatically adds everyone in your group to the rescue list. Remember to reset the list before you add the group.

**Add this line on the command line to create the group alias.**

#ALI {groupres}{group;#T+ Res_Group_Add}

***Here's the meat. Copy and paste to a txt file and load as a script.***

#CLASS {Auto_Rescue}
#ALIAS rc {#forall {@rescuelist} {rescue %{i}}}
#ALIAS addres {
#VAR rescuelist %additem( %1, @rescuelist)
#SA %1 ADDED TO RESCUE LIST
}
#ALIAS delres {
#var rescuelist %delitem( %1, @rescuelist)
#SA %1 REMOVED FROM RESCUE LIST
}
#ALIAS resetres {
@rescuelist = default
#SA RESCUE LIST RESET
}
#VAR rescuelist {default} {default}
#TRIGGER {~< T: ({@rescuelist})} {rescue %1}
#TRIGGER {* {hits|slashes|crushes|misses|whips|pierces} *({@rescuelist})*} {rescue %1}
#CLASS 0

#CLASS {Res_Group_add} {disable}
#TRIGGER {psp %1} {#IF {%1 = @SelfName} {} {addres %1}}
#TRIGGER {~<} {#T- Res_Group_Add}
#CLASS 0



[This message has been edited by ShadowDrake (edited 07-12-2001).]

[Letat]

This is an alternative. This works as soon as the tank (presumably YOU) gets switched off of and continues to work until you are the tank again. It will also continue rescuing after the first try until you hit. Also, I'm adding a trigger that will automatically put you back in the thick of battle after being rescued. May be one that some casters would prefer to leave off, but some may like it, so it's here. If you want to be able to turn it off, just class it and adjust accordingly.

#TRIGGER {* switches targets..} {#T+ autorescue}
#TRIGGER {You fail the rescue.} {#T+ autorescue}
#TRIGGER {* T: (%w) *} {#IF (%1 != Marlir) {rescue %1} {#T- autorescue};#T- autorescue} "autorescue"
#TRIGGER {You are rescued by (%w)?} {assist %1}

Replace "Marlir" with your character's name in the third trigger.
------------------
Letat N'lavalia
Slayer of Time, Defender of his own arse.

[This message has been edited by Letat (edited 07-12-2001).]

[ShadowDrake]

This should work to assist when you are rescued, Letat.

#TRIGGER {You are rescued by (%w)} {assist %1;tell %1 Thank ye fer the rescue!}


Plus, the trigger I listed rescues all listed members, that way if someone in your list is being attacked by another mob, not the current one, it'll save their ass, cause sometimes you just can't see that other mob attack in the heat of battle.


[This message has been edited by ShadowDrake (edited 07-12-2001).]

[Kegor]

Thank you for posting that... there are tons of sucky warriors out there that like to watch thier casters die.

-Jaznolg

[cherzra]

It's far from perfect though, this is actually the simplest version. My set is much better! *wink*

[Vipplin]

*nod cherzra*

I don't like spamming rescues, and I didn't like missing any either, so I went way overboard on my rescue triggers.

*boggle me*

Vadian the Rescue Ranger

[Xyd]

Hrm... I'm still somewhat new to tanking so autorescue sets are interesting to me, but my first glance at this trigger set leads me to believe it's going to try what I call a "brute force" rescue by spamming. Also, for example, if Zobit is suddenly tanking and he takes 6 hits, won't this triggerset send "rescue zobit" 6 times? Would this overflow some sort of "per-round-rescue buffer"??

My experiments with rescue thus far tell me spamming rescue isn't very effective -- could a more seasoned warrior shed some light on this perhaps?? Is there a limit as to the number of rescues that get processed per round?

.xyd

[Galok Icewolf]

spamming rescue.. is something that happens. Ive saved more then a few caster lives...

I think i have the same resuce set as cherzra....

[Vipplin]

Yup, that triggerset will spam like hell. There are only two disadvantages to that:

1) You can't pick up your weapon, say anything, do anything at all until every one that was sent finishes.

2) It is SPAM, but thankfully only for you.

You see, the extra rescues will just zip by with no lag once you have gotten all the mobs off of everyone, or they're dead or they fled.

The failed attempts and successes will lag you.

If you only send one command at a time, waiting for the outcome before sending another, you will incorporate pinglag and be less successful (quick) at successive rescues than spamming rescues. You will, though, be able to pick up weapons and issue commands etc. after only waiting one lag period.

The ideal, in my opinion, is to have one rescue being performed, and another in the mud's command queue. That way the mud isn't waiting on pinglag for the next command, and while you're mudlagging from your attempt/success, another command is on the way. This allows you to issue commands to the mud after a maximum of 2 rescuelag periods, which I find acceptable, and maintains maximum rescuing speed.

The triggerset to accomplish that is kind of complex, but I'm a nut. If people are interested I'll post it (it's like a friggin' novel) in a week or so (I'm going to be w/o internet for a week! ).

Vadian the Rescue Ranger "You want nuts? I've got nuts!"

[kobdahn]

Just thought I'd throw in my 2 cents.

I don't like the triggering off of events that happen often(slash, miss, pound, crush, beats, drains, etc) because they slow zmud down and zmud isn't very stable when you have lots of triggers.

Here's what my party does. The warrior has a trigger for "switches targets" that causes a look. In the room description you will see who is getting attacked. "here, fighting Barney". The warrior has a trigger for each player(for performance reasons to avoid n^2...although it's probably overkill if you have a small group) that will set a variable to @switchedPC. From there, the warrior uses an rpc alias(not remote procedural call to rescue the @switchedPC. This also works for when you walk in a room and one of your partymembers is already fighting.

The other nice thing about this method is that it is very fast. Our paladin consistently rescues before the mob gets a chance to swing. And in the end, that's what's important to this Shaman.

kobdahn

[kobdahn]

For example:

< 155h/155H 152v/152V T: Galorion TC: excellent EC: pretty hurt>
You pound a bored ogre.
Hastlek barely slashes a bored ogre.
Galorion maneuvers his mount to avoid a bored ogre's attack!
A bored ogre switches targets..
look
Galorion slashes a bored ogre.

< 155h/155H 152v/152V T: Kobdahn TC: excellent EC: pretty hurt>
cast 'unleash fetish'
Hastlek starts casting an offensive spell.

Galorion group-says 'kobdahn is tanking!'

< 155h/155H 152v/152V T: Kobdahn TC: excellent EC: pretty hurt> You start chanting...

< 155h/155H 152v/152V T: Kobdahn TC: excellent EC: pretty hurt>
Casting: unleash fetish *
You are rescued by Galorion!

Bugger never even took a swing at me

[Klurg]

Umm kobdahn Just because a event happens often it dont make zmud slower... What affects it is the Number of the triggers since every single line that are sent from the mud needs to be checked trough the triggers even if they trigger or not.
There are also events when a caster ends up tanking beside switches IE aggro mobs walking in and things like that... This is the set I use there are some variables and stuff in there that im working on at the moment as the need_rescue and a couple of others just leave them out if u dont wanna use em:


#CLASS {Auto_Resc}
#ALIAS radd {#additem resc_list {%1}}
#ALIAS rdel {#delitem resc_list {%1}}
#VAR Hit_Types {crushes|slashes|hits|bites|whips|bludgeons|punches|claws|strikes|smashes} {crushes|slashes|hits|bites|whips|bludgeons|punches|claws|strikes|smashes}
#VAR Hit {crush|slash|hit|bite|whip|bludgeon|punch|claw|strike|smash} {crush|slash|hit|bite|whip|bludgeon|punch|claw|strike|smash}
#VAR need_resc {you}
#VAR rescflag {ON}
#VAR resc_list {Noliez|Narsliss|Tronglonok|Sizzraxxil|Grumdikanikus|Tsaej}
#VAR tank {Klurg}
#TRIGGER {* ({@Hit_Types}) (%w) {hard|very hard|extremely hard}.} {#if (%ismember(%2,@resc_list)) {rescue %2;#var need_resc %2}}
#TRIGGER {* ({@Hit_Types}) (%w).} {#if (%ismember(%2,@resc_list)) {rescue %2;#var need_resc %2}}
#TRIGGER {* ({@Hit}) seriously wounds (%w).} {#if (%ismember(%2,@resc_list)) {rescue %2;#var need_resc %2}}
#TRIGGER {(%w) avoids being bashed by * who loses {his|her} balance and falls.} {#if (%ismember(%1,@resc_list)) {rescue %1;#var need_resc %2}}
#TRIGGER {* ({@Hit}) enshrouds (%w) in a mist of blood!} {#if (%ismember(%2,@resc_list)) {rescue %2;#var need_resc %2}}
#TRIGGER {* ({@Hit}) nearly slaughters (%w)!} {#if (%ismember(%2,@resc_list)) {rescue %2;#var need_resc %2};}
#TRIGGER {In his haste to slam (%w) around, * slips and falls!} {#if (%ismember(%1,@resc_list)) {rescue %1;#var need_resc %1}}
#TRIGGER {* suddenly looks a bit dumb, and madly slams at (%w)!} {#if (%ismember(%1,@resc_list)) {rescue %1;#var need_resc %1}}
#TRIGGER {* switches targets..} {#forall {@resc_list} {rescue %i}}
#TRIGGER {lands a mighty ({@Hit}) on (%w)!} {#if (%ismember(%2,@resc_list)) {rescue %2;#var need_resc %2}}
#TRIGGER {* enshrouds (%W) in a mist of blood with her deadly ({@Hit})!} {#if (%ismember(%1,@resc_list)) {rescue %1;#var need_resc %1}}
#TRIGGER {(%w) staggers from a fearsome ({@hit}) from *} {#if (%ismember(%1,@resc_list)) {rescue %1;#var need_resc %1}}
#TRIGGER {(%w) dodges * attack.} {#if (%ismember(%2,@resc_list)) {rescue %2;#var need_resc %2}}
#CLASS 0

[kwirl]

I have a played a warrior for a long time, and for the longest time - i didnt have any triggers at all "hello, telnet"

im looking at these scripts, because from what i see - the warrior big names, seem to think these scripts are almost a requirement. fine, i can adapt. I appreciate you posting your script - i really dont have the time to write my own right now. one question - how would i add an alias that would show who is in the rescue list?

[Jegzed]

#say @resc_list

[Jorta]

Hello All,

Thanks for sharing the rescue lists. I was wondering if someone could remind me how I get that resc_list to show up on my status bar?

Thanks!

Jorta

Feh, actually that was easy.... How about this then? My old rescue set used to have a button that would turn the entire list on and off when I needed to. How would I get that to work instead



[This message has been edited by Jorta (edited 07-18-2001).]

[belleshel]

#BUTTON 1 {Rescue On} {#T- Auto_Rescue} {Rescue Off} {#T+ Auto_Rescue} {} {1} {} {} {} {} {} {} {} {} {} {} {} "" {} {} {}

[kobdahn]

Klurg,

Let me try putting it this way. Maybe I mispoke. Sorry if I ramble.

1) The more triggers you have the slower ZMud will run. For every line, Zmud has an "order n" loop through the triggers. As a result, the more the n, the longer it takes to run. Yes, n has to be a very large number before you notice a difference. That depends on your system. But I am building a large set of triggers and don't want to performance tweak later.

2) The more triggers that fire, the slower zmud will run. Will you notice it? Again, it depends on how often and how many triggers. Not only does ZMud have to do an order n traversal(#1 above), but it has to perform the emulation of your command. Again, the time it takes to emulate your command depends on it's complexity.

3) ZMud is buggy. I used to have a similar triggering system, and it would crash once every 4-5 hours. If I was in a town or resting, I wouldn't care, but it always happened during combat. Hopefully you don't have this problem.

So, if we look at this from an algorithms viewpoint for every line Sojourn sends, you do an order n loop through your triggers. If you only had the triggers listed in your script, you would have 13 triggers(so n=13). 8 of these triggers have for loops(for hitting types) in the trigger(making it order n*m). In the end this is equivalent to having 75 distinct triggers(given your example and assuming Zmud is written efficiently) for autorescuing. Now, if you look at the emulated action, all 13 triggers have emulated for loops(to see if the person is in your group). This processing is order n(6 in your case). So, if one of your triggers fire the algorithmic complexity becomes roughly order (n*m*x).

For most people you won't notice a difference with just this script. It depends on how many other triggers you have, how fast your PC is, and what else you have going on in the background.

With all this software talk/rambling done, if you are a warrior, I recommend using Klurg's method. The only difference I would say is to change the "switches target" trigger to rescue the person being hit, instead of rescue all. Either that or you pay off the tank to put you at the front of the list.

kobdahn

[Klurg]

Correctamundo Kob....
U put it way better that time And I agree zmud gets itchy with many triggers thats why im using linux and TF instead just sharing my old settings for ya all if a mage is tanking more then one round he is free to whap the warriors in the group repeteadly!!!

[Gindipple]

kobdahn,
Just curious if you know for sure it's an order n and not an order log (n) IE a binary tree.
On the issue of having too many triggers, I've never really run into this and I use many. That's on a slow 333MHz machine too.
I have had some slowdown however whhen my mapper window is on.
A basic full set of warrior triggers on any decent computer today should have little to no effect.

[belleshel]

Actually kobdahn that isn't correct.
Zmud extracts the largest literal string from a trigger and uses that to fail lines very quickly. Only after it can't fail a line will it go about using the slower expression parser. Thus its nowhere near the equivalent to having 75 distinct triggers.

Hope that helps,
Belle

[Drevarr]

Since we are discussing text parsing and pattern matching now, I thought I'd post some comments from the zuggsoft board from a few years back:

Excerpts of various posts regarding zMud's Parser and Pattern Matching
Performance.

Basically, what zMUD does is extact the largest literal string in a pattern that must be
present. It then uses this literal string to perform the initial comparison, since it is important
to fail lines as fast as possible. If the literal string test succeeds, then zMUD continues with
the slower regular expression parser to see if the candidate line is really a match of the true
trigger. If there are no wild cards in the pattern, this second step isn't needed. So, it is always
advantage to include some literal text in your pattern. A pattern that is entirely made up of
wildcards will really slow down zMUD since the regular expression parser will have to test
every line from the MUD.

The ^ and $ wildcards are handled seperately and are not considered true wildcards.

I hope that helps the understanding of the trigger parser. It is designed to fail lines very
quickly.

Building multiple choices into one trigger should not only be faster but also reduce the size
of your file, speeding up processing time. Whether or not you use two separate triggers will
not affect the speed at which the trigger fires. Basically, the fewest triggers are the best,
since zmud has to watch every single trigger to see if it is matched, you can see why you'd
want only one trigger with a variable list rather than two separate triggers that perform the
same function.

For speed reasons. When zMud matches a plain text pattern, it can use very fast, very
efficient matching algorithms. A simple pattern like:

^The quick brown fox jumped over the lazy dog.$

Is much faster to parse than this:

^The quick brown fox {jumped} over the {lazy} dog.$

Even though both patterns will match the EXACT same line, the top pattern is much faster.
The bottom pattern has to be passed to the parsing engine, which figures out what you
want to do, finds the special patterns, tests them for matching, then returns back to the
main pattern engine with whether the pattern matched or not.

Complex patterns are much slower than simple text patterns. It's faster to match two
simple text patterns than one complex one. KISS.

======================= Trigger Set Testing =======================
This is an excerpt from a post a couple of years by ago Darker regarding zMud
performance with various trigger sets.

Want to know how fast zMUD's running for you? Connect to your mud, and Hold the
Control key and press Q. You'll see the alphabet and numbers fill up your screen, and
when it's done, on the status bar is a little number. That little number is a speed rating of
how fast zMUD performed with all your triggers running.

Typically, I get a number anywhere from 11 to 22, it depends on how many triggers I have
running.

Now type #ig, to temporarily turn off all your triggers, and do Ctrl-Q again. The number
should be much lower (I got a 6). You can easily see the difference between when
zMUD's parsing your triggers, and when it's not. Having a huge list of triggers definitely
bogs it down, and you'll see a higher Ctrl-Q number as a result.

Remember to type #ig again to turn your triggers back on.

Zugg's done a great job of optimizing the parsing in zMUD to achieve this, but nonetheless:
the more triggers you give zMUD to handle, the slower it can handle everything else.

Drevarr
Darkward.com

[kobdahn]

Interesting posts guys.

Thanks for the info.

[Gindipple]

Hrmm I'm getting 180-190 from the Ctrl-Q
Maybe I need to check into cutting back on some triggers.
Got 17 with all triggers off.

[Xyd]

There is also the use of trigger sets/classes that you enable/disable as needed. I have about 200 battle triggers that are ONLY on during battle. About 30 triggers that are only on during "recite identify item". Other complete trigger sets are enabled/disabled as needed (like coin handling, attribute tracking, etc.). I don't know how many total triggers I have, but I've never seen a significant slowdown in zMud under "normal" circumstances. The automapper, however, seems to cause a smidge of slowdown at times.

I think the trick is classifying your triggers and only enabling them when needed. Use lists of items where possible rather than multiple triggers (e.g. "(%w) completes {his|her} spell".) A good starting point is to separate battle-time triggers from peace-time triggers. It's hilarious to watch people get some rations from their packs during a battle -- and also a complete waste of time and zmud cycles.

Regarding the autorescue triggers specifically, I'm still experimenting but I'm not in agreement that spamming rescue is useful, especially when multiple switches occurs. I'm fairly firmly parked in Klurg's camp with his ideas, but I'm probably making my version overly complex to eliminate multiple rescue attempts.

One question I still have: Does anyone know the rescue queue length? IOW, I'm sure that the "rescue" code can attempt to rescue n people and that the N+1th person will be ignored. What is n?

.xyd

[Klurg]

Hehe yeah Xyd u see that need_rescue variable in that trigs i pasted said it was for future expansion i now finnished it of pretty good not spamming rescues only rescues once wait for a successes or fail then rescues again if failed or else rescue next target in line now to figure out a way to put the lowest hps target in the line of rescues where many is getting hit at the same time

/Klurg

[Vipplin]

Klurg, I have a set that is like yours, but I have two rescue commands out at once instead of one so there's no lag between attempts.

I haven't prioritized on hps, I just use who got hit/missed first myself. If you wanted to do hps, you could capture ppls' max_hps from the group command and sort your list via that each time someone is added to the list (casterlist=names and hps, needs_rescue list sorted on that order). A simple bubble-sort routine could manage that. It shouldn't even lag you if it only kicks off when a new person is added to the needs_rescuing list.

BUT, It probably isn't worth the trouble, especially since how many hps someone has doesn't indicate very reliably how much they need a rescue.

Vadian

[Klurg]

Ok i come to the conclusion that the one that is getting hit hardest are most times in most need of a rescue so it will now make the targets thats getting hit the hardest getting a rescue first and there is a function to prevent certain people to be moved back in the list like if u cant afford to loose the cleric or the chanter they can be set to always get rescued first.. will post it when i cleared the mess up

/Klurg

[Ubek]

I have a 1.2 ghz with 500megs of ram, bring on the triggers :P Wouldn't it be funny if I actually bought this system to mud?

--------------

[Jorus]

Xyd,

I'm pretty sure the "rescue" code makes use of the same command buffer (fifo) that we get for all of our commands sent to the mud. When one command finishes, the command processor asks a buffer for the next command (or so). I assume this buffer is in the server code as re-connecting to the mud clears is, from what I can see.

I have yet to see the limit of this buffer, though I'm sure someone _could_ check it out:

#99 {var1=%{i};#99 {var2=%{i};say @var1 @var2}}}

Of course, I don't know if this would trigger some sort of "kick" from the mud. Who knows.

I would imagine, however, that if the stream/buffer is in the server code, it is some sort of TCP stream, and the buffer length is limited only by the mud machine's ram.

I just tried the command above, and it accepted all of the input, and is currently returning the "say N M"'s to me, from the mud. So the buffer is somewhere in the realm of over 10,000 commands (these are short commands though :P)

Regards,
Jorus

[Vazzgo]

Had to post to keep this subject up.

[Jhorr]

Best rescue triggers I've ever had, with macro to autobuild your rescue list off the group list.

Aliases:

#alias {addgroup} {#T+ Add_Group; group}
#alias {addtank} {#VAR tanklist %additem( %1, @tanklist); #SA %1 ADDED TO
TANK LIST}
#alias {addres} {#VAR rescuelist %additem( %1, @rescuelist); #SA %1 ADDED TO
RESCUE LIST}
#alias {clearres} {rescuelist = ""; #echo Rescue list - Cleared.}
#alias {cleartanks} {tanklist = ""; #echo Tank list - Cleared.}
#alias {delres} {#var rescuelist %delitem( %1, @rescuelist); #SA %1 REMOVED
FROM RESCUE LIST}
#alias {deltank} {#var tanklist %delitem( %1, @tanklist); #SA %1 REMOVED
FROM TANK LIST}
#alias {displist} {#SA CURRENT RESCUE LIST:; #forall {@rescuelist} {#SA
%{i}}}
#alias {disptanks} {#SA CURRENT TANK LIST:; #forall {@tanklist} {#sa %{i}}}
#alias {autoron} {#T+ autorescue; #ST Autorescue is ON}
#alias {autoroff} {#T- autorescue; #ST Autorescue is OFF}

Triggers:

#action {* fighting *({@rescuelist})*} {rescue %1} {autorescue}
#action {p/} {#T- Add_Group; #sa Group Add Off} {Add_Group}
#action {psp %1} {#IF (%ismember(%1,@tanklist)) {} {addres %1}} {Add_Group}

Instructions:

1) Build a list of tanks you group with by using the 'addtank <tankname>'.
Include yourself.
2) When group is assembled, type 'addgroup'. Macro will add only those in
group that aren't on your tank list.
3) Verify the list(s) with the 'displist' and 'disptanks' commands.
4) Fine tune the list manually, if needed, with 'addres <pcname>' and
'delres <pcname>' commands.
5) Use the 'clearres' and 'cleartanks' commands to clear the lists when you
need to.
6) Toggle autorescue on and off with 'autoron' and 'autoroff'. Status
appears just above your command line in Zmud.
7) Macro rescues people on the rescue list who are tanking when you 'look'
at the room. It doesn't spam a list.

[Galkar]

That's pretty sweet, but does it continue to attempt rescue until successful? Maybe make it continue to attempt rescue on that one person until done, the switch to next if more than one person is switched to?

[Jhorr]

I have a additional trigger to retry if rescue fails:

#action {You fail the rescue} {look}

This causes spam sometimes though so I don't usually use it.

Would be complicated to code it so it remembered who you failed rescue on....

[old depok]

Thinking about adapting this for rescue set for spirits (due to a few groups with limited rescuers lately).

I can see that replacing the rescue %1 with order tiger rescue %1 will take care of this but have a couple questions...

1. Do you have a trigger that hits the look command upon mob entry (and is there a way to differentiate between mob entry and pc entry?) Mind posting it?

2. In terms of use, do you just Look in a room your fighting in upon entry to ensure that no one on your list is engaged upon entry? I know this is probably moot for you as a tank, but just curious as a non tank rescuer.

Think I'll make a trigger for switches to look. Had considered a way to make it so that when you failed the look command due to casting it would then send the look command after you complete the spell but figure that might screw up my casting. Will probably just highlight the Your are busy casting message and then manually hit the look command. This way if I see that the person has been rescued or I have to get off that Gheal instead of rescuing I can.

[Selias]

Nice trigger sets here guys. I'm trying to find one for my warrior, and I could probably write it myself, but I'm too damn lazy =P.

I'm wondering if anyone out there has a rescue trigger set that doesn't spam (won't rescue the whole list), will rescue people on the look command, will look when a new mob enters the room, and will continue to rescue a group member on a failed rescue until that member is rescued.

I'm not sure if any of these sets on here do that, because I'm having a tough time following the code that has been posted.

Also, how would I load it into a script file?

Thanks

[Grxx]

book mark bump