ArmA 1 Forum, ArmA 1 Home, ArmA 1 Config, ArmA 1 Tools, ArmA 1 File Formats, ArmA 1 Missions, ArmA 1 3D Modeling, ArmA 1 Terrain, ArmA 1 Texturing, ArmA 1 Scripting

ArmA 1 aka Armed Assault (ArmA)

This guide assumes you have read the How to be mod maker article first and fully understand the complexity of starting a addon / mod making.

This is basic backbone of good addon editing or “modding”. If you follow these guidelines, you don't have to be scared of getting bad reputation in the editing community by putting out bad or lame releases.

It is essential that you combine this how to MOD with how to release article. This page you're reading now only concentrates on editing the addon, while the other walks your through how to release the completed addon.

Keep organized. Write a lot of notes to yourself.

Unless you are a superhuman, you need documentation to remember all the fine details of your addon editing project.

Keep the document text file in a central specific location where you always find it. Personally here at PMC we use documentation directory structure like:

ArmA.edit/Documents/

ArmA2.edit/Documents/

OFP.edit/Documents/

Falcon4.Theaters/Documents/

As you can see its organized to <GAMETITLE>/Documents/ directory system. Each and every piece of text file (we prefer text files as they are light weight, easy to read and search) will be put on this directory, important ones used daily will be linked to windows desktop so you can open the text file just by clicking its icon in desktop.

You need to write a documentation at least for: bug list, fixes list (call it changelog), then anything that is work in progress so that if you suddenly have to be away from your computer for day or two (or gosh, more), you definitely can jump right in as you can see what was it that you were working on.

No we don't mean that you document everything, but a basic thing that “Addon XYZ porting, textures merged up until alphabet M, model cleaned up but memory LOD is unfinished), etc something like this. Believe me, when you come back from (sudden) holiday or timeout, you will appreciate your little reminder text file(s).

Good set of tools are important for any mod maker.

