Cool thanks. I will give this a look when I get home from school.

hi,
Well, first, you need examples of the text you want it to trigger on from the MOO its self. As in, if you want to get something to happen, it  has to be tied to a specific text event, such as, x fires the boomstick in to y's head, making an all mity crack!

hi, That's exactly what a trigger is. Lets look at my erlyer example.
x fires the boomstick in to y's head, making an all mity crack!
Now, lets break it down.
x fires the boomstick in to
X, is obviously a person named x name. So, I'll look at it in vipmud terms. To do this, you would put in the event field:
* fires the boomstick in to
And we'd do the same with y.
*'s head, making an all mity crack!
the full trigger in vipmud would look like this.
* fires the boomstick in to *'s head, making an all mity crack!
What if we wanted to have the same sound for different weapons? No problem!
* fires the * in to *'s head, making an all mity crack!
I hope i've explained this right. to get a fuller understanding, i'd read a mush scripting tutorial to get special simbles etc.

I've gotten the concept, and have since made one fabulous trigger! The connect sound. This, for me, is one gigantic step into the developer community.

I don't think I am going to get into Scripting yet. In 1.0, the triggers and a few macros are all that will be in. Then I will get into the Scripting. It's a matter of getting a firm foundation down. Are there any good audio tutorials that teach LUA? I can't do it in text without learning by ear what stuff is supposed to look like.

with the control tab thing, that's dependent on the output functions plug-in, so you'd need that to be activated.
I use it on every mud I play and it works fine.

hi everyone,
I'm wondering is there any guide on writing plugins aka soundpacks?
I'm getting some problems. when I connect to a mud, the login doesn't  appear correctly, like it doesn't speak correctly...can someone help me in that?

You need to use lua audio. you need the plugin ID for it, and then you do ppi.load(blablablablablabla), all your triggers will then take the form of ppi.play("path", 0, vol, pan) where that first 0 is the sound slot, you get ten. Forgive me if the syntax is a bit off, I haven't done it in a while. Also, you want to make regex triggers wherever possible, because that way your triggers will not interfere or get crossed up with one another. A lot of packs use wildcard triggers, which is something like [* chat * which works just fine until someone says to you, I wanted to have a chat with Billy. Then your chat sound goes off.

You could of course clean this up a bit without using regular expression triggers by just including more of the string, for instance, if your mud puts brackets around its chat channel, supposing it even has one, you could do [chat] *. You don't need that forward star in front of the chat, that's causing issues for people. Learning regex is a %*#$ing pain in the 4$$ so if you go that route, be prepared for it, but it does give you a lot of power and flexibility.

Let's say I wanted to buffer all chat messages using the chanelhistory.xml plugin. I didn't want to include the chat string, just the relevant bits, name, and message. You can format this however you'd like, I'll give an example. First, let's say our output from the mud when the chat channel is used takes the following form: [chat] Nocturnus says, "message"

Now we have some pieces of information needed to make a regular expression. Go in to your triggers list and hit add, then hit alt X to check that box so you don't forget, then alt T again to get back into the trigger, then type in the following

^\[chat\] (.*) says, "(.*)"$

Alright, so that seems crazy, right? but its not, let me break it down for you. The caret thing which looks like an inverted V means basically beginning of line, in other words, were asserting that this is the beginning of the matching line. Now, you may be asking yourself why are their backslashes in front of the brackets enclosing the chat. Well, that's because brackets are used in regular expressions to create a set. like this: p[aeiou]tter. Now, that regular expression would match patter, petter, pitter, potter, and putter, not all of which are words, but you get the idea. So we need to escape those brackets, which just tells the thing, hey, we're not doing a set, we literally mean brackets, so don't interpret it as a set.

Also, why are there parentheses around parts of this expression? Parentheses have several meanings, part of which is to start a branch, so you could have (thing1|thing2|thing3), which means either this one, that one, or finally *that* one, not both, not all, but only one. That symbol in the middle there is the pipe symbol, commonly used in unix like operating systems to pipe things into and out of stdin and stdout. Anyway, for our purposes, the parens do another thing, they mark out what's inside them as things we can refer to as wildcards.

