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.
/* 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 */
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:
Expected way how to call the function is by correctly defining all arguments:
However, the function will break down when tried with only one argument:
Furthermore, using wrong data type will also lead to a problem:
Variable _target expects position array in format [x,y,z]. Scripting error will appear when a different number of elements is used:
As shown there, the most common problems are:
- Param of wrong data type is sent
- Param is missing
- 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:
- _target is undefined. Default [0, 0, 0] is used instead. No error message is logged.
- _unit is undefined (nil is passed instead). Default objNull is used instead. No error message is logged.
- _target has wrong type. Default [0, 0, 0] is used instead. Error message is logged.
- _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.
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.
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:
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:
"User1/log: ERROR: [BIS_fnc_respawnTickets] #0: 0 is type SCALAR, must be NAMESPACE, SIDE, GROUP, OBJECT, BOOL. true used instead."
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.
"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;
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.
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)