We could start by saying that be smart, for example do not use notepad or wordpad to edit text (.hpp, cpp, .cfg, .sqs, .sqf and .sqm etc) files, instead use some advanced text editor (see list from editing tools page.

Being smart means that if you have several hundred classnames to replace on text files in several dirs, do not do this manually, instead use tool like UltraEdit or PowerGREP to do it automatically for you. To merge textures, no way you can do it manually, use PanTool/O2 or Synides method, etc, you get the idea.

You should not use MS Paint for image editing, instead get some professional image editing utility like Photoshop or GIMP for example.

BIS development tools include the TexView2 for textures, Oxygen 2 Personal Edition for p3d modeling, Visitor 3 for terrain editing and finally BinPBO for packaging your finished addon into a ArmA readable PBO file.

Do not ever release “aircraft.pbo”, instead use yours / groups tag, like “tag_aircraft.pbo” style.

This includes filenames inside the released addon pbo, for example, do not have “hangar.p3d” in your models because such file name can conflict with ca\*\* addons made by BIS which are read by default in ArmA. Always make unique file names using your own tag_ in front of the rest of the file name.

Practical example is AGS port OFP porting, there was “hangar.p3d” file which caused serious conflict with ca\data\hangar.p3d not found error from ArmA. The AGS hangar.p3d had to be renamed to “AGS_hangar.p3d” to fix this issue. So always use TAG_ stuff even in your file names (not including texture file names though).

Config file is what makes your addon work. It is very important part of your addon, in some cases its the only thing that makes “addon”.

Choosing classnames is difficult decision. BIS uses just SoldierWB for:

• soldier
• west
• basic

You can choose what ever you like, just TAG_MyClassName, but you should try to keep them organized somehow, even that regular mission editors would learn how to use them. Like “TAG_ins_rfl” would be TAG Insurgent Rifleman and “TAG_ins_mg” would be TAG Insurgent Machinegunner, etc.

Model Config

Basically model.cfg is a file which you place in your addon directory (with p3d models), this file contains basically two classes “CfgSkeletons” and “CfgModels”.

Do not ever put CfgSkeletons and CfgModels into your config.cpp!

You must make sure those go into model.cfg where they belong. Your addon works only partially if you keep them in config.cpp, for example you cannot see any animations in buldozer without proper model.cfg file.

While the ArmA engine will interpret the cpp file no matter how ugly it looks, its common sense to write it with proper intend and nice layout with editor like EditPadPro for example.

Bad example of code

class DestructionEffects2 {
 
 
class DestroyPhase1
		{
	simulation ="destroy";
				type= \ca\buildings\ruins\leseni4x_ruins;
			position="";
				intensity =1.0000;interval= 1.0000;
			lifeTime=1.0000;
		    };	};

Same code with proper intend etc

class DestructionEffects2
{
	class DestroyPhase1
	{
		simulation = "destroy";
		type = "\ca\buildings\ruins\leseni4x_ruins.p3d";
		position = "";
		intensity = 1;
		interval = 1;
		lifeTime = 1;
	};
};

There is no tool to automatically indent your code (released by ArmA community), only way to do that is by binarize your config.cpp and then use unRap for the config.bin to unrap it back to cpp format. But this is not ideal method of doing it, best would be if you indent your config.cpp from the ground up at start, as you lose all comments and other formatting with unRap. Of course unRap does good job, it sticks with the basic indent methodically.

Please name your addon properly, you can find it in this section of config:

class CfgPatches
{
	class test_model
	{
		units[] = {};
		weapons[] = {};
		requiredVersion = 1.16;
		requiredAddons[] = {};
	};
};

As you can see in our code example, its named “test_model”, this is the name string that appears in mission.sqm files required addons array. So please make sure the name has some meaning and it will be easy to locate and so on.

If you fail to properly name your addon, it can lead into multiplayer conflicts for example.

You must specify the required addons that your addon will be using, otherwise you get all sorts of errors ingame and in mission.sqm files. Here is one example of required addons line:

requiredAddons[] = { "CACharacters", "CAWeapons", "Extended_EventHandlers" };

Remember that you must list each and every addon that is referenced from your addon, this is very important.

Sound files can be read by the engine in WAV, OGG or WSS format. You should always make your ArmA (and OFP) sound files in WSS format (only exception is music tracks which are okay in ogg format).

If you would prioritize the sound format usage, then WAV is the worst, please do not ever use them in your addon/mission.

Please use Extended Eventhandlers (XEH) support so your addon is fully compatible with various other user addons out there.

For ArmA you must only write SQF scripts, do not add anymore SQS scripts as that is the old “format” of scripting.

Porting OFP SQS script “spaghetti” as Killswitch likes to call it, can be tedious if not even impossible for many of us. But don't be alarmed, it can be done with proper help. Ask around in the forums and surely there is someone willing to help you port even the nastiest SQS script to SQF.

When you model, there are few necessary properties you must ensure are OK in your model.

• All additional resolution LODs should get 50% reduction on polygons.
• Last resolution LOD should be 100 or less polygons.
• Use merged textures and as few “sections” as possible.
• Do not use “cart board” low poly LOD, instead use real low poly model.

When you have made sure these properties are OK in your model, then you should have very good basic model done.

Examples on the lower resolution LODs are quite simple, you should drop your LOD 50% points on each new LOD. Like this:

Note that 8 LOD's is quite a lot, you could go straight to 74 for example from the 6.0 LOD as there is so little difference (48 points, quite nothing). Its also said that you can drop even more than 50% if your model maintains its shape, so use your best judgment… if the model looks the same, drop some more details…

Never ever skip doing proper lower resolution LOD's or your model / mod starts to cause performance problems!

Definitely try to avoid large number of sections. Read our section fixing tutorial how to reduce sections. Always end your model with only one (1) section. If you have proxies in your model, those wont count, but you must only have one texture in your last LOD for best performance.

You should always merge your textures if porting OFP addon, or if you create totally new content, just use one texture where ever possible. Your main texture filename must end to _CO, like “PMC_Abrams_co.paa” filename. You don't necessarily need to use the tag in texture filenames, in fact you can categorize your textures better when they start with the vehicle or classname.

Use TexView2 to save your texture files to the _CO or _NOHQ etc file names, its been said that other programs do not properly save the correct texture format as Texview2 does. Always use Texview2 for final texture saving.

Create normal map to your main texture. This is the _NOHQ ending texture.

Create specular map to your main texture. This is the _SMDI ending texture.

Finally you must create RVMAT file to use the normal/specular maps properly.

First of all, do not never ever use spaces in file names.

Do not use non English names in file names, for example do not make Spanish or German named addon pbo's, stick with English.

Please give your files a file name which itself describes what they are all about. Do not make “wing.paa” texture, instead put in like ”<plane>_wing_left.paa“ so it can be identified and sorted immediately.

Do not make “READ ME.txt”, but instead do ”<addonname>_readme.txt“ which can be affiliated with your addon. Imagine user unpacking your release archive into ArmA dir, how many “readme.txt” files do you think there are already? Yes, you need to affiliate your readme with YOUR addon. You should even add version numbering like ”<addonname>_readme_v<version>.txt“ which might be “PMC_apache_readme_v1.0.txt” for example.

Name your p3d filenames with categories and organized style, NO catshitone Afghanistan style!

Consider choosing prefixes for your filenames, like TAG_Tree_Type and TAG_House_Type, etc so they are more easier to find in great numbers. Always avoid the non English file names, do you really want to go back to the old BIS file Czech file naming? :)