Now, let's move onto that dot star or dot asterisk syntax. The dot, or full stop means literally any character, remember that example with patter pitter, etc? it could also be written like this: p.tter In this case, it means literally any character can fill the place of that dot, not just vowels, and it will still match. The asterisk is a quantifier, it just means zero or more, and now that I think about it, since we want both those fields to be filled in, it would be more appropriate to change the asterisk to a plus sign, which is also a quantifier meaning one or more.

That covers everything for this example except for the dollar sign, which simply means end of line. SO, the caret is beginning of line, and the dollar is end of line. Notice how we included the quotes in the regex rather than just encapsulating them in the .*? I did it that way so the quotes would be left out of that second wildcard to give you flexibility to format it however you wish.

Now that that regular expression is finished, you will want to go into the send box and do something like this, then you will go down two and change that combo box to script. Going back up in to the send, do the following:

history_add chat=(%1, %2)

The %1 and %2 are how you refer to those wildcards in the order they appear inside your regex. You can also format that however you wish, or if you don't want to format it, leave off the parens and delete everything inside them and change it to chat=%0. %0 is the entire matching line.

Now, one more thing, you will probably want to create a .lua file for your world which is part of our pack. This is where you link the external file to and is where you put the ppi.load method call. In this file you will want to do something like the following: global path=Getinfo(56) + "/worlds/aardwolf/sounds/"; But what is that Getinfo(56)? All that is saying is give me the path of mushclient's executable. After that we do what is called string concatenation, what that means is that we join multiple bits of info into one string, the + sign in lua is for that purpose, also for arithmetic addition, so its called an overloaded operator. We're basically forming a root so that we can use relative paths in the pack. We also leave it with a trailing / so that you don't have to prepend one to every sound trigger. The global in front of path is just saying I want to access this variable anywhere i.e. globally. So what this does is saves you a massive amount of typing. You could use it in a trigger like this. Let's say you had a folder structure in your Aardwolf/sounds folder that was like: combat, communication, general, etc. etc. etc. Your chat sound would be in communication, so in that example trigger earlier, you could add a line that looks like this: ppi.play((path+"communication/chat.ogg"), 0, 50, 50) and it would both play the sound and buffer it. I forget which one comes first pan or volume, I'd have to look inside luaaudio.xml to straighten that out but still... you get the general idea.
I'm sorry if that was too slow going or whatever, I don't know how much you know about programming and regex, not trying to be insulting or anything, just wanted to make something anyone should be able to follow. If you want more help with this, skype me or something, pm me and tell me here you sent one because  I never check them.

yeah no problem, you can add me on skype with bscross32, also I have a teamtalk server which I can fire up, I have more memory on my server now so there's no concern of letting it run 24/7 now, or face time something like that, whatever works for you I'm fine with.

You don't need to know every single thing about lua to make a soundpack. All you really need to know is variables and data types and if statements for certain things.

Right and that's fine, but what he was saying is he has limited experience with programming. In that case, the goal then is to do as much as possible without introducing abstract programming concepts. The minimalist approach, do as much as you can with whatever you got. Learn only what is necessary to do those tasks. Tables aren't really needed for a basic level, in fact, I can easily see a point where it becomes detrimental to introduce too many concepts too quickly. And building MUSHz probably took years, I know Wayune was one of, if not the main devs, and I don't know if he had help, but that pack grew to this crazy thing, a really good pack, but its just so big. I think for building something like this from scratch, its more important to get the thing functional before adding features like area music and the like.

You don't say to an aspiring chef, OK, here's this cooking manual, learn everything in it, then we'll talk. You start them up with small things, and build layers of understanding based on introducing concepts one at a time. If someone knows nothing of cooking, they need to have some basic concepts. So what concepts does a chef need, let's see

• Heat - low heat for simmering, medium heat for general cooking, high for boiling, high can burn your food rapidly

• General measuring knowledge - of which I have very little, so use siri or alexa

• Ability to follow instructions, but know where its safe to deviate if needed or desired

There are more obviously, but my point is you learn some things and work with what you have. When you feel confident with what you're doing, then you hit the books and learn more, you don't try to cram in knowledge, also at least for me, too much theory and not enough practice means I will not learn effectively. I need equal amounts of both. The practical sets the theoretical up in my mind, and makes associations that weren't there before.

I have also studied code examples from other packs, because I am not a good programmer, and never claimed to be, but I can get by, if not with a bit more frustration and cussing than some more talented people. Some of these packs are coded terribly, to be frank, and not worth studying at all. It was good that I knew better and didn't do what they did.