Because my triggers are so complex, it is hard to give a definite "compact" box with which I could actually POST these triggers.

But I do have a small enough block of self-contained triggers that I might actually be able to post these. These work on the Duris, land of bloodlust, using the MSP terminal (tog term until it reports MSP terminal).

This is an Export Text version of the entire folder.
I have Bolded the more important triggers.
Note, a lot of leftover values are still present from previous groupings.
The variables are not listed, because they are so many, and it should be fairly obvious what they contain, by the name of the variable used.
Here goes:

Code:

this is an example of the mud output when I check the status of the group:
<group>
( Head) Gnord
<195h/195H> <216m/216M>
(Front) a thick-haired buffalo
<106h/106H> <225m/225M>
</group>

Code:

This is an example of what you actually SEE on the screen (note, the lines are colored by the percentage health, which I can't do easilly here.)
( Head) Gnord
<195h/195H> <216m/216M> 100%
(Front) a thick-haired buffalo
<106h/106H> <225m/225M> 100%

Ok, so here's the skinny on what these triggers do:
Group healthbars. The mud outputs a complete group status list (like the one in the first code box) whenever a person in the group gets hit. These triggers keep healthbars on the entire group (with a bunch of extra empty healthbars as space keepers when we're not using a full group). You can click on the healthbar to cast @HealthBarSpell on that person. I usually play a healing class, so I almost always set this to be a healspell.

Why it's good:
Visual NON-SCROLLING identification of the health status of the party. When there's twenty party members, and each of them is getting hit by all sorts of different targets, I literally get hundreds of lines per second. It's impossible to watch it all scroll past and get more than just the most general idea of what's happening. With this, even if the screen is scrolling faster than I can see, I can heal the people who need healing by clicking on the healthbar with my mouse.

You'll note there's a bunch of aliases and things in here that aren't defined in this list. That's because just about all of my triggers build on eachother. If anybody wants, I'll show you what those aliases/triggers do if you request a specific one.

As a last note, I will say that this is one of my LEAST complex sets of triggers. :D Enjoy.

If anybody specifically requests some of my other trigger types, I've got a few categories for you.

Chat - copies all communication lines to another window which isn't scrolling 100's of lines per second. It's also useful to review what somebody has said to you recently, without scrolling your entire mud history.

Mapping - the built in mapper is great, but if I export text this folder, I use 16 kilobytes of triggers to keep the mapper in line. This also colors the rooms by terrain, detects when you try to walk somewhere you can't, maps while FOLLOWING somebody else, rather than moving manually (and as it turns out, this is MUCH more efficient), and several aliases to renumber all the room vnums, in case you somehow ended up with duplicates. In a subfolder, I have a bunch of triggers that control my character when people want me to consent, group, follow, and other simple group commands and instructions.

Names - Use one zmud icon to control all your characters! Keeps track of what class/specialization you are, what your name is, what level you are, and turns on/off specific triggers/aliases/etc to match what your class can currently do. It is actually pretty small, considering how much it has to keep track of.

SmartCommands - Want to use ONE alias to do a whole bunch of things depending on what the current situation? Then you need a SmartCommand!

Spells - This is a HUGE list of all the aliases I use for spells. Lots of subfolders on each class.
It also keeps track of the spells I have memmed, how many seconds I have left to mem my spells, keeps track of "spellwords" and translates them into the actual spell rather than 'waaixzrr'
This also keeps track of the spells I have set into triggers, like the above healthbar system, and my autoBotCleric system.

Storage - Keeps track of your container. loot an unlimited number of corpses! Loot an unlimited number of corpses for a specific item! Loot an unlimited number of <keyword>! Loot an unlimited number of <keyword> for a specific item! The number is quickly definable with a macro key, which scrolls up or down the number. And of course, if you're constantly using different keywords for your container, you can use the same alias for ALL of this, and it already knows what bag to put all your loot in! As a subfolder to this, it also keeps track of your weapons, and an alternate set of weapons you can swap in and out rapidly with a single alias. Also, it has a fairly extensive list of "hot items" that if you notice these just laying around for some stupid reason, you'll grab them, stick them into your <keywordBP> so fast that nobody else will match your speed.

TriggerBot - One of my best and most advanced trigger systems. This one is about a meg worth of triggers, but it's....... awesome. Although most muds consider it illegal, I can turn this on, autoBotCleric for HOURS without ever touching the keyboard. In a good group, with a good leader, this autoBotCleric could literally handle itself indefinitely. Go to sleep, wake up tomorrow at max level. It's that good.

Hello! I was sending you this email because I was looking for help with a script im trying to do and you looked like you are a very experienced scripter. Im a completely newbie and I don't know much about making em. :)

What I'm currently wanting to do is a trigger/script that counts npcs in a room. For example:

A dark forest. You can go: north, south, east
A devilish gnome is sitting here, six cute gnomes are standing here and a big gnome is leaning here.

What I want to do is also make a trigger/echo/script that, when i enter this room it will make me see how many npcs there are, in this case, 5 npcs. So each time i kill one npc (You killed the gnome)it makes a -1 and when it reaches 0 it will see if all npcs are dead and if true, it will make a trigger that sacrificies the corpses.

I have no idea on how you can or if its even possible to make that, but i thought i'd ask. If you have no idea, my mistake i just thought i could send you and hear what you say. :)

Many thanks!

<name ommited>

Alright, <no>, I'm going to present you with the "trigger making process" via me. And, it will probably contain more info than you really wanted, but it might give you some insight on how to make your own triggers in the future, or give other advanced people some new ideas if they see my line of thought.

To begin:
wow, that's brutal.
Duris is a bit nicer in that it puts every npc on a different line.

BUT, I think I can do this. This shall be a recursive trigger. First, I'll introduce you to a little trick I use:

So, here's a simple version of the trick. When Thing A B or C happens, I call the alias Z_CallThisWhenThingABCHappens.

Tips on naming your alias:
You don't want to accidentally activate this alias manually, so have it be a long annoying name, that you would never accidentally type. I start mine with a Z_ so they end up at the bottom of the alias list, as well as it gives me a little "reminder" when I'm looking through my triggers, that says 'this alias is called by a bunch of triggers.

Ok, that was a bit of training in the art of triggery, now for the next step:

A devilish gnome is sitting here, six cute gnomes are standing here and a big gnome is leaning here.

By the way, 1+6+1 != 5 :D

here's what we do.

Code:

#trigger {(%w) (*) is (%w) here(*)} {...}

This trigger covers the following:
A (*) is sitting here
An (*) is standing here
The (*) is lounging here
etc.

Now, the beauty of triggers, and the curse of triggers is that the SAME LINE will not activate the trigger twice. In this case, it would be HANDY if it did, but we don't have that luxury. But, we'll come back to that, because we're not done detecting all the states:

Code:

#trigger {(%w) (*) are (%w) here(*)} {...}

This one catches:
Ten (*) are sitting here
Fifteen (*) are squatting here
Three (*) are bouncing here
etc.

Ok, now we'll discuss false positives:
This kind of trigger can hit HORRENDUS loads of false positives.
Like..... mayhem.
basically
the big switch is glowing here.
obviously a big switch is not a mob. We can filter a bit of the verbs though. BUT, if you have filtered your verbs to ONLY "standing" "sitting" "leaning" the trigger won't catch it when a mob is "squatting" or "laying". So there's a tradeoff.

Let's see how this triggers on your line:
A devilish gnome is sitting here, six cute gnomes are standing here and a big gnome is leaning here.

the "single mob" trigger is going to catch on:

A devilish gnome is sitting here, six cute gnomes are standing here and a big gnome is leaning here.
1: A
2: devilish gnome
3: sitting
4: , six cute gnomes are standing here and a big gnome is leaning here.

and, the "multi mob" trigger is going to catch on:
six cute gnomes are standing here and a big gnome is leaning here.
1: six
2: cute gnomes
3: standing
4: and a big gnome is leaning here.

So, now I will warn you that I'm thinking via typing here.
If the alias I make (Z_CountMobsInParseString) is going to count the mobs, then I've gone and counted all the cute gnomes and the big gnome twice. Trigger reports 15 mobs. It's supposed to be 8. Bad news.

SO, I didn't make my trigger correct, I'll have to accomplish this in a FANTASTIC single trigger. But, the downside is almost unlimited false positives that we have to filter. But we can handle that.
So, we need a better trigger that doesn't count everything twice:
#trigger {(%w) (*) (%w) (%w) here(*)} {...}

now we've restricted it back down to the original two triggers, using only one trigger in it's place. Let's call that "TRIGGER ACCOMPLISHED" and move on to the alias in the next post, right after a few comments:

we're still going to have a lot of false positives in this trigger, despite the fact we've restricted %3 to only process when %3 is "are" or "is". Further discussion may be needed to decide how to detect these false positives, because in any given mud, you may or may not end up with lots of things that match the above line. If we DO end up with more false positives, we may have to further restrict the "words" list so that, say
%1 can only be "a,an,the,two,three,four...,eighteen,ninteen,twenty"
This would be accomplished using the %match() function and a ton of or statements, all beside the ones I gave above.

the more restrictions you place, the better chance of you throwing out false positives, but the more work the trigger does, and there is also the chance you always have of throwing out a line you actually need.

BUT, if that turns out to be the case, then that will be discussion for another time.

Now, you may be wondering "why does he keep the ENTIRE line, practically unchanged in the variable NumberMobsParseString?
That is because this is going to be a recursive alias. This alias is going to call itself. Now you may be thinking "OMG PANIC", but don't worry, we won't destroy your zmud.

Recursive case:
The string NumberMobsParseString is not empty.
Base case:
the string NumberMobsParseString is empty.

So, now, as it turns out, once we've decided that the contents of NumberMobsParseString are DEFINITELY a list of mobs (this is 100% the job of the trigger, once the alias is called, we have decided "BY GOD IT'S A MOB LIST") we can begin counting them. Which is 100% the job of the alias.
Simple version of what I said:
Trigger determines if it is a mob
alias counts the mobs.

In case you're not familiar with my terminology NPC=mob and vice versa.

Let me just load this mess into zmud real fast.... (you wait for a short period of time)

*CRY*

It doens't work. It's triggering on the FIRST word "A" and then the * takes up the ENTIRE LINE, leading to the last "here", which means that I've got to figure out how to do some string manipulation, sans trigger.

I'll come back with another post once I've played with this in zmud. DON"T USE THIS YET, it'll kill yer zmud.

It took some doing.
My original plan was to parse the FIRST mob in the list of mobs.
IE
parse : "A devilish gnome is sitting here, six cute gnomes are standing here and a big gnome is leaning here."
would process like this:
+1 mob, parse : ", six cute gnomes are standing here and a big gnome is leaning here."
+6 mob, parse : " and a big gnome is leaning here."
+1 mob, parse : "."
which would fail to match, and then it would report 8 mobs.
BUT, because of the way the trigger matching occurs, mainly that the (*) seems to eat up as much as possible, rather than as little as possible, I had to reverse the parsing order:

So there you have it. A few restrictions:
the mob must be "is verbing" or the mobs must be "are verbing" in a room for this to work, they can't be "A big bunny bounces here." If the mud reports "A big bunny is bouncing here" it'll work.