Clean out each and every directory of your addon package for any leftover unused temporary files. Do not leave any files in there which aren't used by your addon.

Very good example is Visitor 3 terrains, when it converts the satellite textures it leaves the PNG files in the dir, now many times people just pack/binarize up their terrain leaving these excessive png files in the pbo causing it to grow maybe twice in size. This is totally unacceptable.

Also many times you don't see the “Thumbs.db” file in several directories where there have been some image editing/viewing going on. To see this you have to choose show hidden files from win explorer, or happen to stumble on it inside the already made RAR packet or something. It is very important to remove this unnecessary file also.

When you binarize your addon, it will not copy .png, .tga or .bmp files for example, so that alone helps you out, however you should always keep your dev dir clean as it would be the addon in ArmA mod dir. You should store the development files like Photoshop PSD layered image files safe somewhere else.

Always binarize your addon. This helps you to seek out any errors / bugs in your addon. Use BinPBO to binarize, then look at the dir where the pbo was copied and you'll see LOG file in there, read this log file to sort out any remaining issues with your addon. Much of the log can be compared with arma.rpt file as the errors are identical many times.

Even a great addon maker cannot necessarily maker a addon with no errors in the log file, so please don't be intimidated by the log and spend too much time cleaning out the errors/lines in it. In time you will learn which error you must fix and which you can just ignore. Good rule of thumb is that warning you can ignore but error you must fix.

Read our Binarize tutorial to better understand binarize and its use.

Very good debugging method is to make a test mission where you place ALL your addon units/vehicles/weapons into play at one time. One unit of each type is only required. Then make them all playable so you can use teamswitch to switch between the units and then just fire up the mission and surely if there is any errors they will came up right away. You'll find smaller errors and places for tweak when you browse around the teamswitch through the available units. After a few minutes of browsing the units, exit ArmA and look arma.rpt file for warnings and errors which you can start to fix.

Always only test your addon against BIS default stuff, do not use other peoples addons with yours as you cannot be 100% sure they wont cause any problems or false readings in arma.rpt file.

Multiplayer (MP) testing is important, especially if your addon is “advanced” with some scripting features and weird stuff, however if you are a one man show its bit difficult to test. The best you can do is to launch a server from your own computer and try it there, that MIGHT bring up some problems but most likely it wont be nearly as good testing platform as real dedicated server. Sometimes such MP testing is impossible and you are left helpless to just wish there is no such errors.

createVehicle command is also important to check with your units as sometimes there can be some problems using the scripted method to create your units. Many missions in current mission making scene use createUnit / createVehicle so having your addon fully compatible (bug free) regarding this method is a must.

Make sure you read How to release article too so your time spent editing wont be wasted with a bad release.