User Tools

Site Tools


Bug Hunting Tutorial

Bug Hunting Tutorial

If your addon doesn't work, here is the basic principles of how to check all the possible reasons.

Check config.cpp for errors

Check config.cpp for errors. You can do this by


Indent means that you should always indent your code, always. You are never too hurry to write a code without indent, there is no single reason in this planet why would you need to skip indenting. When the code is properly indented, you can spot missing { }; lines immediately, this is the first method to spot errors.


Mikero's Rapify tool is unforgiving when it comes to errors. It is more thorough for errors than Binarize or ArmA 2 engine itself, if rapify gives your all OK, then you're good config wise.


Uncrustify is 3rd party tool for ArmA 2 editing, it has nothing to do with it or our community, it is C/C++ tool basically. Run your config through uncrustify and it will notify you about errors and also indents it automatically.


Squint will check your config for errors, it also highlights it for nice viewing.

BinPBO / Binarize

BinPBO / Binarize will take your config, process it and binarizes it for in-game use. As said rapify is more tougher than binarize, there is some errors which binarize and ArmA 2 engine itself will ignore, but still, binarize is quite decent to check your config for errors. When you get binpbo / binarize error, it only says “error” so you have to look into the destination directory for <addon>.log file which is the RPT file from binarize, any errors are located there.

Binarize crashes if it tries to binarize ODOL p3d or wrong version of OPRW WRP format files. You cannot mix MLOD p3d and ODOL p3d files in your addon, which sometimes would be the case of not getting permissions or similar situations, then you just have to make additional pbo for the ODOL models, which you only “Pack” and not binarize.

Check RPT for errors

All the above methods with binarize, rapify and others doesn't necessarily fix all the errors, sometimes you have to get the final error(s) from arma2.exe itself by reading arma2.rpt file.

Error like the following doesn't cause any harm regarding your addon showing up in-game:

Updating base class <class>-><class>, by <addon>\config.cpp/Cfg<something>/<class>/

But if there is error like:

Cannot Open Model <something>

Then you do have a problem. Look for anything related to your <addon> name.

O2 for Missing Textures

To check missing textures in O2, you need to load up the model in question (this can be a problem if you have 100's of models) and do Tools → Mass Texture & Material Renaming… feature. It shows you all missing textures in RED color. Please take a note that if you have changed the textures into .TGA as many of us do, then those as well are shown in red if they aren't there but the actual .PAA file is, heh kind of tricky.

Remember that O2 only checks the _CO main diffuse textures, not what its written in your RVMAT files, more of them below.

RVMAT's for missing textures

To check RVMAT missing textures, most likely _NOHQ and _SMDI, there is no other way than to run O2 with buldozer or arma2.exe itself, which gives you error on the screen with missing texture path + file name, this is also written in RPT file even in buldozer (check buldozer's RPT from the same dir the exe is located). Well of course you could manually check the RVMAT's in text editor and scan your addon dir for the texture, but its much quicker to run it through buldozer/arma2.exe.

arma2/bug_hunting_tutorial.txt · Last modified: 2011-07-01 07:34 (external edit)