User:Nixinova/Function

Functions allow players to run lists of commands using text files with the extension. Being text files, functions are easily modifiable and less likely than command blocks to induce lag when used in large quantities.

Function syntax


Within the  file, one valid command is placed per line, without the usual forward slash. Players can add comments within the function text file by beginning a line with.

Individual commands in functions can be longer than the 32,500 character limit in command blocks. However, the total number of commands run inside a function is limited. Functions obey $$, which is 65,536 commands by default, and have a maximum of 10,000 $$. Any commands beyond this limit are ignored.

It is recommended to use ANSI encoding (without a byte order mark) for function files to prevent any problems.

The execution location does not move with the executor if it is teleported in a function. So if a function is executed as and at an entity or at ~ ~ ~, teleports the executor away and then sets a block at ~ ~ ~, the block would be at the original execution location. To target the new location a new execute command is needed.

Java Edition
To create a function, a text file [FUNCTION_NAME].mcfunction may be placed in the folder .minecraft/saves/[WORLD_NAME]/datapacks/[DATA_PACK_NAME]/data/[NAMESPACE]/functions.

Functions can also be placed into subfolders within the functions folder. It is also necessary to have a pack.mcmeta file in the [DATA_PACK_NAME] folder. For example, running the function  will refer to the file located at data/custom/functions/example/test.mcfunction.

Bedrock Edition
$$, function files must be placed into a top-level folder named " functions " within a behavior pack, located at com.mojang/behavior_packs/[BEHAVIOR_PACK_NAME]/functions.

Subfolders can be added to this folder to serve as namespaces. For example, the function  refers to the file located at [BEHAVIOR_PACK_NAME]/functions/sub/foo.mcfunction.

Invocation
To execute the function, use the fully qualified function name, which is. If there's no ambiguity with other datapacks or with an existing Minecraft command, just  may be used instead. If the namespace is left out when trying to call a function, it will default to the  namespace. Using a custom namespace $$ is recommended in order to prevent unintended behavior in the case of future additions to the default namespace.

Upon successfully running, a message will display in the chat: Executed [ amount ] command(s) from function '[ file path ]' . Embedded functions won't display this chat messsage. The successful output of the commands inside a function cannot be measured with a comparator (although the same effect could be accomplished with the use of command).

Functions will run all of their commands in a single tick and functions called from within other functions will also run their commands in the same tick as their parent. Functions will use the command environment of whatever called the function. This includes command sender, position, rotation, etc. This command context is preserved for all the commands in the function, so a command will use the saved position context even when a previous command in the same function teleported the original executor to a different position.

In a singleplayer or a LAN world, like a command block, a function can run any command that is no more restrictive than permission level 2. On the default multiplayer software $$, a function can run any command that is no more restrictive than the permission level prescribed in  setting in server.properties.

The command context can be updated as usual by their respective sub-commands. It is suggested to use target selector for the most frequently used entity in a function and use  when calling that function to modify the executor entity to that most frequently used entity. This can simplify content if the entity was selected with target selector arguments and improve performance in general for the reduced iteration through the world entity list.

If a function is updated while the player is still in-game, the command is used to alert the game that the function files have been changed. $$, the game must be restarted if new functions are added, as the command only reloads functions already known to the game.

Methods
There are several methods of running a function file in-game:

Commands

 * Allows players to run a function or all functions in a function tag once.
 * Uses the command environment of whatever called the command.
 * Initial command environment may be modified by the command.
 * Initial command environment may be modified by the command.

Advancements
$$, advancements can run a function once as a reward for completing them. The commands in the function are run through the player who completed the advancement.

Reward functions are called within advancement JSON files using the following format:

Tags
$$, functions can be grouped together using tags in data packs. These tags can then be called to run all the functions inside that tag with.

Functions tagged in  will automatically run every tick at the beginning of the tick. Functions tagged in  will run after (re)loading the datapack.

Note:  will run before   after reloading the datapack. This means that you cannot inherently rely on a stable state of the datapack for the first tick.

Engine version
$$, functions require a minimum engine version specified as in the pack  file. This field determines which version of a command to run. The number specified here should match the version number of the game. For example, say that was changed in. If the behavior pack has  and runs a function that contains, it runs the older version of fill (as if the version was still  ).