====== ArmA 2 Sound Config Tutorial ======

[[https://www.pmctactical.org/forum/viewforum.php?f=50|ArmA 2 Forum]], [[:arma2|ArmA 2 Home]], [[arma2:config|ArmA 2 Config]], [[arma2:file_formats|ArmA 2 File Formats]], [[arma2:missions|ArmA 2 Missions]], [[arma2:modeling|ArmA 2 3D Modeling]], [[arma2:scripting|ArmA 2 Scripting]], [[arma2:terrain|ArmA 2 Terrain]], [[arma2:texturing|ArmA 2 Texturing]], [[arma2:tools|ArmA 2 Tools]]

This is beginner tutorial, it tries to assume that reader don't know much about editing. So first you need to read the [[arma2:beginner_editing_guide|ArmA 2 Beginner Editing Guide]] which teaches you the basics.

Goal of this tutorial is to teach how to write config file to work with your custom weapon sound files. Specifically we demonstrate how to make M16 sound replacement config.

For purposes of this tutorial we call our tag "TAG_", but you need to use your own tag.

To begin the editing properly, please read [[arma:installing_bis_tools|Installing BIS tools]] tutorial by PMC and [[arma:build_environment|Build Environment]] by Synide which instructs you how to configure your directories and BinPBO.


====== Sound Files ======

Your sound files need to be WSS format, **do not use WAV or OGG**.


====== Addon Name ======

For this tutorial we use addon name of TAG_MySounds.pbo


====== Config File Creation ======

The configuration file is called "config.cpp" and its located in the root of your TAG_MySounds.pbo file.

Browse to the P: root (the BIS tools subst drive explained in [[arma:installing_bis_tools|Installing BIS tools]] tutorial), in there you first create a directory called "TAG" which is your name space. Then in the TAG dir create "TAG_MySounds", then create text file there named "config.cpp", make sure it is NOT "config.cpp.txt" as that wont work. We highly recommend you use proper text editor and not try to edit with notepad or wordpad.

The whole structure looks like this:
<code>
TAG\TAG_MySounds\config.cpp
</code>


====== cfgPatches ======

cfgPatches is what starts most of the addon configs, however some BIS configs start with other classes first, so its not strange to see this class being somewhere between other classes, however it might be good idea to put it first on user made addons.

Here is the beginning of your config. Notice the class TAG_MySounds which will be your addon name.
<code cpp>
class CfgPatches
{
	class TAG_MySounds
	{
		units[] = {};
		weapons[] = {};
		requiredVersion = 1;
		requiredAddons[] = { "CAWeapons" };
	};
};
</code>

The requiredAddons defines the other addons what are needed to be present (and loaded with either in default ArmA addons dir or with a -mod dir parameter), in this case its "CAWeapons" which is the ArmA main weapons addon.

To understand cfgPatches meaning, the ArmA main weapons addon is defined like this:
<code cpp>
class CfgPatches
{
	class CAWeapons
	{
        ...
</code>
You can compare it to yours and see how the addon "name" is created.


====== Fire Mode Classes ======

Because weapons usually have fire modes, which are classes inside the weapon class itself, those have to be declared before hand so they are available for our weapon class.

<code cpp>
class Mode_SemiAuto;
class Mode_Burst;
class Mode_FullAuto;
</code>
Put those fire modes into the global config space, meaning not inside cfgPatches and not inside cfgWeapons. You could put that between them in the config.cpp file.

If you do not declare these classes, binarize gives you error.


====== cfgWeapons ======

cfgWeapons class is where all the weapons are defined.

First we need to learn about inheriting. It means that you do not have to re-write all the code already existing in some other class, you can just inherit from existing classes. Here is basic example how we define the M16A2 class so our config can use its contents.
<code cpp>
class M16A2;
</code>
Very very simple.

The class <SOMETHING>; means that SOMETHING is now defined/declared and available in our config. When we would inherit from the SOMETHING class, it would go like this:
<code cpp>
class TAG_MyNewM16: M16A2
{
        displayName = "My New M16";
};
</code>
That code would create new weapon called "TAG_MyNewM16" and its name would be "My New M16" in-game.

Okay so lets start to replace some sounds.

First like said we declare the M16A2 but we also need the inheriting M16_base class too, then we start to modify its values. It goes like this:
<code cpp>
        class M16_base;

	class M16A2 : M16_base
	{
		class Single : Mode_SemiAuto
		{
			begin1[] = {"tag\tag_mysounds\m16_single1.wss", 1.77828, 1, 1000};
			begin2[] = {"tag\tag_mysounds\m16_single2.wss", 1.77828, 1, 1000};
			soundBegin[] = {"begin1", 0.5, "begin2", 0.5};
		};

		class Burst : Mode_Burst
		{
			begin1[] = {"tag\tag_mysounds\m16_single1.wss", 1.77828, 1, 1000};
			begin2[] = {"tag\tag_mysounds\m16_single2.wss", 1.77828, 1, 1000};
			soundBegin[] = {"begin1", 0.5, "begin2", 0.5};
			soundBurst = 0;
		};

		class FullAuto : Mode_FullAuto
		{
			begin1[] = {"tag\tag_mysounds\m16_single1.wss", 1.77828, 1, 1000};
			begin2[] = {"tag\tag_mysounds\m16_single2.wss", 1.77828, 1, 1000};
			soundBegin[] = {"begin1", 0.5, "begin2", 0.5};
		};
	};
</code>
Wow, few lines :)

Okay the class Single, Burst and FullAuto are the firing mode classes, ie how is your weapon firing models setup. In this case its self explanatory how they are setup. The config allows us to give individual sounds for each firing mode.

The sounds are defined in the begin1[] and begin2[] lines. As you can see from the example we are using tag\tag_mysounds\ directory structure as path to our sound m16_single1.wss and m16_single2.wss files.

The soundBegin[] part is which tells what sound values to play (or something like that, we are not sure exactly heh).


====== Fully Working Config ======

This is fully working config which you can drop into "PMC_MySounds" dir in config.cpp file, put in "m16_fire.wss" sound file in the root and binarize, this works, its tested. Its all good baby :)

<code cpp>

class CfgPatches
{
	class PMC_MySounds
	{
		units[] = {};
		weapons[] = {};
		requiredVersion = 1;
		requiredAddons[] = { "CAWeapons" };
	};
};

class Mode_SemiAuto;
class Mode_Burst;
class Mode_FullAuto;

class cfgWeapons
{
        class M16_base;

	class M16A2 : M16_base
	{
		class Single : Mode_SemiAuto
		{
			begin1[] = {"pmc\pmc_mysounds\m16_fire.wss", 1.77828, 1, 1000};
			begin2[] = {"pmc\pmc_mysounds\m16_fire.wss", 1.77828, 1, 1000};
			soundBegin[] = {"begin1", 0.5, "begin2", 0.5};
		};
		
		class Burst : Mode_Burst
		{
			begin1[] = {"pmc\pmc_mysounds\m16_fire.wss", 1.77828, 1, 1000};
			begin2[] = {"pmc\pmc_mysounds\m16_fire.wss", 1.77828, 1, 1000};
			soundBegin[] = {"begin1", 0.5, "begin2", 0.5};
			soundBurst = 0;
		};
		
		class FullAuto : Mode_FullAuto
		{
			begin1[] = {"pmc\pmc_mysounds\m16_fire.wss", 1.77828, 1, 1000};
			begin2[] = {"pmc\pmc_mysounds\m16_fire.wss", 1.77828, 1, 1000};
			soundBegin[] = {"begin1", 0.5, "begin2", 0.5};
		};
	};
};
</code>


====== WSS files ======

It doesn't really matter where you place the sound WSS files, they can be in the root of the addon or in sounds\ directory or similar dir.

You might be good idea to create good file names for the sounds so they are organized and easily recognized. Example of a bad sound file naming would be "shot.wss" or "gun.wss", but good ones might be "M16A4_fire.wss" and "M16A4_reload.wss" file names.

Also note that the initial characters upper or lower case makes the order when listed in explorer, so it would be good idea to name all sounds like "Sound.wss" instead of "sound.wss", makes much more easier to sort the files. Careful reader notices that our config actually says "m16_fire.wss", but that's just because in config it doesn't matter which case it is, but in file name sorting it does. We believe that config.cpp is more beautified when path + file names are in lower case, but its totally up to you how you write them.


====== Binarize ======

Use BinPBO to binarize and pack the addon. Synide's build environment guide helps you to setup BinPBO properly. When done, point the source dir into your development addon dir and destination dir into your game addon dir (but NOT the "<arma2root>\Addons" dir!).

Just press Pack button and its done. Binarize will display error message if there is any errors in the config. It creates TAG_MySounds.log file into the destination dir, so if you have errors, check this .log file out.


====== Test In-game ======

Nothing else left to do except to test in-game.

To do this, make sure you know which mod directory did you pack the addon, then launch game with the -mod= parameter to point into this directory.

Fire up a test mission and listen how your sounds are playing out :)

If there are problems, remember to check your [[arma2:arma2.rpt|RPT]] file for error logs.

See also [[arma2:config:vehicle-sound-tutorial|vehicle sound tutorial]]