User talk:X39

Rewrite of Debugging_Techniques

---

How to begin

For starters, debugging is most of the time literally as complicated as writing the actual code itself. You usually get hinted by the game, where your error happened, and what it was. The first thing you do thus, is allowing the game to display script errors (For Arma 3, you do this in the Launcher or by setting the corresponding -showScriptErrors flag).

Afterwards, every script error should greet you with this box: --PLACEHOLDER FOR IMAGE--

It tells you what went wrong, shows a snippet of the code that failed and, unless you used a command combination like eg. `compile loadFile`, what file and line it occured on.

This now allows you to actually continue to debug as you know where to start.

This info can also be found in the RTP log

RPT files

RPT files are the location where debug information is dumped to both by the Arma game and by any scripts that are running. For scripts which are running on a server, generally the file used is Arma2OAServer.RPT which has varying locations depending upon the type of server being run. For scripts which are running on a client, the Arma2.RPT or Arma2OA.RPT file will contain debug related information. The default locations for these files may vary, but should be based in the AppData folder in Windows 7 (C:\Users\User\AppData\Local\<Game Name>\).

Actual Techniques

Using no tools

The most simple thing you can do, is to add output. This can be done, using for example diag_log. Output yourself a few variables that relate to your problem (for example: When the error occurs because you land in some if block, output the corresponding variables inside of the if). You continue doing this until you hit the actual problem: When variable A is not set, go to where variable A gets set and check around there, repeat and continue.

The same can be done for non-critical errors like when a method is "just" computing the wrong values.

Using Tools

Debug consoles

Like in other games, several debug consoles are available which have been developed by community members, to either display or list useful information, display or analyse bugs within code, to allow code execution, or a variety of these functions. They usually contain a way to display variables which allows for simpler debugging sessions.

Arma: Cold War Assault	Vektorboson released a debugging console for advanced users that is very helpful at debugging your scripting in real time.
Arma: Armed Assault	Debug console made by Str. It's in form of addon and it's available in all singleplayer missions, intros and outros. Easy and simple to use (Escape-Enter execute). TroopMon V 0.7 *Mission debugger - Complex debugging system providing lot of informations for mission-makers, escpecially about AI.
Arma 2	Debug console by Str TroopMon2 by Charon Productions DevCon by Kju If you're at an advanced stage of a project, you can save the game when the bug appears and check the variable and script states with Chain of Command's Binary gamefile viewer.
Take On Helicopters	The game already features Debug Console in basic installation.
Arma 3	The game already features Debug Console in basic installation.

---

---

---

Old Stuff

---

---

---

General debugging techniques

Addons

If you're working with an existing addon, or are developing one, repacking a PBO can be time-intensive, and can be replaced simply by creating a basic mission in the "Missions" or "MPmissions" (if your feature is multiplayer-specific) folder of your game installation, and then running the scenario or mission locally. The easiest way of accomplishing this is by the use of Event Scripts to run your code such as init.sqf. Once you have tested your code, using missions in this way, you can then sequentially pack your PBO when major changes have been made, rather than for each debug session of a script or piece of code.

Syntax checking and highlighting

Syntax errors can be a frequent occurrence when developing scripts. There are several methods of determining if the syntax is correct before running scripts; squint provides a fully-featured code editor which allows for syntax highlighting, displaying of errors and code correction. A simpler solution of code highlighting for Notepad++ is also available here, although errors will only be visible from the absence of highlighting. Using SQDev you will get code validation (linting) while you are typing it. The plugin will automatically check if you are using all commands with the proper syntax and with proper argument types.

Debugging specific sections of code

Although primitive, the use of diag_log and format can be used to debug the content of variables when entering them into functions. In the case that specific pieces of code do not run, or if specific if conditions don't appear to fire, debugging the contents of that specific variable with diag_log can be useful. As with all debugging, so long as the developer is methodical and logical in checking each section of code that runs, finding bugs and resolving them can be straightforward.

Keep it simple

If you're having great difficulty solving a problem, simplify the problem, take the part of the mission which does not work, paste it into a new test mission so that you don't have to watch the effect of the rest of the script(s).