{"name":"Arma 3: CfgDisabledCommands","title":"Arma 3: CfgDisabledCommands","type":"topic","url":"https://community.bistudio.com/wiki/Arma_3:_CfgDisabledCommands","revid":378044,"updated":"2026-01-27T20:21:42Z","aliases":["Arma 3 CfgDisabledCommands","CfgDisabledCommands"],"markdown":"Arma 3 v1.66 The **CfgDisabledCommands** is a Description.ext class which allows to disable selected scripting commands in a mission.\n\n> [!IMPORTANT]\n> It is a powerful tool and can **make or break** your game, since some of the default in-game mechanics also uses scripting.\n> The use of CfgDisabledCommands feature requires advanced knowledge of scripting and should not be attempted unless the mission maker is confident in his abilities and is aware of potential dangers.\n\n### Motivation\n\nThis powerful feature was developed in an attempt to give mission maker a tool, which allows him to increase security of multiplayer missions against possible hacking and exploits.\nMany mission makers choose to move important code to server side, however some script commands left on client side may prove it difficult to achieve desired security goal.\nDisabling them altogether while mission is running could be the answer to some of the common issues.\n\n### Mechanics\n\nCommands listed in `CfgDisabledCommands` are disabled on mission start.\nThis means that they are fully available in pre-init phase, therefore allowing mission maker to initialise the mission properly.\nCommands could be disabled on server, clients and HCs separately, giving even more flexibility to mission maker.\n\n> [!NOTE]\n> If the command is disabled on client:\n>\n> - **In singleplayer:** using `Local Exec` in debug console throws a `Generic error in expression`.\n> - **In multiplayer:** if the command is remote executed from the server (or a headless client), the command executes normally. Using `Local Exec` makes the command run normally, since it uses remoteExec to call the script.\n\nAny attempt of using disabled command after mission start will result in error message in .rpt file, while command itself will be ignored as if it didn't exist.\nThe disabling is final and cannot be overridden during mission.\nSome commands have alternative syntaxes, therefore in order to disable command, the desired syntax has to be indicated (about this later).\n\n> [!IMPORTANT]\n> `CfgDisabledCommands` impacts both Singleplayer **and** Multiplayer. In Singleplayer, the **client** setting is used.\n\n### Indication\n\nIf the mission config contains `CfgDisabledCommands` class and it is not empty, the warning icon will be shown on the title bar of the debug console:\n\n### Structure\n\nHere is an example config, which disables createUnit, the one with remote exec ability, and createVehicleLocal on clients:\n\n```cpp\nclass CfgDisabledCommands\n{\n    class CREATEUNIT\n    {\n        class SYNTAX1\n        {\n            targets[] = { 1, 0, 1 };\n            args[] = { { \"STRING\" }, { \"ARRAY\" } };\n        };\n    };\n\n    class CREATEVEHICLELOCAL\n    {\n        class SYNTAX1\n        {\n            targets[] = { 1, 0, 1 };\n            args[] = { { \"STRING\" }, { \"ARRAY\" } };\n        };\n    };\n};\n```\n\nAs you can see, the structure consists of definition of commands (CREATEUNIT, CREATEVEHICLELOCAL), definition of syntax (args[]) and target locality (targets[]):\n\n- **targets[]** - the format is `{ enableServer, enableClient ,enableHC }`. 1 means enable, 0 means disable. From the above example `targets[] = { 1, 0, 1 };` means: enable server, disable client, enable HC.\n- **args[]** - (Optional) the format is **{{leftArgumentType},{rightArgumentType}}**. The information about argument types could be retrieved with supportInfo command.\n\n#### CfgDisabledCommands Utility (Arma 3 v1.68)\n\nCfgDisabledCommand Utility can be used to generate CfgDisabledCommands template.\nIn order to do so, open debug console and type `utils 1` then click on LOCAL EXEC:\n\n### Selecting Correct Syntax\n\nWhile createVehicleLocal has only 1 syntax, createUnit has 2 syntaxes:\n\n```cpp\n// ...\nclass CREATEUNIT\n{\n    class SYNTAX1\n    {\n        targets[] = { 1, 1, 1 };\n        args[] = { { \"STRING\" }, { \"ARRAY\" } };\n    };\n\n    class SYNTAX2\n    {\n        targets[] = { 1, 1, 1 };\n        args[] = { { \"GROUP\" }, { \"ARRAY\" } };\n    };\n};\n// ...\n```\n\nFrom the createUnit command page it is obvious that `args[] = { { \"STRING\" }, { \"ARRAY\" } };` is the syntax we want to keep as it is the syntax we want to disable since it allows for passed code to be remote executed everywhere, and thus presenting a security issue, so we leave it and delete the other syntax which is harmless in comparison.\nFor other commands also refer to the respectful command pages. For example, setViewDistance:\n\n```cpp\nclass CfgDisabledCommands\n{\n    class SETVIEWDISTANCE\n    {\n        class SYNTAX1\n        {\n            targets[] = { 1, 1, 1 };\n            args[] = { {}, { \"SCALAR\" } };\n        };\n    };\n};\n```\n\nNote that the command doesn't have left argument, so it is simply replaced with `{}`.\nAfter the correct syntax is selected and other syntaxes are removed, the targets could be configured according to mission design (by default enabled everywhere).\n\nIf a command doesn't have left arguments, or right arguments the correct syntax is:\n\n```cpp\nclass CfgDisabledCommands\n{\n    class ALLPLAYERS\n    {\n        targets[] = { 1, 1, 1 };\n    };\n};\n```\n\n### Reminder\n\nOnce again, consider carefully what commands you want to disable and verify that disabling is not interfering with default functionality of the game.\nDon't forget to check .rpt file to avoid any confusion in the future.","sections":[{"heading":null,"level":1,"markdown":"Arma 3 v1.66 The **CfgDisabledCommands** is a Description.ext class which allows to disable selected scripting commands in a mission.\n\n> [!IMPORTANT]\n> It is a powerful tool and can **make or break** your game, since some of the default in-game mechanics also uses scripting.\n> The use of CfgDisabledCommands feature requires advanced knowledge of scripting and should not be attempted unless the mission maker is confident in his abilities and is aware of potential dangers."},{"heading":"Motivation","level":3,"markdown":"This powerful feature was developed in an attempt to give mission maker a tool, which allows him to increase security of multiplayer missions against possible hacking and exploits.\nMany mission makers choose to move important code to server side, however some script commands left on client side may prove it difficult to achieve desired security goal.\nDisabling them altogether while mission is running could be the answer to some of the common issues."},{"heading":"Mechanics","level":3,"markdown":"Commands listed in `CfgDisabledCommands` are disabled on mission start.\nThis means that they are fully available in pre-init phase, therefore allowing mission maker to initialise the mission properly.\nCommands could be disabled on server, clients and HCs separately, giving even more flexibility to mission maker.\n\n> [!NOTE]\n> If the command is disabled on client:\n>\n> - **In singleplayer:** using `Local Exec` in debug console throws a `Generic error in expression`.\n> - **In multiplayer:** if the command is remote executed from the server (or a headless client), the command executes normally. Using `Local Exec` makes the command run normally, since it uses remoteExec to call the script.\n\nAny attempt of using disabled command after mission start will result in error message in .rpt file, while command itself will be ignored as if it didn't exist.\nThe disabling is final and cannot be overridden during mission.\nSome commands have alternative syntaxes, therefore in order to disable command, the desired syntax has to be indicated (about this later).\n\n> [!IMPORTANT]\n> `CfgDisabledCommands` impacts both Singleplayer **and** Multiplayer. In Singleplayer, the **client** setting is used."},{"heading":"Indication","level":3,"markdown":"If the mission config contains `CfgDisabledCommands` class and it is not empty, the warning icon will be shown on the title bar of the debug console:"},{"heading":"Structure","level":3,"markdown":"Here is an example config, which disables createUnit, the one with remote exec ability, and createVehicleLocal on clients:\n\n```cpp\nclass CfgDisabledCommands\n{\n    class CREATEUNIT\n    {\n        class SYNTAX1\n        {\n            targets[] = { 1, 0, 1 };\n            args[] = { { \"STRING\" }, { \"ARRAY\" } };\n        };\n    };\n\n    class CREATEVEHICLELOCAL\n    {\n        class SYNTAX1\n        {\n            targets[] = { 1, 0, 1 };\n            args[] = { { \"STRING\" }, { \"ARRAY\" } };\n        };\n    };\n};\n```\n\nAs you can see, the structure consists of definition of commands (CREATEUNIT, CREATEVEHICLELOCAL), definition of syntax (args[]) and target locality (targets[]):\n\n- **targets[]** - the format is `{ enableServer, enableClient ,enableHC }`. 1 means enable, 0 means disable. From the above example `targets[] = { 1, 0, 1 };` means: enable server, disable client, enable HC.\n- **args[]** - (Optional) the format is **{{leftArgumentType},{rightArgumentType}}**. The information about argument types could be retrieved with supportInfo command."},{"heading":"CfgDisabledCommands Utility (Arma 3 v1.68)","level":4,"markdown":"CfgDisabledCommand Utility can be used to generate CfgDisabledCommands template.\nIn order to do so, open debug console and type `utils 1` then click on LOCAL EXEC:"},{"heading":"Selecting Correct Syntax","level":3,"markdown":"While createVehicleLocal has only 1 syntax, createUnit has 2 syntaxes:\n\n```cpp\n// ...\nclass CREATEUNIT\n{\n    class SYNTAX1\n    {\n        targets[] = { 1, 1, 1 };\n        args[] = { { \"STRING\" }, { \"ARRAY\" } };\n    };\n\n    class SYNTAX2\n    {\n        targets[] = { 1, 1, 1 };\n        args[] = { { \"GROUP\" }, { \"ARRAY\" } };\n    };\n};\n// ...\n```\n\nFrom the createUnit command page it is obvious that `args[] = { { \"STRING\" }, { \"ARRAY\" } };` is the syntax we want to keep as it is the syntax we want to disable since it allows for passed code to be remote executed everywhere, and thus presenting a security issue, so we leave it and delete the other syntax which is harmless in comparison.\nFor other commands also refer to the respectful command pages. For example, setViewDistance:\n\n```cpp\nclass CfgDisabledCommands\n{\n    class SETVIEWDISTANCE\n    {\n        class SYNTAX1\n        {\n            targets[] = { 1, 1, 1 };\n            args[] = { {}, { \"SCALAR\" } };\n        };\n    };\n};\n```\n\nNote that the command doesn't have left argument, so it is simply replaced with `{}`.\nAfter the correct syntax is selected and other syntaxes are removed, the targets could be configured according to mission design (by default enabled everywhere).\n\nIf a command doesn't have left arguments, or right arguments the correct syntax is:\n\n```cpp\nclass CfgDisabledCommands\n{\n    class ALLPLAYERS\n    {\n        targets[] = { 1, 1, 1 };\n    };\n};\n```"},{"heading":"Reminder","level":3,"markdown":"Once again, consider carefully what commands you want to disable and verify that disabling is not interfering with default functionality of the game.\nDon't forget to check .rpt file to avoid any confusion in the future."}],"categories":["Arma 3: Remote Execution","Introduced with Arma 3 version 1.66"],"groups":["Configuration"]}