Arma 3: Writing a Function

The most important thing to remember when writing a function is that other people are going to use it. Most of them won't understand how it works, expecting it to do its job without problems.

The function must be robust. It should not allow passing arguments of incorrect Data Types in. When some values are incorrect, it should throw an error explaining what went wrong and how to fix it. And above all, its header must provide complete explanation of usage.

⚠

What is not documented does not exist!

Header

Template

Example

/* Author: <author nickname> Description: <function description> Parameter(s): 0: can be one of: <type> - <description> <type> - <description> 1: <type> - (Optional, default <default value>) <description> Returns: <return type> Examples: <example> */

/* Author: Karel Moricky Description: Ends mission with specific ending. Parameter(s): 0: can be one of: STRING - (Optional, default "end1") end name ARRAY in format [endName, ID] - will be assembled as "endName_ID" string 1: BOOLEAN - (Optional, default true) true to end mission, false to fail mission 2: (Optional, default true) can be one of: BOOLEAN - true for signature closing shot (default: true) NUMBER - duration of a simple fade out to black Returns: BOOLEAN Example: [] call BIS_fnc_endMission */

Taking Arguments

Arguments are the only way to interact with a function. Let's now see how to make sure they are loaded properly.

Here is this very simple function which will let a unit watch a position:

params ["_unit", "_target"]; _unit doWatch _target;

Expected way how to call the function is by correctly defining all arguments:

[player, getPosASL myCar] call TAG_fnc_myFunction;

However, the function will break down when tried with only one argument:

[player] call TAG_fnc_myFunction;

Furthermore, using wrong data type will also lead to a problem:

[player, 0] call TAG_fnc_myFunction;

Variable _target expects position array in format [x,y,z]. Scripting error will appear when a different number of elements is used:

[player, [1, 2, 3, 4]] call TAG_fnc_myFunction;

As shown there, the most common problems are:

1. Param of wrong data type is sent
2. Param is missing
3. Param is an array expecting specific number of elements, but different number is sent

Rather than check for all these exceptions manually, it is more than advised to use the param command:

_unit = param [0, objNull, [objNull]];

For multiple parameters, use the params command instead.

params [
	["_unit", objNull, [objNull]],
	["_target", [0, 0, 0], [[], objNull], [2, 3]]
];
_unit doWatch _target;

• In a params array first argument is the name of the private variable. In param it is the index number.
• Second argument is the default value. It will be used when the argument is missing, is nil or when wrong data type is used.
• Next is optional array of compatible data types. They are defined by an example of the type, e.g. objNull will mean an object is allowed. When wrong data type is sent into the function, param will log an error message explaining what went wrong and use the default value.
• The last, also optional argument is an array of required array sizes. [2,3] means only array with 2 or 3 elements are allowed. When incorrectly large array is sent into the function, param will log an error message explaining what went wrong and use the default value.

Let's see what happens with wrong examples now:

[player] call TAG_fnc_myFunction;

_target is undefined. Default [0, 0, 0] is used instead. No error message is logged.

[nil, getPosASL myCar] call TAG_fnc_myFunction;

_unit is undefined (nil is passed instead). Default objNull is used instead. No error message is logged.

[player, 0] call TAG_fnc_myFunction;

_target has wrong type. Default [0, 0, 0] is used instead. Error message is logged.

[player, [1, 2, 3, 4]] call TAG_fnc_myFunction;

_target has wrong size. Default [0, 0, 0] is used instead. Error message is logged.

Additionally, when only one argument is used, it can be sent into the function directly without the need to have it in an array.

player call TAG_fnc_myFunction;

Returning Value

A function can return a result (object reference, script handle, etc) that can then be saved by the user. If no value is returned, the variable would be nil and could lead to script errors.

_myVar = [player, getPosASL myCar] call TAG_fnc_myFunction;

It is a good practice to always return a value, even if it would be a simple true marking the function as completed. Let's use the example function from above:

params [ ["_unit", objNull, [objNull]], ["_target", [0, 0, 0], [[], objNull], [2, 3]] ]; _unit doWatch _target; true;

ⓘ

Note that a spawned function will always return a Script Handle, as per spawn command's behaviour.

Showing Errors

While param and params can filter out the most common issues, the function will sometimes have special rules which will need to be handled. Let's return back to the example function, where we would want to terminate the function with error when _unit is dead:

params [["_unit", objNull, [objNull]], ["_target", [0, 0, 0], [[], objNull], [2, 3]]]; if (!alive _unit) exitWith { ["Unit %1 must be alive.", _unit] call BIS_fnc_error; false; }; _unit doWatch _target; true;

Notice that we're returning false at the end of exitWith code.

⚠

Error states must always return value of the same type as when everything is fine (Boolean in this case).

BIS_fnc_error accepts String and Array of formatted ext. The error is logged into RPT and if the mission is previewd from the editor, it will also appear on screen.

RPT	"User1/log: ERROR: [BIS_fnc_respawnTickets] #0: 0 is type SCALAR, must be NAMESPACE, SIDE, GROUP, OBJECT, BOOL. true used instead."
In-game

Logging

Apart from errors, it is possible to print any needed debug message. Use one of the following functions:

• BIS_fnc_log - log a data of any type (e.g., String, Number, Object, ...)
• BIS_fnc_logFormat - log formatted text

Profile name and function name will automatically appear in the output text, to help identifying the source.

Usage examples:

Expression	RPT Output
"Hello World" call BIS_fnc_log;	"User1/BIS_fnc_log: [TAG_fnc_myFunction] Hello World"
42 call BIS_fnc_log;	"User1/BIS_fnc_log: [TAG_fnc_myFunction] 42"
["I'm playing %1", missionName] call BIS_fnc_logFormat;	"User1/BIS_fnc_log: [TAG_fnc_myFunction] I'm playing FalconWing"

To prevent RPT spam, logging is by default enabled only when previewing a mission from the editor. To force it in the mission everywhere, use the following Description.ext attribute:

allowFunctionsLog = 1;

Recompiling

Once compiled, functions remain unchanged and editing their file won't have any effect in the game. To adjust functions on the fly, their recompilation can be manually triggered - see Arma 3: Functions Viewer and BIS_fnc_recompile.

Meta Variables

System is adding header with basic meta data to all functions. Following local variables are declared there:

• _fnc_scriptName: String - Function name (e.g., TAG_fnc_myFunction)
• _fnc_scriptNameParent: String - Name of q function from which the current one was called (_fnc_scriptName used when not defined)

⚠

Do not modify these values!

See Also

• Arma 3: Functions Library
• Arma 2: Functions Library
• Take On Helicopters: Functions Library