Komutların Ayrıntılı İşlevleri (A-L)

**Bu makale halen yapım aşamasında.**
Yapım aşamasında yardımcı olursanız seviniriz.

Bu sayfadaki bilgiler, ilk harfleri A'dan L harfine kadar olan komutların işlevlerini içermektedir.

## `/ability`

Sets or queries player with a specific ability.

-Syntax
`ability <player: target> <ability: Ability> <value: Boolean>`
`ability <player: target> [ability: Ability]`
-Arguments
`player: target`

Specifies the target to grant/revoke player ability. Must be a player name or target selector.
`ability: Ability`

Specifies the player ability.
These abilities are:
* `worldbuilder` gives the selector the ability to become a world builder.
* `mayfly` lets the selector fly.
* `mute` mutes the selector. If they chat, no-one can hear (or see) them.

`value: Boolean`

Specifies the value to set the ability to, must in between `true` or `false`.
-Result
Fails if the arguments are not specified correctly.

On success, Sets the player ability into the specified ability. If `value: Boolean` isn't specified, returns whether the player has the specified ability. If `ability: Ability` isn't specified, returns what abilities the player has.

-History

## **`/attribute`**

-Syntax
`attribute <*target*> <*attribute*> [base] get [<*scale*>]`
`attribute <*target*> <*attribute*> base set <*value*>`
`attribute <*target*> <*attribute*> modifier add <*uuid*> <*name*> <*value*> (add|multiply|multiply_base)`
`attribute <*target*> <*attribute*> modifier remove <*uuid*>`
`attribute <*target*> <*attribute*> modifier value get <*uuid*> [<*scale*>]`
-Details
`attribute <*target*> <*attribute*> ...`
`... get [<*scale*>]`
Returns the total value of the specified attribute.
`... base get [<*scale*>]`
Returns the base value of the specified attribute.
`... base set <*value*>`
Overwrites the base value of the specified attribute with the given value.
`... modifier (add|remove|value get)`
`... add <*uuid*> <*name*> <*value*> (add|multiply|multiply_base)`
Adds an attribute modifier with the specified properties if no modifier with the same UUID already existed.
`... remove <*uuid*>`
Removes the attribute modifier with the specified UUID.
`... value get <*uuid*> [<*scale*>]`
Returns the value of the modifier with the specified UUID.
-Arguments
`<*target*>`
The entity that the attribute is applied to. Only accepts a single target. Only players, armor stands, and mobs have attributes.
`<*attribute*>`
The namespaced ID of the specified attribute.
`<*scale*>`
The number the value is multiplied with before being returned.
`<*uuid*>`
Specifies the UUID of the modifier in the hyphenated hexadecimal format. Modifiers with the same UUID do not stack.
-Result
When using `set`, fails if the modifier is already present.

When using `get`, fails if the value an invalid double (64-bit integer) value.

On success, changes or returns the attribute value.

-Examples
* To set the minimum armor value of yourself to 5:
`/attribute @s minecraft:generic.armor base set 5`

-History

## `/advancement`

Gives or takes an advancement from one or more players.

-Syntax
`advancement (grant|revoke) <targets> everything`
`advancement (grant|revoke) <targets> only <advancement> [<criterion>]`
`advancement (grant|revoke) <targets> (from|through|until) <advancement>`
-Arguments
`(grant|revoke)`

Specify whether to add or remove the to-be-specified advancement(s).
`<targets>`

Specify one player or more. Must be a player name or a target selector.
Entities other than players are not allowed.
`everything`

Specify *all* loaded advancements for addition/removal.
`from`

Specify an advancement and *all* its children advancements for addition/removal.
Think of specifying everything *from* that advancement to the end.
The exact order the operation is carried out in is `specified advancement > child > child's child > ...` When it operates on a child that branches, it iterates through all its children before continuing.
`only`

Specifying a single advancement for addition/removal.
`through`

Specify an advancement, *all* its parent advancements, and *all* its children advancements for addition/removal.
Think of specifying everything *through* the specified advancement, going both backwards and forwards.
The exact order the operation is as if the command were executed with "until" specified, then with "from" specified: `parent > parent's parent > ... > root > specified advancement > child > child's child > ...`
`until`

Specify an advancement and *all* its parent advancements until the root for addition/removal.
Think of specifying everything from the start *until* that advancement.
The exact order the operation is carried out in is: `parent > parent's parent > ... > root > specified advancement`.
`<advancement>`

A valid advancement identifier; specifies which advancement to target.
`[<criterion>]`

A valid advancement criterion identifier; specifies which criterion of the advancement to manipulate.
This defaults to the entire advancement.
If specified, the command refers to merely the criterion and not the entire advancement.
-Result
On success, grants or removes the specified advancement(s) to the player(s).

Fails if the arguments are invalid or if <targets> fails to resolve to one or more online players.

-Examples
* To grant the "Cover Me With Diamonds!" advancement to player Steve, execute `/advancement grant Steve only minecraft:story/shiny_gear`.
* To grant the all advancements to every player, execute `/advancement grant @a everything`.

-History

## `/ban ve türevleri`

These commands control a server's banlist, or blacklist. A blacklist is a list of players or IP addresses that are not allowed to connect to the server. Bans supersede any whitelisting in place.

### `/ban`

Adds a player to the blacklist.

-Syntax
`ban <targets> [<reason>]`
-Arguments
`<targets>`

Name of the player to be added to the blacklist. Must be a player name, a target selector or a UUID. Does not have to be online or even real.
Entities other than players are not allowed.
`<reason>`

Message to display to the banned player, to other operators, and in the server logs. May include spaces as well as target selectors.
-Result
Fails if any target selectors in either argument fail to resolve to at least one online player.

On success, the player(s) is added to the server blacklist, which prevents anyone with that name from connecting to the server.

### `/ban-ip`

Adds an IP address to the blacklist.

-Syntax
`ban-ip <target> [<reason>]`
-Arguments
`<target>`

An IP address or name of an online player.
`<reason>`

A message to display to the banned player, to other operators, and in the server logs. May include spaces as well as target selectors.
-Result
Fails if either the IP address or player name is invalid, or if any target selectors in `<reason>` fail to resolve to at least one online player.

On success, the narrowly-specified address or that of the named, online player is added to the server blacklist, preventing anyone from connecting to the server from that address.

### `/banlist`

Displays the server's blacklist.

-Syntax
`banlist [ips|players]`
-Result
Always succeeds. Displays banned IP addresses or banned players.

### `/banip`

Bans a player by IP number. Cannot be undone in-game; `banned-ip.txt` must manually be changed.

The Classic equivalent of `/ban-ip`.

-Syntax
`banip (<address>|<name>) [<reason>]`
-History

## `/bossbar`

Creates and modifies boss bars.

-Syntax
`bossbar add <id> <name>`
`bossbar get <id> (max|players|value|visible)`
`bossbar list`
`bossbar remove <id>`
`... max <max>`
`... name <name>`
`... players [<targets>]`
`... value <value>`
`... visible <visible>`
-Arguments
`<id>`

Specifies a unique boss bar. Has the form of Namespaced ID (Note: "namespace:" defaults to "minecraft:" if absent.)
`<name>`

The display name of the boss bar. Must be a valid raw JSON text.
`... add <id> <name>`

Create a new boss bar.
`... get <id> (max|players|value|visible)`

Return the requested setting as a `result` of the command.
`... list`

Display a list of existing boss bars.
`... remove <id>`

Remove an existing bossbar.

Set the text color (if no color was specified as part of a text component) and bar color.
Defaults to `white` upon creation.
`... max <max>`
Set the boss bar's maximum value.
Defaults to `100` upon creation.
`... name <name>`
Set the boss bar's name.
`... players [<targets>]`
Change the set of players to whom the bar is visible.
Defaults to none upon creation.
Set the boss bar's visual amount of segments: continuous, 6 segments, 10 segments, 12 segments, or 20 segments.
Defaults to `progress` upon creation.
`... value <value>`
Set the boss bar's current value.
Defaults to `0` upon creation.
`... visible <visible>`
Set the boss bar's visibility.
Defaults to `true` upon creation.
-Result
Fails if bossbar specified with `<id>` doesn't exist in `set` mode and `remove` mode, or if bossbar specified with `<id>` already exists in `add` mode,

On success, creates, modifies or lists boss bar(s).

-History

## `/clear`

Clears items from player inventory, including items being dragged by the player.

-Syntax
* **Java Edition**

`clear [<targets>] [<item>] [<maxCount>]`
* **Bedrock Edition**

`clear [player: target] [itemName: Item] [data: int] [maxCount: int]`
-Arguments
`<targets>` (BE: `player: target`)

Must be a player name or a target selector. If not specified, defaults to the player who executed the command. Not optional if the executor isn't a player.
Entities other than players are not allowed.
`<item>` (BE: `itemName: Item`)

Specifies the id of the item to be cleared. If not specified, all items in the player's inventory are cleared.
`data: int` [*Bedrock edition only*]

Specifies the data value of the item to be cleared. If not specified, or if `-1`, all items that match "itemName: Item" are cleared, regardless of their data. Must be an integer between -1 and 2,147,483,647 (inclusive, without the commas), but values that are invalid for the specified item id revert to 0.
`<maxCount>` (BE: `maxCount: int`)

Specifies the maximum number of items to be cleared. If not specified, or if `-1`[*Bedrock edition only*], all items that match *item* and *data* are cleared. If `0`, does not clear items, but returns successfully if there were items that could have been cleared (allowing detection of items rather than clearing of items). Must be an integer less than 2,147,483,648.
-Result
Fails if the arguments are not specified correctly, if `<targets>` fails to resolve to one or more online players, or if no items are removed (except when <maxCount> is `0`)

On success, removes the specified items from the player(s). If maxCount is 0, no items are removed, and the number of matching items are displayed in chat.

If a player has a two specified items with the same name but different [data: int]
(For example light\_block 1 7 and light\_block 1 15) and the user clears their inventory of a specific [data: int], the command will always clear their inventory of the first item that is has the same [ItemName: Item] from the left side of the hot bar to the right, bottom to top of the inventory. [*Bedrock edition only*]

The specific outputs are as follows:

-Examples
* To clear your entire inventory: `clear`
* To clear all items from Alice's inventory: `clear Alice`
* To clear all wool items from Alice's inventory: `clear Alice minecraft:wool`
* To clear all orange wool items from the inventory of all players: `clear @a minecraft:wool 1`[*Bedrock edition only*] or  `clear @a minecraft:orange_wool`[*Java edition only*]
* To clear all golden swords with the "Sharpness I" enchantment from the nearest player
	+ `clear @p minecraft:golden_sword{Enchantments:[{id:"minecraft:sharpness",lvl:1s}]}`[*Java edition only*]
* To test if a random player has stone in his inventory: `clear @r minecraft:stone -1 0`[*Bedrock edition only*] or  `clear @r minecraft:stone 0`[*Java edition only*]

-See also
* `/data` — can change or remove items in block or entity inventories
* `/give` — give items to player
* `/kill` — can destroy item entities
* `/replaceitem` — can replace items in block or entity inventories

-History

**Bu madde bir taslaktır.**
İçeriği genişleterek yardımcı olabilirsin.

## `/clone`

Clones blocks from one region to another.

-Syntax* **Java Edition**

`clone <begin> <end> <destination> [replace|masked] [force|move|normal]`
`clone <begin> <end> <destination> filtered <filter> [force|move|normal]`* **Bedrock Edition**

`clone <begin: x y z> <end: x y z> <destination: x y z> [maskMode: MaskMode] [cloneMode: CloneMode]`
`clone <begin: x y z> <end: x y z> <destination: x y z> filtered <cloneMode: CloneMode> <tileName: Block> <tileData: int>`-Arguments`<begin>` and `<end>` (BE: `begin: x y z` and `end: x y z`)

Specifies the coordinates of two opposing corner blocks of the source region. May use tilde and caret notation to specify distances relative to the command's execution.
The blocks that make up the corners extend in the positive direction from the coordinates used to identify them. Because of this, the lesser coordinates of each axis falls right on the region boundary, but the greater coordinates are one block from the boundary, and the block volume of the source region is (xgreater - xlesser + 1) × (ygreater - ylesser + 1) × (zgreater - zlesser + 1). For example, `0 0 0 0 0 0` has a 1-block volume, and `0 0 0 1 1 1` and `1 1 1 0 0 0` both identify the same region with an 8-block volume.`<destination>` (BE: `destination: x y z`)

Specifies the lower northwest corner (i.e., the smallest coordinates of each axis) of the destination region. May use tilde and caret notation to specify a distance relative to the command's execution.`replace|masked` (BE: `maskMode: MaskMode`)

Specifies whether to filter the blocks being cloned. Must be one of the following:
* `replace` — Copy all blocks, overwriting *all* blocks of the destination region with the blocks from the source region.
* `masked` — Copy only non-air blocks. Blocks in the destination region that would otherwise be overwritten by air are left unmodified.

If left unspecified, defaults to `replace`.`force|move|normal` (BE: `cloneMode: CloneMode`)

Specifies how to treat the source region. Must be one of the following:
* `force` — Force the clone even if the source and destination regions overlap.
* `move` — Clone the source region to the destination region, then replace the source region with air. When used in filtered mask mode, only the cloned blocks are replaced with air.
* `normal` — Don't move or force.

If left unspecified, defaults to `normal`.`<filter>` (BE: `tileName: Block`)

Specifies the block id to copy in `filtered` mode, in which the command clones only blocks with the block id specified by this argument.`tileData: int`[*Bedrock edition only*]

Specifies the block data to match when finding blocks to clone. Must be between 0 and 65535 (inclusive), but values that are invalid for the specified block id revert to 0.-ResultFails if the block volume of the source region is greater than 32768 (the equivalent of 8 chunk sections)[*Java edition only*] or 524288(equivalent to 8 chunks)[*Bedrock edition only*], if the source and destination region overlap (unless using force clone mode), or if one or both regions isn't currently loaded.

On success, overwrites blocks in the destination region with blocks from the source region, leaving the source region unmodified (unless using move clone mode).

-History

**Bu madde bir taslaktır.**
İçeriği genişleterek yardımcı olabilirsin.

## `/collect`

Lets your agent collect all items within a one block from Agent in three dimensions.

-Syntax
`collect <item: string>`
-Arguments
`item: string`

Specifies the item to be collected on the block to the Agent's inventory. Must be an item ID, or a block ID for which an item exists (for example, `golden_sword`).
-Result
Fails if the arguments are not specified correctly or no items of the same name were collected.

On success, returns if any items of the same name were collected.

-History
Şablon:H
Şablon:H
Şablon:H

## `/data`

The `**/data**` command allows the user to get, merge, modify, and remove NBT data of a block entity, entity, or Command NBT storage.

-Syntax
There are four instructions for `/data` (`get`, `merge`, `modify`, `remove`), and the targets/sources referenced by each instruction command may be either `block <targetPos>`, `entity <target>`, or `storage <target>`.

`data **get** block <targetPos> [<path>] [<scale>]`
`data get entity <target> [<path>] [<scale>]`
`data get storage <target> [<path>] [<scale>]`
`data **merge** block <targetPos> <nbt>`
`data merge entity <target> <nbt>`
`data merge storage <target> <nbt>`
`data **remove** block <targetPos> <path>`
`data remove entity <target> <path>`
`data remove storage <target> <path>`
**Syntax displayed in various ways**

* `… **get** <*TARGET*> [<path>] [<scale>]`
* `… **merge** <*TARGET*> <nbt>`
* `… **modify** <*TARGET*> <targetPath> <*MODIFICATION*>`
	+ `… from <*SOURCE*> [<sourcePath>]`
	+ `… value <value>`
* `… **remove** <TARGET> <path>`

where substituted arguments are:
`<*TARGET*>` = `(block <targetPos> | entity <target> | storage <target>)`

* `… **get**`
	+ `… block <targetPos> [<path>] [<scale>]`
	+ `… entity <target> [<path>] [<scale>]`
	+ `… storage <target> [<path>] [<scale>]`
* `… **merge**`
	+ `… block <targetPos> <nbt>`
	+ `… entity <target> <nbt>`
	+ `… storage <target> <nbt>`
* `… **modify**`
		- `… from`
			* `… block <sourcePos> [<sourcePath>]`
			* `… entity <source> [<sourcePath>]`
			* `… storage <source> [<sourcePath>]`
		- `… value <value>`
		- `… from`
			* `… block <sourcePos> [<sourcePath>]`
			* `… entity <source> [<sourcePath>]`
			* `… storage <source> [<sourcePath>]`
		- `… value <value>`
		- `… from`
			* `… block <sourcePos> [<sourcePath>]`
			* `… entity <source> [<sourcePath>]`
			* `… storage <source> [<sourcePath>]`
		- `… value <value>`
* `… **remove**`
	+ `… block <targetPos> [<path>]`
	+ `… entity <target> [<path>]`
	+ `… storage <target> [<path>]`

* `… **get** (block <targetPos>|entity <target>|storage <target>) [<path>] [<scale>]`
* `… **merge** (block <targetPos>|entity <target>|storage <target>) <nbt>`
	+ `… from (block <sourcePos>|entity <source>|storage <source>) [<sourcePath>]`
	+ `… value <value>`
* `… **remove** (block <targetPos>|entity <target>|storage <target>) <path>`

```

```

`data get entity <target> [<path>] [<scale>]`
`data get storage <target> [<path>] [<scale>]`
`data **merge** block <targetPos> <nbt>`
`data merge entity <target> <nbt>`
`data merge storage <target> <nbt>`
`data **modify** block <targetPos> <targetPath> **append** from block <sourcePos> <sourcePath>`
`data modify block <targetPos> <targetPath> append from entity <source> <sourcePath>`
`data modify block <targetPos> <targetPath> append from storage <source> <sourcePath>`
`data modify block <targetPos> <targetPath> append value <nbt>`
`data modify block <targetPos> <targetPath> **insert index>** from block <sourcePos> <sourcePath>`
`data modify block <targetPos> <targetPath> insert <index> from entity <source> <sourcePath>`
`data modify block <targetPos> <targetPath> insert <index> from storage <source> <sourcePath>`
`data modify block <targetPos> <targetPath> insert <index> value <nbt>`
`data modify block <targetPos> <targetPath> **merge** from block <sourcePos> <sourcePath>`
`data modify block <targetPos> <targetPath> merge from entity <source> <sourcePath>`
`data modify block <targetPos> <targetPath> merge from storage <source> <sourcePath>`
`data modify block <targetPos> <targetPath> merge value <nbt>`
`data modify block <targetPos> <targetPath> **prepend** from block <sourcePos> <sourcePath>`
`data modify block <targetPos> <targetPath> prepend from entity <source> <sourcePath>`
`data modify block <targetPos> <targetPath> prepend from storage <source> <sourcePath>`
`data modify block <targetPos> <targetPath> prepend value <nbt>`
`data modify block <targetPos> <targetPath> **set** from block <sourcePos> <sourcePath>`
`data modify block <targetPos> <targetPath> set from entity <source> <sourcePath>`
`data modify block <targetPos> <targetPath> set from storage <source> <sourcePath>`
`data modify block <targetPos> <targetPath> set value <nbt>`
`data modify entity <target> <targetPath> append from block <sourcePos> <sourcePath>`
`data modify entity <target> <targetPath> append from entity <source> <sourcePath>`
`data modify entity <target> <targetPath> append from storage <source> <sourcePath>`
`data modify entity <target> <targetPath> append value <value>`
`data modify entity <target> <targetPath> insert <index> from block <sourcePos> <sourcePath>`
`data modify entity <target> <targetPath> insert <index> from entity <source> <sourcePath>`
`data modify entity <target> <targetPath> insert <index> from storage <source> <sourcePath>`
`data modify entity <target> <targetPath> insert <index> value <value>`
`data modify entity <target> <targetPath> merge from block <sourcePos> <sourcePath>`
`data modify entity <target> <targetPath> merge from entity <source> <sourcePath>`
`data modify entity <target> <targetPath> merge from storage <source> <sourcePath>`
`data modify entity <target> <targetPath> merge value <value>`
`data modify entity <target> <targetPath> prepend from block <sourcePos> <sourcePath>`
`data modify entity <target> <targetPath> prepend from entity <source> <sourcePath>`
`data modify entity <target> <targetPath> prepend from storage <source> <sourcePath>`
`data modify entity <target> <targetPath> prepend value <value>`
`data modify entity <target> <targetPath> set from block <sourcePos> <sourcePath>`
`data modify entity <target> <targetPath> set from entity <source> <sourcePath>`
`data modify entity <target> <targetPath> set from storage <source> <sourcePath>`
`data modify entity <target> <targetPath> set value <value>`
`data modify storage <target> <targetPath> append from block <sourcePos> <sourcePath>`
`data modify storage <target> <targetPath> append from entity <source> <sourcePath>`
`data modify storage <target> <targetPath> append from storage <source> <sourcePath>`
`data modify storage <target> <targetPath> append value <value>`
`data modify storage <target> <targetPath> insert <index> from block <sourcePos> <sourcePath>`
`data modify storage <target> <targetPath> insert <index> from entity <source> <sourcePath>`
`data modify storage <target> <targetPath> insert <index> from storage <source> <sourcePath>`
`data modify storage <target> <targetPath> insert <index> value <value>`
`data modify storage <target> <targetPath> merge from block <sourcePos> <sourcePath>`
`data modify storage <target> <targetPath> merge from entity <source> <sourcePath>`
`data modify storage <target> <targetPath> merge from storage <source> <sourcePath>`
`data modify storage <target> <targetPath> merge value <value>`
`data modify storage <target> <targetPath> prepend from block <sourcePos> <sourcePath>`
`data modify storage <target> <targetPath> prepend from entity <source> <sourcePath>`
`data modify storage <target> <targetPath> prepend from storage <source> <sourcePath>`
`data modify storage <target> <targetPath> prepend value <value>`
`data modify storage <target> <targetPath> set from block <sourcePos> <sourcePath>`
`data modify storage <target> <targetPath> set from entity <source> <sourcePath>`
`data modify storage <target> <targetPath> set from storage <source> <sourcePath>`
`data modify storage <target> <targetPath> set value <value>`
`data **remove** block <targetPos> <path>`
`data remove entity <target> <path>`

-Arguments
`(block <targetPos>|entity <target>|storage <target>)`

* `<targetPos>`—The `<x> <y> <z>` position of the target block entity whose NBT is to be operated on
* `<target>`—Valid a UUID, or a target selector variable for an entity whose NBT is to be operated on
* `<target>`—Valid namespaced ID for a storage to be operated on

`get ... [<path>] [<scale>]`

* `<path>`—Valid a NBT path defining the specific NBT to retrieve
* `<scale>`—Scalar for the command's return value

`merge ... <nbt>`

* `<nbt>`—Compound tag. The simplest valid input is `{}`.

* `<targetPath>`—Valid a NBT path defining the specific *target* NBT to modify
* `<index>`—Valid integer specifying an item's index within a list

`… from (block <sourcePos>|entity <sourceEntity>|storage <sourceStorage>) <sourcePath>`:
* `<sourcePos>`—The `<x> <y> <z>` position of the source block entity whose NBT is to be used
* `<sourceEntity>`—Valid player name, UUID, or target selector variable of a source entity whose NBT is to be used
* `<sourceStorage>`—Valid storage namespace whose NBT is to be used
* `<sourcePath>`—Valid a NBT path defining the specific *source* NBT to be used by `modify`

`… value <value>`:
* `<value>`—Value to use in modifying the target NBT. Must match in data type

`remove ... <path>`

* `<path>`—Valid a NBT path to the NBT to remove

-Results
Fails if the arguments are not specified correctly.

On success:

`/data get`

`/data get ...`
Read off the entire NBT data from the targeted block position or entity to the executor with syntax highlighting.
If applicable, returns 1 on success.
`/data get ... <path>`
Send the subsection of the NBT data from the targeted block position or entity to the executor without syntax highlighting.
Return value depends on the type of the NBT element:
* Retrieving a number returns that number.
* Retrieving a string returns the length of the string.
* Retrieving a list returns the number of elements in that list.
* Retrieving a compound returns the number of tags that are direct children of that compound.

`/data get ... <path> <scale>`
Return the value of the tag, scaled by <scale>.
<path> needs to specify a numeric tag—TAG\_byte, TAG\_short, TAG\_int, TAG\_long, TAG\_float, or TAG\_double.
`/data merge`
Merge the NBT data from the sourced block position or entity with the specified <nbt> data.
If applicable, returns 1 on success.
`/data modify`

`append`
Append the source data onto the *end* of the pointed-to list.
`<targetPath>` must specify a tag of the TAG\_List, TAG\_Byte\_Array, TAG\_Int\_Array, or TAG\_Long\_Array type, and the source data should be of an item type appropriate for the list.
`insert <index>`
Insert the source data into the pointed-to list as element `<index>`, then shift higher elements one position upwards.
`<targetPath>` must specify a tag of the TAG\_List, TAG\_Byte\_Array, TAG\_Int\_Array, or TAG\_Long\_Array type, and the source data should be of an item type appropriate for the list.
`merge`
Merge the source data into the pointed-to object.
Both `<targetPath>` and source data must be of the TAG\_compound type.
`prepend`
Prepend the source data onto the *beginning* of the pointed-to list.
`<targetPath>` must specify a tag of the TAG\_List, TAG\_Byte\_Array, TAG\_Int\_Array, or TAG\_Long\_Array type, and the source data should be of an item type appropriate for the list.
`set`
Set the tag specified by `<targetPath>` to the source data.
`/data remove`
Removes NBT data at <path> from the targeted block position or entity. Player NBT data cannot be removed.
If applicable, returns 1 on success.
-NBT path
Ana makale: NBT path format
-Examples
* To make all items within 10 blocks unable to be picked up by players:
`/data modify entity @e[type=item,distance=..10] PickupDelay set value -1`
* To get the Y-position of a random item:
`/data get entity @e[type=item,limit=1,sort=random] Pos[1]`
* To get the item ID of the item in the first hotbar slot of the nearest player:
`/data get entity @p Inventory[{Slot:0b}].id`
* To set the armor attribute of the dolphin closest to coordinates (0, 64, 0) to 20:
`/data modify entity @e[x=0, y=64, z=0, type=dolphin, limit=1] Attributes[{Name:"generic.armor"}].Base set value 20`
* To change the first item in a chest located at coordinates (1, 64, 1) into a diamond block, keeping all NBT data:
`/data modify block 1 64 1 Items[0].id set value "minecraft:diamond_block"`

-Storage
*Şunlara da bakın: command storage format*
The command storage of NBT data is an efficient way for commands to access or save NBT data without an overhead for block entities or entities reading from or writing to the NBT data.

Each command storage is a general purpose, key-value storage, identified by a namespaced ID to prevent unintentional conflicts.

`/data get` and `/data modify` can read from the storage, while `/data merge`, `/data modify`, `/data remove`, and `/execute store` can write to the storage.

The command storage is accessible with JSON text as well.

-History

## `/datapack`

Controls the loading/unloading of data packs.

-Syntax
`datapack disable <name>`
`datapack enable <name> [first|last]`
`datapack enable <name> [before|after] <existing>`
`datapack list [available|enabled]`
-Arguments
`<name>`

Specifies the name of the data pack.
`<existing>`

Specifies the name of an existing data pack.
-Result
Command fails if the arguments are not specified correctly.

On success:

* `(disable|enable)`—Disable or enable the specified pack.
* `enable`—Enable the specified pack.
	+ `first`—Load this pack before all others (lowest priority).
	+ `last`—Load this pack after all others (highest priority).
	+ `before`—Load this pack just before (lower priority) an *existing* pack.
	+ `after`—Load this pack just after (higher priority) an *existing* pack.
* `list`—List all data packs, or list only the available/enabled ones. Hovering over the data packs in the chat output shows their description defined in their `pack.mcmeta`.

-History

## `/debug`

Starts or stops a debugging session.

-Syntax
`debug (start|stop|report)`
-Arguments
`start`

Starts a new debug profiling session.
`stop`

Stops the active debug profiling session.
`report`

Used to get more detailed information while debugging performance. Saves information in the `.minecraft\debug` folder in the form of a zip file.
-Result
Fails if trying to start a debug session when one is already active, or if trying to stop a debug session when none is running.

On success, starts or stops the debug session. While active, includes notifications about potential performance bottlenecks in the console. When stopped, creates a profiler results file in the folder "debug".

-File structure
When using `/debug report`, a `.zip` file is created with the following structure:Şablon:Info needed

* **debug-report-<year>-<month>-<day>\_<hour>.<minute>.<second>.zip**
	+ **levels**
		- **minecraft** or **<other custom namespaces>**
			* **overworld** or **the\_end** or **the\_nether** or **<other custom dimensions>**
				+ **block\_entities.csv**: Contains a list of block entities in the world in the format `x,y,z,type`.
				+ **chunks.csv**: Contains a list of chunk information in the format `x,z,level,in_memory,status,full_status,accessible_ready,ticking_ready,entity_ticking_ready,ticket,spawning,entity_count,block_entity_count`.
				+ **entities.csv**: Contains a list of entities in the world in the format `x,y,z,uuid,type,alive,custom_name`.
				+ **example\_crash.txt**: An example crash file.
				+ **stats.txt**: Contains some statistics.
	+ **classpath.txt**: Contains the file paths of the external jars *Minecraft* uses.
	+ **example\_crash.txt**: An example crash file.
	+ **gamerules.txt**: A plain text file containing a list of game rules and their values (`<gamerule>=<value>`).

-History

## `/defaultgamemode`

Sets the default game mode (creative, survival, etc.) for new players entering a multiplayer server.

-Syntax
`defaultgamemode <*mode*>`
-Arguments
`<*mode*>`

Specifies the default game mode for new players. Must be one of the following:
* `survival` for survival mode
* `creative` for creative mode
* `adventure` for adventure mode
* `spectator` for spectator mode

-Result
Fails if the arguments are not specified correctly.

If successful, sets the default game mode that is shown on the world selection menu. New players who join the world are put into the default game mode.

-Examples
* To set the default game mode to survival: `defaultgamemode survival`

-History

## `/deop`

Revokes operator status from a player.

-Syntax
* **Java Edition**

`deop <targets>`
* **Bedrock Edition**

`deop <player: target>`
-Arguments
`<targets>` (BE: `player: target`)

Must be a player name or a target selector.
Entities other than players are not allowed.
-Result
Fails if player(s) isn't op.

On success, removes `<targets>` from the list of operators.

-Examples
* To remove Steve from the list of operators: `deop Steve`

-History

**Bu madde bir taslaktır.**
İçeriği genişleterek yardımcı olabilirsin.

## `/destroy`

Makes your agent destroy a block or item in the specified direction.

-Syntax
`destroy <direction: string>`
-Arguments
`direction: string`

Specifies the direction of Agent to destroy.
Must be one of:
* `forward` to destroy block/item on the front.
* `back` to destroy block/item on the back.
* `left` to destroy block/item on the left-hand side.
* `right` to destroy block/item on the right-hand side.
* `up` to destroy block/item on the top-hand side.
* `down` to destroy block/item on the bottom-hand side.

-Result
Fails if the block was unbreakable or a non-solid block.

On success, the Agent destroys the block/item by one hit as expected.

-History
Şablon:H
Şablon:H
Şablon:H

## `/detect`

Lets your agent detect if there is a collidable block in the specified direction.

-Syntax
`detect <direction: string>`
-Arguments
`direction: string`

Specifies the direction of Agent to detect a collidable block.
Must be one of:
* `forward` to detect the block on the front.
* `back` to detect the block on the back.
* `left` to detect the block on the left-hand side.
* `right` to detect the block on the right-hand side.
* `up` to detect the block on the top side.
* `down` to detect the block on the bottom side.

-Result
Fails if the arguments are not specified correctly.

On success, returns if there was a collidable block in the specified direction.

-History
Şablon:H
Şablon:H
Şablon:H

## `/detectredstone`

Lets your agent detect a redstone signal in the specified direction.

-Syntax
`detectredstone <direction: string>`
-Arguments
`direction: string`

Specifies the direction of Agent to detect a redstone signal.
Must be one of:
* `forward` to detect the block on the front.
* `back` to detect the block on the back.
* `left` to detect the block on the left-hand side.
* `right` to detect the block on the right-hand side.
* `up` to detect the block on the top-hand side.
* `down` to detect the block on the bottom-hand side.

-Result
Fails if the arguments are not specified correctly.

On success, returns if the object in the specified direction received a redstone signal at that moment.

-History
Şablon:H
Şablon:H
Şablon:H

## `/difficulty`

Sets the difficulty level (peaceful, easy, etc.).

-Syntax
* **Java Edition**

`difficulty [easy|hard|normal|peaceful]`
* **Bedrock Edition**

`difficulty <difficulty: Difficulty>`
`difficulty <difficulty: int>`
-Arguments
`easy|hard|normal|peaceful` (BE: `difficulty: Difficulty` or `difficulty: int`)

Specifies the new difficulty level. Must be one of the following:
* `peaceful` (can be abbreviated as `p` or `0`[*Bedrock edition only*]) for peaceful difficulty
* `easy` (can be abbreviated as `e` or `1`[*Bedrock edition only*]) for easy difficulty
* `normal` (can be abbreviated as `n` or `2`[*Bedrock edition only*]) for normal difficulty
* `hard` (can be abbreviated as `h` or `3`[*Bedrock edition only*]) for hard difficulty

-Result
Fails if the arguments are not specified correctly, or if the original difficulty is the same as the specified difficulty[*Java edition only*].

If successful and applied, changes the game's difficulty. On a multiplayer server lasts only until the server is restarted — on restart, difficulty is reloaded from server.properties.

In Hardcore mode, the difficulty doesn't change even when successful.[*Java edition only*]
If the argument is empty, querys current difficulty rather than changes it.[*Java edition only*]
-Examples
* To change the difficulty to hard: `difficulty hard`, `difficulty h`[*Bedrock edition only*], or `difficulty 3`[*Bedrock edition only*]

-History

**Bu madde bir taslaktır.**
İçeriği genişleterek yardımcı olabilirsin.

## `/dropall`

Makes an agent drop all its items from all slots onto the ground by one block in the specified direction.

-Syntax
`dropall <direction: string>`
-Arguments
`direction: string`

Specifies the direction of Agent to drop all the items.
Must be one of:
* `forward` to drop items to the front.
* `back` to drop items to the back.
* `left` to drop items to the left.
* `right` to drop items to the right.

-Result
Fails if the arguments are not specified correctly or the Agent's inventory was empty.

On success, returns if all items were dropped onto the ground in the direction specified.

-History
Şablon:H
Şablon:H
Şablon:H

## `/effect`

Add or remove status effects on players and other entities.

-Syntax
* **Java Edition**

`effect clear [<targets>] [<effect>]` (removes an effect)
`effect give <targets> <effect> [<seconds>] [<amplifier>] [<hideParticles>]` (gives an effect)
* **Bedrock Edition**

`effect <player: target> clear` (removes all effects)
`effect <player: target> <effect: Effect> [seconds: int] [amplifier: int] [hideParticles: Boolean]` (gives or removes an effect)
-Arguments
`<targets>` (BE: `player: target`)

Specifies the target(s). Must be a player name, a target selector or a UUID[*Java edition only*]
Permits entities other than players.
`<effect>` (BE: `effect: Effect`)

Specifies the effect to add or remove. Must be a status effect id.
`<seconds>` (BE: `seconds: int`)

Specifies the effect's duration in seconds. Must be between 1 and 1,000,000[*Java edition only*], or 1 and 100,000[*Bedrock edition only*]. (inclusive, without the commas). If not specified, defaults to 30 seconds.
`<amplifier>` (BE: `amplifier: int`)

Specifies the number of additional levels to add to the effect. Must be between 0 and 255 (inclusive). If not specified, defaults to 0. Note that the first tier of a status effect (e.g. Regeneration I) is 0, so the second tier, for example Regeneration II, would be specified by an amplifier level of 1.
`<hideParticles>` (BE: `hideParticles: Boolean`)

Specifies whether the particles and the HUD indicator[*Java edition only*] of the status effect should be hidden. Must be either `true` or `false`. If not specified, defaults to `false`.
-Result
Fails if arguments are not specified correctly, if `<targets>` fails to resolve to one or more valid entities (named players must be online), if `<seconds>` was specified as 0 and the target did not have the effect Bedrock Sürümü sürümünde, or if no effects were removed in `clear` mode.

On success:

* `clear` mode — clears status effects from the target(s).

* `effect give` (BE: effect) mode — Adds the status effect to the target(s). If a target already has the status effect, a new status effect with the same amplifier overrides the old duration only if it is longer, but a new status effect with a higher duration overrides any previous duration. Bedrock Sürümü sürümünde, if seconds is set to 0, cancels the specified effect instead.

-Examples
* To grant a Speed II effect to the nearest player for 60 seconds: `effect give @p minecraft:speed 60 1`[*Java edition only*] or `effect @p speed 60 1`[*Bedrock edition only*]
* To grant a Speed III effect to the nearest player for 60 seconds: `effect give @p minecraft:speed 60 2`[*Java edition only*] or `effect @p speed 60 2`[*Bedrock edition only*]
* To clear any Haste effects from all players: `effect clear @a minecraft:haste`[*Java edition only*] or `effect @a haste 0`[*Bedrock edition only*]
* To clear all effects from all zombies: `effect clear @e[type=zombie]`[*Java edition only*] or `effect @e[type=zombie] clear`[*Bedrock edition only*]

-History

## `/enchant`

Adds an enchantment to a player's selected item, subject to the same restrictions as an anvil.

-Syntax
* **Java Edition**

`enchant <targets> <enchantment> [<level>]`
* **Bedrock Edition**

`enchant <player: target> <enchantmentId: int> [level: int]`
`enchant <player: target> <enchantmentName: Enchant> [level: int]`
-Arguments
`<targets>` (BE: `player: target`)

Specifies the (s). Must be a player name, target selector or a UUID[*Java edition only*].
Permits entities other than players.
`<enchantment>` (BE: `enchantmentId: int` or `enchantmentName: Enchant`)

Specifies the enchantment to be added to the item held by the target. Must be a valid enchantment ID.
`<level>` (BE: `level: int`)

Specifies the enchantment level. Must be at least 1 and not greater than the maximum level for the specified enchantment. If not specified, defaults to 1.
-Result
Fails if arguments are not specified correctly, if `<targets>` fails to resolve to one or more online players, if the enchantment is not valid for the item,Şablon:Note or if the enchantment conflicts with current enchantments (for example, "Piercing" cannot be given to a crossbow which already has "Multishot", and "Sharpness III" cannot be given to a sword which already has "Sharpness I").

On success, adds the specified enchantment to the item held by the target.

-Examples
* To give the Infinity enchantment to all players holding a bow:
`/enchant @a infinity`
* To enchant the executing player's held sword with Sharpness 5:
`/enchant @s sharpness 5`

-History

**Bu madde bir taslaktır.**
İçeriği genişleterek yardımcı olabilirsin.

## `/execute`

`/execute` is a versatile command that modifies variables or procedures in the execution of another command.

### {MC-JavaSürümü için:}

*Java Sürümü* sürümünde, there are twelve instructions (or sub-commands) for the `/execute` command. Multiple sub-commands are connected after /execute. Subcommands are divided into 4 categories: modify subcommands, condition subcommands, store subcommands, and `run` subcommand.

* Modify subcommands modify command variables and change the situation the command is executed, and execute subcommands following it with specific executor(s), execution position(s), execution dimension(s), and execution rotation(s).
* Condition subcommands are used to test whether certain conditions are true and output results or limit conditions of execution.
* Store subcommands can store the return values of the command in a scoreboard or the data of an entity, block entity or storage, and can also change the maximum or current value of a boss bar.
* `run` subcommand is used for carrying out another command.

A number of sub-commands needed can be chained together. Subcommands other than the `run` subcommand can be arranged arbitrarily or used multiple times. But the `run` subcommand can only be used once and must at the end of the subcommands chain. A `run` subcommand or a condition subcommand finalizes the command, otherwise the command does nothing. The game processes these subcommands in order from front to end, for example, the following commands are different:

* All entities move one block forward: `execute as @e at @s run tp ^ ^ ^1`
* All entities move to one block in front of the executor: `execute at @s as @e run tp ^ ^ ^1`

The game processes other subcommands before processing `run` and store subcommands, so the `run` and store subcommands cannot affect other subcommands. The `run` commands and store subcommands cannot affect each other as well. In some cases, the command terminates halfway and does nothing.

After the command is executed (if it does not terminate halfway), it returns a `success` and a `result` value (see #Store subcommands for details). These two values ??come from the last subcommand (may be a condition subcommand or `run` subcommand). Note that the return value of the command must be an integer, if not, it is rounded down. The `success` value is usually 0 or 1. When the command fails, both return values ??are 0. When the last subcommand (may be a condition subcommand or `run` subcommand) is executed multiple times, only values of the last execution can be returned. The two values can be stored by store subcommands.

`/execute` command also has a success count (whether or not terminates halfway). This is usually `0` or `1`, but if the command split up (as perhaps with "/execute as @a -> *execute*") then success can be a number higher than `1`. When executing it with the command block, the success count is returned to the command block, which can be checked by the conditional command block for success or be read with a redstone comparator.

There are twelve instructions (or sub-commands) for the `/execute` command, and each has its own special syntax, so describing syntax takes a large branching tree.

**This section needs updating**. Some of the information no longer applies to the latest version.

Full syntax tree

`**/execute** . . .`
* `… **align** <axes> -> *execute*`
* `… **anchored** <anchor> -> *execute*`
* `… **as** <targets> -> *execute*`
* `… **at** <targets> -> *execute*`
* `… **facing** (<pos>|entity <targets> <anchor>) -> *execute*`
* `… **in** <dimension> -> *execute*`
* `… **positioned** (<pos>|as <targets>) -> *execute*`
* `… **rotated** (<rot>|as <targets>) -> *execute*`
* `… **store** (result|success) . . .`
	+ `… bossbar <id> (max|value) -> *execute*`
	+ `… score <targets> <objective> -> *execute*`
* `… (**if**|**unless**) . . .`
	+ `… block <pos> <block> -> [*execute*]`
	+ `… blocks <start> <end> <destination> (all|masked) -> [*execute*]`
	+ `… data . . .`
		- `… block <sourcePos> <path> -> [*execute*]`
		- `… entity <source> <path> -> [*execute*]`
		- `… storage <source> <path> -> [*execute*]`
	+ `… entity <entities> -> [*execute*]`
	+ `… predicate <predicate> -> [*execute*]`
	+ `… score <target> <targetObjective> . . .`
		- `… matches <range> -> [*execute*]`
* `… **run** <*command*>`

where `-> *execute*` represents the start of another subcommand.
#### Modify subcommands

-align
Convert execution position's coordinates of specified axes to block position (rounding down, toward negative infinity.).

Syntax
`align <axes> -> *execute*`
Arguments
`<axes>`
Any non-repeating combination of the characters 'x', 'y', and 'z'. (For example, `x`, `xz`, `zyx`, or `yz`.)
Result
Error if the argument is not specified correctly.
Example

* Given the position (-1.8, +2.3, +5.9), the command `/execute **align xz** run summon zombie ~ ~ ~` summons a zombie at (-2.0, +2.3, +5.0).
* Given (+2.4, -1.1, +3.8), using `/execute **align yxz** run spawnpoint @p ~ ~ ~` sets the player's spawnpoint to (2, -2, 3).

-anchor
Stores the distance from the feet to the eyes of the entity that is executing the command in the anchor, which is part of the command context. Default of anchor is feet.

The only places where the anchor is used is in the caret notation (`^?T ^?N ^?B`) and in the `facing` subcommand of the `execute` command.

Syntax
`anchored <anchor> -> *execute*`
Arguments
`<anchor>`
Must be one of `feet` and `eyes`.
Result
Error if the argument is not specified correctly.
-as
Change the executor to the targeted entity/entities, but does not change position or rotation of execution. Changes the function of the `@s` target selector variable

Syntax
`as <targets> -> *execute*`
Arguments
`<targets>`
Specifies the target(s). Must be a player name, a target selector or a UUID
Permits entities other than players.
Result
Error if the argument is not specified correctly.
Terminates if `<targets>` fails to resolve to one or more valid entities (named players must be online).
When multiple entities are selected, next subcommand is executed once each per executor.
Example
Get data of all sheep: `execute **as @e[type=sheep]** run data get entity @s`
-at
Use the position, rotation, and dimension of the target(s), but does not change the current executor. Changes the function of `~?x ~?y ~?z` and `^?T ^?N ^?B` positioning.

Syntax
`at <targets> -> *execute*`
Arguments
`<targets>`
Specifies the target(s). Must be a player name, a target selector or a UUID
Permits entities other than players.
Result
Error if the argument is not specified correctly.
Terminates if `<targets>` fails to resolve to one or more valid entities (named players must be online).
When multiple entities are selected, next subcommand is executed once each per execution position.
Example
All sheep move upward 1 block: `execute **as @e[type=sheep]** at @s run tp ~ ~1 ~`
Kill yourself: `execute **at @e[type=sheep]** run kill @s`
-facing
Change the execution rotation to facing either the given position or the targeted entity's/entities' eyes or feet, but does not change the current executor. Changes the function of `^?T ^?N ^?B` positioning.

Syntax
`facing (<pos>|entity <targets> <anchor>) -> *execute*`
Arguments
`<targets>`
Specifies the target(s). Must be a player name, a target selector or a UUID
Permits entities other than players.
`<anchor>`
Must be one of `feet` and `eyes`.
`<pos>`
Must be in form of `<x> <y> <z>`. May use tilde and caret notation.
Result
Error if the argument is not specified correctly.
Terminates if `<targets>` fails to resolve to one or more valid entities (named players must be online).
When multiple entities are selected, next subcommand is executed once each per execution rotation.
Example
All entities move one block in the direction of (0, 64, 0) (without changing their rotation): `execute as @e at @s **facing 0 64 0** run tp @s ^ ^ ^1`
All entities move one block in the direction of (0, 64, 0) (with changing their rotation): `execute as @e at @s **facing 0 64 0** run tp ^ ^ ^1`
All non player entities move one space in the direction of their nearest player (without changing their orientation): `execute as @e[type=!player] at @s **facing entity @p eyes** run tp @s ^ ^ ^1`
-in
Change the execution dimension to specified dimension.

Syntax
`in <dimension> -> *execute*`
Arguments
`<dimension>`
Must be in form of namespaced ID.
The standard dimensions in the minecraft namespace are "overworld", "the\_nether", and "the\_end".
Result
Error if the argument is not specified correctly.
Example
Looking for an end city in the end (can find even though players is in the overworld):`execute **in the\_end** run locate EndCity`
Transport player to the nether with coordinates unchanged: `execute **in the\_nether** run teleport ~ ~ ~`
-positioned
Use either the given coordinates or the targeted entity's coordinates for the execution position. Changes the function of `^?T ^?N ^?B` and `~?x ~?y ~?z` positioning. Does not change rotation, dimension, or executor.

Syntax
`positioned <pos> -> *execute*`
`positioned as <targets> -> *execute*`
Arguments
`<targets>`
Specifies the target(s). Must be a player name, a target selector or a UUID
Permits entities other than players.
`<pos>`
Must be in form of `<x> <y> <z>`. May use tilde and caret notation.
Result
Error if the argument is not specified correctly.
Terminates if `<targets>` fails to resolve to one or more valid entities (named players must be online).
When multiple entities are selected, next subcommand is executed once each per execution position.
Example
Look for a village near (0, 64, 0): `execute **positioned 0 64 0** run locate Village`
Let all sheep move one block in the direction of the executor's rotation (for example, when the executor looks east, the sheep moves one block eastward; when the executor looks up, the sheep moves one block upward): `execute as @e[type=sheep] **positioned as @s** run tp @s ^ ^ ^1`
-rotated
Change the execution rotation to rotating either in the given direction or the same the targeted entity is facing.

Syntax
`rotated <rot> -> *execute*`
`rotated as <targets> -> *execute*`
Arguments
`<rot>`
Specifies the rotation. In form of `<horizontal rotation> <vertical rotation>`
For the horizontal rotation, -180.0 for due north, -90.0 for due east, 0.0 for due south, 90.0 for due west, to 179.9 for just west of due north, before wrapping back around to -180.0.
For the vertical rotation, -90.0 for straight up to 90.0 for straight down.
Tilde notation can be used to specify a rotation relative to the current execution rotation.
Result
Error if the argument is not specified correctly.
Terminates if `<targets>` fails to resolve to one or more valid entities (named players must be online).
When multiple entities are selected, next subcommand is executed once each per execution rotation.
Example
Move every sheep 1 block toward the player closest to it: `execute as @e[type=sheep] at @sORpositioned as @s **rotated as @p** run tp @s ^ ^ ^1`

#### Condition subcommands

-Syntax and arguments
`(if|unless) block <pos> <block> -> [*execute*]`

Compares the block at the given position to the given block ID.
* `<block>`
Specifies a block ID or a block tag, following block states and data tags if needed. See Command#ID arguments in Java Edition.

`(if|unless) blocks <start> <end> <destination> (all|masked) -> [*execute*]`

Compare region between the <start> and <end> positions to the area starting at the <destination> position. The calculation of the areas as well as the `(all|masked)` argument work in the same way as they do in the `/clone` command.
* `<start>`, `<end>`, and `<destination>`
Specifies the coordinates of the two diagonal corner of source region and the coordinates of the northwest lower corner of destination region.
Must be in form of `<x> <y> <z>`. May use tilde and caret notation.
* `all`
Compare all the blocks in regions.
* `masked`
Ignore the position where is air in the source region.

`(if|unless) data (block <pos>|entity <target>|storage <source>) <path> -> [*execute*]`

Check whether the targeted block, entity or storage has any data for the tag named by <path>.
* `<path>`
Specifies an NBT path to check for.

`(if|unless) entity <targets> -> [*execute*]`

Check whether one or more <targets> exist.
* `<targets>`
Specifies the target(s). Must be a player name, a target selector or a UUID
Permits entities other than players.

`(if|unless) predicate <predicate> -> [*execute*]`

Check whether the <predicate> evaluates to a positive result.
See Predicate for more information on predicates

Check whether the target entity's score accurately relates to source entity's score, given some conditional operator.
`(if|unless) score <target> <targetObjective> matches <range> -> [*execute*]`

Check whether the target entity's score is within given range (e.g. `1`, `1..5`).
-General arguments
`<pos>`
Specifies the coordinates of a block to check.
Must be in form of `<x> <y> <z>`. May use tilde and caret notation.
`<target>`
Specifies a single score holder, which can be a player name, a target selector or `*`(commands fails).
`<targetObjective>`
Specifies a scoreboard objective.
-Result
Error if the argument is not specified correctly.
When not at the end of the subcommands chain, Only if the condition tests pass is the subcommand following it executed. If it is executed multiple times by multiple variables (e.g. excuetors, execution positions, execution rotations), it acts as a variable filter - Only the variable that matches the condition executes the next subcommand.
When at the end of the subcommands chain, it checks whether the condition is met and then outputs.
-Example
* Kill all players standing on a wool: `execute as @a at @s **if block ~ ~-1 ~ #wool** run kill @s`
* Check whether your own score a and b are equal: `execute if score @s a = @s b`

#### Store subcommands

Store the `success` and a `result` value of a command somewhere.

It first records the location to store in, and then stores in the location after all the commands are executed.

Note that the return values of commands must be an integer. If a decimal, it is rounded down.

-Syntax

Saves the return value in block entity at the given position. Store as a byte, short, int, long, float, or double. If the return value is a decimal, it is rounded first and then multiplied by <scale>.
`store (result|success) bossbar <id> (value|max) -> *execute*`

Saves the return value in either the current value or the maximum value of the given bossbar.

Use the data tag `path` from one targeted entity to save the return value. Store as a byte, short, int, long, float, or double. If the return value is a decimal, it is rounded first and then multiplied by <scale>.
Like the "`/data`" command, "/execute store <arguments>" cannot modify player NBT.
`store (result|success) score <name> <objective> -> *execute*`

Use the scoreboard under <name> and <objective> to save the return value.

Uses the <path> within storage <target> to store the return value in. Store as a byte, short, int, long, float, or double. If the return value is a decimal, it is rounded first and then multiplied by <scale>.
If the storage does not yet exist, it gets created.
-Arguments
`<pos>`
Specifies the coordinates of a block entity to store.
Must be in form of `<x> <y> <z>`. May use tilde and caret notation.
`<path>`
Specifies an NBT path to store return value in.
`<id>`
ID of the bossbar to store return value in.
`<target>` in `entity` mode
Specifies a single entity, which can be a player name, a target selector or a UUID.
`<name>`
Specifies a score holder, which can be a player name, a target selector or `*`.
`<objective>`
Specifies a scoreboard objective.
`<target>` in `storage` mode
Target storage container, as a namespaced ID.
-Result
Error if the argument is not specified correctly.
In `block` and `entity` mode, does not store anything when the path does not exist.
#### `run` subcommand

Specifies the command to be executed, the variables of which may be modified by the subcommands used.

-Syntax
`run <*command*>`

-Arguments
`<*command*>`

Can be any command
*Technical:* Resets the command node to the root of the command dispatcher
Information on modelling commands as chat text:
* The *command dispatcher* is what starts when the player begins a message with a forward-slash (`/`).
* A *command node* is the specific word/entry the cursor is editing, either a command or an argument.
* The *root node* comes before the first word in the current command.

-Result
Execute this command. Fails if `<*command*>` is failure.

-More examples
* Teleport all players who have an item enchanted with Efficiency in their first hotbar slot to coordinates (0, 64, 0):
`/execute as @a if data entity @s Inventory[{Slot:0b}].tag.Enchantments[{id:"minecraft:efficiency"}] run tp @s 0 64 0`
* Create a smoke particle three blocks in front of all players:
`/execute at @a anchored eyes run particle smoke ^ ^ ^3`
* Place a saddle on pigs located within 5 blocks of the executing player, and remove saddles from pigs located over 5 blocks away from the executing player:
`/execute as @e[type=pig] at @s store success entity @s Saddle byte 1 if entity @p[distance=..5]`
* Make a player say "My feet are soaked!" in chat if they are located in a block of water:
`/execute as @a at @s if block ~ ~ ~ water run say "My feet are soaked!"`
* Make a player say "Score is reset" in chat if the score 'test' is not set, eg by doing "scoreboard players reset @s test":
`/execute as @a unless score @s test = @s test run say "Score is reset"`

### {MC-BedrockSürümü için:}

Syntax
`execute <origin: target> <position: x y z> <command: command>`
An alternate syntax allows the command to be executed only if a specific block is detected:
`execute <origin: target> <position: x y z> detect <detectPos: x y z> <block: Block> <data: int> <command: command>`
-Arguments
`origin: target`

Specifies the target to be the command's executor. Must be a player name or target selector. If more than one entity is selected, the command is run once as each of them.
`position: x y z`

Specifies the position from which to run the command. Coordinates specified with tilde and caret notation are relative to the target, not to the position of the command's execution.
`command: command`

Specifies the command to be run. Must be a valid command.
`detectPos: x y z`

Specifies the position of the block to check. May use tilde and caret notation to specify distances relative to `position: x y z`.
`block: Block`

Specifies the block ID that the block at detectPos, must match for the command to run. Must be a valid block ID.
`data: int`

Must be a valid block data for that type of block or `-1` to match any block data.
-Result
Fails if arguments are not specified correctly, if `origin: target` fails to resolve to one or more valid entities (named players must be online), if the checked block is not of the correct block id, data or state, or if the specified command fails.

On success, executes the specified command as if executed by the specified target(s), done with operator-level permission at the specified coordinate.

-Examples
* To summon lightning bolts at the positions of every zombie:
`execute @e[type=zombie] ~ ~ ~ summon lightning_bolt`
* To summon lightning bolts at the positions of every zombie standing on any type of sand:
`execute @e[type=zombie] ~ ~ ~ detect ~ ~-1 ~ minecraft:sand -1 summon lightning_bolt`
* To summon 10 creepers at the nearest player's position (only works as long as there are at least 10 entities in the loaded world):
`execute @e[c=10] ~ ~ ~ execute @p ~ ~ ~ summon creeper ~ ~ ~`

-History

## `/experience veya /xp`

Adds or removes player experience.

-Syntax
* **Java Edition**

`experience add <targets> <amount> [levels|points]`
`experience set <targets> <amount> [levels|points]`
`experience query <targets> (levels|points)`
`xp add <targets> <amount> [levels|points]`
`xp set <targets> <amount> [levels|points]`
`xp query <targets> (levels|points)`
* **Bedrock Edition**

`xp <amount: int> [player: target]`
`xp <amount: int>L [player: target]`
-Arguments
`<amount>` (BE: `amount: int`)

Specifies the amount of experience to give to the player. This amount may represent either an amount of points or an amount of levels.
If an `L` is added to the end, adds levels instead[*Bedrock edition only*].
Bedrock Sürümü sürümünde:
If the amount is expressed in points, it must be between 0 and 2,147,483,647 (inclusive, without the commas).
If the amount is expressed in levels, it must be between -2,147,483,648 and 2,147,483,647 (inclusive, without the commas).
*Java Sürümü* sürümünde:
For `experience add` and `xp add`, it must be between -2,147,483,648 and 2,147,483,647 (inclusive, without the commas).
For `experience set` and `xp set`, it must be between 0 and 2,147,483,647 (inclusive, without the commas).
Negative values remove experience instead of adding them.
`<targets>` (BE: `player: target`)

Specifies the target of the command. If not specified, defaults to the command's executor. Not optional in command blocks.
Entities other than players are not allowed.
-Result
Fails if arguments are not specified correctly, or if `<targets>` fails to resolve to one or more online players.

On success, adds/removes experience or adds/removes levels. Total experience and levels are not reduced below 0.

-Examples
* To display Steve's current level: `experience query Steve levels`[*Java edition only*]
* To give 7 experience to yourself: `xp 7`[*Bedrock edition only*] or `experience add @s 7`[*Java edition only*]
* To give 3 levels to Alice: `xp 3L Alice`[*Bedrock edition only*] or `xp add Alice 3 levels`[*Java edition only*]
* To remove all levels from all players: `xp -2147483648L @a`[*Bedrock edition only*] or `xp set @a 0`[*Java edition only*] or `xp set @a 0 levels`[*Java edition only*]

-History

## `/fill`

Fills all or parts of a region with a specific block.

-Syntax
* **Java Edition**

The fill command also has an optional alternate syntax when using the `replace` option:
`fill <from> <to> <block> replace [<filter>]`
* **Bedrock Edition**

`fill <from: x y z> <to: x y z> <tileName: Block> [tileData: int] [oldBlockHandling: FillMode]`
The fill command also has an optional alternate syntax for `replace` mode:
`fill <from: x y z> <to: x y z> <tileName: Block> <tileData: int> replace [replaceTileName: Block] [replaceDataValue: int]`
-Arguments
`<from>` and `<to>` (BE: `from: x y z` and `to: x y z` )

Specifies any two opposing corner blocks of the region to be filled (the "fill region"). May use tilde and caret notation to specify distances relative to the command's execution.
The blocks that make up the corners extend in the positive direction from the coordinates used to identify them. Because of this, the lesser coordinates of each axis are on the region boundary, but the greater coordinates are one block from the boundary, and the block volume of the source region is (xgreater - xlesser + 1) × (ygreater - ylesser + 1) × (zgreater - zlesser + 1). For example, `0 0 0 0 0 0` has a 1-block volume, and `0 0 0 1 1 1` and `1 1 1 0 0 0` both identify the same region with an 8-block volume.
`<block>` (Bedrock: `tileName: Block`)

Specifies the block to fill the region with. Must be a block ID.
`tileData: int`[*Bedrock edition only*]

Specifies the block data to use for the fill block. Must be an integer between 0 and 65535 (inclusive), but values that are invalid for the specified item id revert to 0. If not specified, defaults to 0.

* `destroy` - Replaces all blocks (including air) in the fill region with the specified block, dropping the existing blocks (including those that are unchanged) and block contents as entities as if they had been mined with an unenchanted diamond shovel or pickaxe. (Blocks that can be mined only with shears, such as vines, do not drop; neither do liquids.)
* `hollow` - Replaces only the blocks on the outer edge of the fill region with the specified block. Inner blocks are changed to air, dropping their contents as entities but not themselves. If the fill region has no inner blocks (because it is smaller than three blocks in at least one dimension), acts like `replace`.
* `keep` - Replaces only the air blocks in the fill region with the specified block.
* `outline` - Replaces only the blocks on the outer edge of the fill region with the specified block. Inner blocks are not affected. If the fill region has no inner blocks (because it is smaller than three blocks in at least one dimension), acts like `replace`.
* `replace` - Replaces all blocks (including air) in the fill region with the specified block, without dropping blocks or block contents as entities. Optionally, instead of specifying a data tag for the replacing block, block ID and data values may be specified to limit which blocks are replaced (see *replaceTileName* and *replaceDataValue* below)

If not specified, defaults to `replace`.
`<filter>` (Bedrock: `replaceTileName: Block` and `replaceDataValue: int`)

Arguments are valid only for `replace` mode.
Specifies the ID of the blocks in the fill region to be replaced. Bedrock Sürümü sürümünde, if *replaceDataValue* is not specified, data value is ignored when determining which blocks to replace; if both arguments are not specified, replaces all blocks in the fill region.
-Result
Fails if the arguments are not specified correctly, if the fill region is not loaded, if the block volume of the fill region is greater or equal to 32768, if `tileData` are invalid for the specified block id, or if no blocks were changed.

On success, changes blocks in the fill region to the specified block.

-Examples
* `/fill 52 63 -1516 33 73 -1536 minecraft:gold_block replace minecraft:orange_glazed_terracotta`[*Java edition only*]
* `/fill 52 63 -1516 33 73 -1536 gold_block 0 replace orange_glazed_terracotta`[*Bedrock edition only*]
	+ Replaces all the orange stained glazed terracotta in the selected area with gold blocks.
* `/fill ~-3 ~-3 ~-3 ~3 ~-1 ~3 water`
	+ Replaces the blocks in a 7x7x3 cube directly beneath the command execution's location with water.
* `/fill ~-3 ~ ~-4 ~3 ~4 ~4 minecraft:stone hollow`[*Java edition only*]
* `/fill ~-3 ~ ~-4 ~3 ~4 ~4 stone 0 hollow`[*Bedrock edition only*]
	+ Creates a house-sized box around the command execution's location, replacing any blocks that would have been inside the box with air.
* `/fill ~-15 ~-15 ~-15 ~15 ~15 ~15 stone`
	+ Creates a solid cube of stone centered on the command execution's location.

-History

**Bu madde bir taslaktır.**
İçeriği genişleterek yardımcı olabilirsin.

## `/forceload`

Force chunks to load constantly or not, `forceload add`, `forceload query` and `forceload remove` are three separated commands.

-Syntax
`forceload add <from> [<to>]`
`forceload remove <from> [<to>]`
`forceload remove all`
`forceload query [<pos>]`
-Arguments
`<from>`, `<to>`

Specifies the selected chunks, with a form of `<x> <z>`.
`<pos>`

Specifies the chunk to query, with a form of `<x> <z>`.
-Result
Fails if the arguments are not specified correctly, or if the specified chunk isn't force loaded in `query <pos>` mode,

On success:

* `add` – forces the chunk at the `<from>` position (through to `<to>` if set) in the dimension of the command's execution to be loaded constantly.
* `remove` – unforces the chunk at the `<from>` position (through to `<to>` if set) in the dimension of the command's execution to be loaded constantly.
* `remove all` – unforces all chunks in the dimension of the command's execution to be loaded constantly.
* `query` – if chunk coordinates are given, says the specified chunk in the dimension of the command's execution is force loaded; otherwise, lists which chunks in the dimension of the command's execution are force loaded.

Forced chunks get load ticket with load level of 31, the same as ticket chunks get by being in player's chunk loading distance, which means that the said chunk processes all aspects of the game while adjacent chunks get activated by the load level's spread but since it increases its load level each time, adjacent chunks don't process every aspect of the game as well. See also chunk.

-Notes
* Coordinates are actually block coordinates. In order to forceload chunks 0,0 to 1,2, the player should use `/forceload add 0 0 31 47`, which loads chunks 0,0 to 1,2 (1,2 inclusive, 2 x 3 chunks).
* When using `/forceload add 0 0 10 30` chunks 0,0 to 0,1 are actually loaded (one chunk equals 16x16 blocks on x/z axis). However, `/forceload query` gives result in chunk coordinates.

-History

## `/function`

Runs commands founds in the corresponding function file.

*Java Sürümü* sürümünde, runs a function or all functions in a tag from a datapack.

Bedrock Sürümü sürümünde, Runs a function from a behavior pack.

-Syntax
* **Java Edition**

`function <name>`
* **Bedrock Edition**

`function <name: filepath>`
-Arguments
<name> (BE: name: filepath)

*Java Sürümü* sürümünde:
May be of the format `namespace:path/to/function/file`, or `#namespace:path/to/function/tag`.
The format without the `#` prefix, `namespace:path/to/function/file`, runs a single function located at `[data_pack]/data/namespace/functions/path/to/function/file.mcfunction`.
The format with the `#` prefix, `#namespace:path/to/function/tag`, runs all functions included in the function tag located at `[data_pack]/data/namespace/tags/functions/path/to/function/tag.json`.
Bedrock Sürümü sürümünde:
May be of the format `path/to/function/file`
Runs the function located at `[behavior_pack]/functions/path/to/function/file.mcfunction`
-Result
Fails if the argument is not specified correctly.

If successful, runs a function through the command source which ran the `/function` command.

*Java Sürümü* sürümünde:
Success count is the sum of success counts of all commands ran in the function/functions plus 1 (this command itself).
For example,
`**foo:bar1**`
`function foo:bar2`
`**foo:bar2**`
`function foo:bar3`
`**foo:bar3**`
`say hi`
The Success count of `/function foo:bar3` is 1 (one command in foo:bar3) + 1 (this command itself) = 2.
The Success count of `/function foo:bar2` is 2 (from above) + 1 (this command itself) = 3.
The Success count of `/function foo:bar1` is 3 (from above) + 1 (this command itself) = 4.
Output of the command returns the number of commands ran (not the number of commands that succeed) plus the number of embedded functions called by a function.
The output count of `/function foo:bar3` is 1(one command in foo:bar3).
The output count of `/function foo:bar2` is 1 (one command in foo:bar2) + 1 (one command in foo:bar3) + 1 (one embedded function) = 3.
The output count of `/function foo:bar1` is 1 (one command in foo:bar1) + 1 (one command in foo:bar2) + 1 (one command in foo:bar3) + 2 (two embedded function) = 5.
If successful, `/execute store success` always returns 1. Otherwise, returns 0.
If successful, the return value of `/execute store result` is the same as output count. Otherwise, returns 0.
-Examples
* *Java Sürümü* sürümünde:
	+ To run a function located at `data/custom/functions/example/test.mcfunction` in a loaded data pack: `/function custom:example/test`
	+ To run all functions in a function tag located at `data/custom/tags/functions/example/test.json`: `/function #custom:example/test`
	+ To run a function if there is a sheep within a radius of 2 blocks: `/execute if entity @e[type=sheep,distance=..2] run function custom:example/test`
	+ To run a function unless the executor is a player: `/execute unless entity @s[type=player] run function custom:example/test`

-History

## `/gamemode`

Sets a player's game mode.

-Syntax
* **Java Edition**

`gamemode [adventure|creative|spectator|survival] [<target>]`
* **Bedrock Edition**

`gamemode <gameMode: GameMode> [player: target]`
An alternate syntax allows player to enter game mode by its number:
`gamemode <gameMode: int> [player: target]`
-Arguments
`adventure|creative|spectator|survival` (BE: `gameMode: GameMode` or `gameMode: int`)

Must be one of:
* `survival` (can be abbreviated as `s` or `0` Bedrock Sürümü sürümünde) for survival mode
* `creative` (can be abbreviated as `c` or `1` Bedrock Sürümü sürümünde) for creative mode
* `adventure` (can be abbreviated as `a` or `2` Bedrock Sürümü sürümünde) for adventure mode
* `spectator` for spectator mode[*Java edition only*]

"hardcore" is not a valid option for the *mode* argument, as it is technically not a game mode.
`<target>` (BE: `player: target`)

If specified, must be either a player's username or a target selector. If unspecified, defaults to the player using the command. When used in a command block, it is not optional.
Entities other than players are not allowed.
-Result
Fails if the arguments are not specified correctly, or if `<target>` fails to resolve to one or more online players.

On success, changes the game mode of the default or specified players.

-Examples
* To put the executing player into creative mode:
`gamemode creative`
`gamemode c`[*Bedrock edition only*]
`gamemode 1`[*Bedrock edition only*]

* To put all players into survival mode
`gamemode survival @a`

-History

## `/gamerule`

**It has been suggested that the contents of this page be split into two or more separate articles.** [discuss]
The topics presented on this page may be diverse enough to warrant distinct pages.
*Reason: Game rule*

Sets or queries a game rule value.

-Syntax
* **Java Edition**

`gamerule <*rule name*> [<value>]`
* **Bedrock Edition**

`gamerule <rule: BoolGameRule> [value: Boolean]`
`gamerule <rule: IntGameRule> [value: int]`
Bedrock Sürümü sürümünde, gamerules can also be changed in the world options and certain gamerules can be toggled on and off with the command without cheats enabled. This only works in singleplayer, server gamerules and server settings cannot be adjusted using the client settings, even if a player is opped.
-Arguments
Arguments *Java Sürümü* sürümünde are case sensitive. Arguments Bedrock Sürümü sürümünde are shown for tab autocompletion as lowercase, but when typed are case-insensitive.

`<*rule name*>` (BE: `*rule*: BoolGameRule` or `*rule*: IntGameRule`)

Specifies the game rule to set or query. Must be one of predefined game rules in the table below.
`<*value*>` (BE: `*value*: Boolean` or `value: int`) (optional)

Specifies the value to set the game rule to. Only `true` or `false` specified for predefined game rules can affect gameplay, except in the case of `maxEntityCramming`, `randomTickSpeed`, `spawnRadius`, and `maxCommandChainLength` where any integer 0 or greater affects gameplay (see the table below).Şablon:Needs testing

Total Gamerules

BE: 26

JE: 33

-Additional behavior

**Bu madde bir taslaktır.**
İçeriği genişleterek yardımcı olabilirsin.

This section explains more complex behaviors of certain gamerules.

* `disableRaids`
	+ When true, the Bad Omen effect is not removed from a player when entering a village.
	+ Stops a raid if set to true while a raid is in progress, but the existing raid mobs do not despawn.
* `doEntityDrops`
	+ When false, items cannot be removed from item frames.
* `doMobSpawning`
	+ Affects only natural mob spawning. Mobs from structures, spawners, and events still spawn when set to false.
* `doTileDrops`
	+ When false, containers still drop their contents, but not themselves.
		- Shulker boxes do not drop anything, causing the items in them to be lost.
	+ When false, destroying an armor stand does not drop it nor any armor it had equipped.
	+ When false, item frames still drop themselves and their items.
* `drowningDamage`
	+ When false, the player still loses air, but does not take damage when the air is depleted.
* `keepInventory`
	+ When true, players also retain their experience upon death.
	+ When true, health and hunger are still reset as normal upon death.
* `mobGriefing`
			* Trampling crops.
			* Picking up items.
		- Blazes from creating fire or lighting campfires.
		- Creepers from destroying blocks when they explode, although they still damage entities.
		- The ender dragon from destroying blocks, causing it to just fly through them instead.
		- Endermen from picking up or placing blocks.
		- Foxes from picking sweet berries from a sweet berry bush.
		- Ghast fireballs from exploding blocks and creating fire. They still damage entities.
		- Piglins from attempting to barter.
		- Rabbits from eating carrot crops.
		- Ravagers from destroying crops and leaves.
		- Sheep from turning grass blocks into dirt, but does not prevent the regrowth of wool. They still act as if they are eating the grass and regrow their wool upon doing so, but the grass remains and the grass breaking sound does not play.
		- Snow golems from creating snow trails.
		- Villagers from farming and picking up items. However, they can still open doors and throw items.
		- The wither and its heads from destroying blocks with their explosions. Entities are still damaged, and a wither rose drops as an item.
		- Zombies from breaking doors.
	+ Has no effect on the player.
* `universalAnger`
	+ Bees attack all nearby players when their beehive is broken, regardless of the setting of this gamerule.
		- Bees becoming angry when attacked works as expected.

-Result
Fails if the arguments are not specified correctly.

On success, returns the value of the game rule (if `<value>` is not provided) or sets the game rule to the specified value (if `value` is provided).

-Examples
* To stop the day-night cycle: `gamerule doDaylightCycle false`
* To stop natural healing: `gamerule naturalRegeneration false`
* To stop creepers, ghasts and other mobs from modifying blocks: `gamerule mobGriefing false`
* To stop the natural cycle of weather: `gamerule doWeatherCycle false`
* For the player, so that they can keep all of their valuables when they die: `gamerule keepInventory true`
* To stop TNT from exploding:[*Bedrock edition only*] `gamerule tntExplodes false`

-History

## `/give`

Gives an item to one or more players.

-Syntax
* **Java Edition**

`give <target> <item> [<count>]`
* **Bedrock Edition**

`give <player: target> <itemName: Item> [amount: int] [data: int] [components: json]`
-Arguments
`<target>` (BE: `player: target`)

Specifies the target to give item(s) to. Must be a player name or target selector.
Entities other than players are not allowed.
`<item>` (BE: `itemName: Item`)

Specifies the item to give. Must be a valid item ID, or block ID for which items exist.
`<count>` (BE: `amount: int`)

Specifies the number of items to give. Must be between 1 and 2,147,483,647[*Java edition only*] / 32767[*Bedrock edition only*] (inclusive). If not specified, defaults to `1`.
`data: int`[*Bedrock edition only*]

Specifies the item data value of the given item(s). Must be an integer between 0 and 32767 (inclusive), but values that are invalid for the specified item id revert to 0. If not specified, defaults to 0.
`components: json`[*Bedrock edition only*]

Specifies the item components of the given item(s). Like data tags but supports only `minecraft:can_place_on` and `minecraft:can_destroy` functions (for example, `/give @p iron_shovel 1 0 {"minecraft:can_destroy":{"blocks":["grass"]}}`)
-Result
Fails if the arguments are not specified correctly, or if `<target>` fails to resolve to one or more online players.

On success, summons the specified item(s) at the location(s) of the target(s). If *player* resolves to multiple targets, each receives the specified number of items. If there is room in the player's inventory, or the player is in creative mode, the item entity summoned is "fake", with its `PickupDelay` tag set to `32767` and its `Age` tag set to `5999`, which would normally make it impossible to pick up the item, and have it despawn within a tick. If the player's inventory is full and they are not in creative mode, the item entity's `Owner` tag is set to the target and its `PickupDelay` tag set to `0` so that it can be picked up only by that player until within 10 seconds of it despawning, at which time other players may pick it up.

-Examples
* To give the nearest player a diamond sword with Lore that says "A legendary weapon":
	+ `/give @p minecraft:diamond_sword{display:{Lore:["\"A legendary weapon\""]}} 1`[*Java edition only*]
* To give all players a potion that has the Night Vision effect:
	+ `/give @a potion{Potion:"minecraft:night_vision"} 1`[*Java edition only*]
* To give a random player a Sharpness X diamond sword:
	+ `/give @r diamond_sword{Enchantments:[{id:"minecraft:sharpness",lvl:10}]} 1`[*Java edition only*]
* To give Steve a block of diamond that can be placed on dirt and can break quartz blocks even in adventure mode.
	+ `/give Steve minecraft:diamond_block{CanPlaceOn:["minecraft:dirt"],CanDestroy:["minecraft:quartz_block"]} 1`[*Java edition only*]
	+ `/give Steve minecraft:diamond_block 1 0 {"minecraft:can_place_on":{"blocks":["dirt"]},"minecraft:can_destroy":{"blocks":["quartz_block"]}}`[*Bedrock edition only*]
* To give all players a level 2 Wither Potion with Knockback X:
	+ `/give @a potion{Enchantments:[{id:"minecraft:knockback",lvl:10}],CustomPotionEffects:[{Id:20,Amplifier:1}]} 1`[*Java edition only*]

-History

**Bu madde bir taslaktır.**
İçeriği genişleterek yardımcı olabilirsin.

## `/help`

Provides help/lists of commands.

-Syntax
* **Java Edition**

`help [<command>]`
* **Bedrock Edition**

`help [command: CommandName]`
`help <page: int>`
-Arguments
`<command>` (BE: `command: CommandName`)

Specifies the command to provide help for. *Java Sürümü* sürümünde, entering more specific parameters of that command is allowed.
`page: int`[*Bedrock edition only*]

Specifies the page number of the command list. Must be an integer between -2147483648 and 2,147,483,647 (inclusive, without the commas), but numbers less than 1 or greater than the total number of pages are treated as 1 or the last page accordingly.
-Result
Fails if `page: int` is not a valid page number, or if <command> is not a valid command name.

On success, displays a page of the command list. Multiplayer commands are not displayed while in singleplayer, even when open to LAN players.

If a valid command name was specified, displays the usage for that command. *Java Sürümü* sürümünde, for some complicated commands may show only the basic usage; additional information can be supplied by entering more specific parameters of that command.

-Examples
* To display (the first page of[*Bedrock edition only*]) the command list: `/help`.
* To display the usage for the `/give` command: `/help give`.
* To display the usage for the `add` section of the `/scoreboard` command: `/help scoreboard add`.

-History

## `/immutableworld`

Toggles the world to be able altered or cannot be altered.

-Syntax
`immutableworld [*value: bool*]`
-Arguments
*value: bool* (optional)
Specifies the value to set the world to be able altered, must in between `true` or `false`.
-Result
Fails if user is not an operator.

On success, if `true` the world cannot be altered, but doors, levers, etc. can still be used, and vice versa if set to `false`.

-History

## `/kick`

Kicks a player off the server.

-Syntax
* **Java Edition**

`kick <target> [<reason>]`
* **Bedrock Edition**

`kick <name: target> <reason: message>`
-Arguments
`<targets>` (BE: `player: target`)

Must be a player name or a target selector.
Entities other than players are not allowed.
`<reason>` (BE: `reason: message`)

A string that does not require quotation marks and can contain spaces.
-Result
Fails if `<targets>` is not online.

Fails if `<targets>` is the host of the server.[*Bedrock edition only*]

In success, forcibly disconnects `<targets>` from the server, displaying an optional `<reason>` to them.

-History

## `/kill`

Kills entities (players, mobs, items, etc.).

-Syntax
**Java Edition**

`kill [<targets>]`
**Bedrock Edition**

`kill [target: target]`
-Arguments
`<targets>` (BE: `target: target`)

Specifies the target(s) to be killed. Must be a player name, a target selector, or a UUID[*Java edition only*].
If not specified, defaults to the executor who executed the command. Not optional if executor isn't an entity.
Permits entities other than players (including "non-living" entities like items, minecarts, etc.).
-Result
Fails if `<targets>` fails to resolve to one or more entities (named players must be online), or if the targeted player is in Creative mode Bedrock Sürümü sürümünde[*verify*].

On success, directly kills non-living targets, even if they are protected by a high-level Resistance effect or by a totem of undying, and issues the appropriate death message. Players and mobs killed this way drop loot, and slimes and magma cubes that are not already of minimum size spawn smaller ones. Destroys boats, minecarts, loose items and experience orbs if they are targeted.

-Examples
* To kill the player executing the command: `kill @s`
* To kill the player Steve: `kill Steve`
* To kill item entities: `kill @e[type=item]`
* To kill all entities within 10 blocks: `kill @e[distance=..10]`
* To kill all entities except players: `kill @e[type=!player]`

-History

## `/list`

Lists players on the server.

-Syntax
* **Java Edition**

`list`
`list uuids`
* **Bedrock Edition**

`list`
-Arguments
`uuids`[*Java edition only*]

In Java Edition, if 'uuids' is specified, player UUIDs are shown alongside names.
-Result
Always succeeds.

Shows the names of all currently-connected players (the same can be achieved when pressing `Tab ↹`).
-History

## `/locate`

Displays the coordinates for the closest generated structure of a given type in the chat for the player who executed the command.

-Syntax
* **Java Edition**

`locate <*StructureType*>`
* **Bedrock Edition**

`locate <feature: Feature>`
-Arguments
`<*StructureType*>` (BE: `feature: Feature`)

Specifies the structure to locate. Must be one of the following:

*Java Sürümü* sürümünde, the structure type is case-sensitive.
-Result
Fails if the arguments are not specified correctly, or if unable to locate the requested feature (for example, if it's in a different dimension).

If successful, displays the coordinates for the closest structure of the given type in the chat, for the player who executed the command. Displays the Y coordinate as `(y?)` for some structures. (All structures Bedrock Sürümü sürümünde)

-Examples
* To obtain the coordinates of the nearest woodland mansion: `/locate mansion`

-History

## `/locatebiome`

Displays the coordinates for the closest biome of a given biome ID in the chat for the player who executed the command.

-Syntax
`locatebiome <*biome ID*>`
-Arguments
<*biome ID*>
Specifies the biome to be located. See Biome/ID for a list of available biome IDs.
-Result
Searches for the nearest coordinates where the given biome would be generated using the current seed in the current version of Minecraft, ignoring existing terrain that may have different biomes.

Fails if the arguments are not specified correctly, or if unable to locate the requested biome (for example, if the dimension does not generate a given biome).

* If the biome is invalid, the following error message is given: "*There is no biome named <Biome ID>*"

* If the biome is valid but cannot be found, the following error message is given: "*Could not find a biome of type <Biome Name> within reasonable distance*"

If successful, the following message is sent to chat: "*The nearest <biome name> is at [<x> ~ <z>] (<distance> blocks away)*". The coordinates can be clicked, which will put the command `/tp @s <x> ~ <z>` in the chat box. The command can then be executed, and the player will be sent to those coordinates.

-Example
* To obtain the coordinates of the nearest desert:
`locatebiome desert`

-History

## `/loot`

Drops the given loot table into the specified inventory or into the world.

-Syntax
`loot <*target*> <*source*>`
`<*target*>`:
`spawn <targetPos>`
`replace entity <entities> <slot> [<count>]`
`replace block <targetPos> <slot> [<count>]`
`give <players>`
`insert <targetPos>`
`<*source*>`:
`fish <loot_table> <pos> [<tool>|mainhand|offhand]`
`loot <loot_table>`
`kill <target>`
`mine <pos> [<tool>|mainhand|offhand]`
-Arguments
`<loot_table>`

Specifies which loot table to use.
`<targetPos>` or `<pos>`

Specifies the position of a block or location in the dimension where item drops. May use tilde and caret notation to specify a position relative to the command's execution.
`<players>`

Specifies one or more players to give. Must be a player name or a target selector.
Entities other than players are not allowed.
`<entities>`

Specifies one or more entities to modify. Must be a player name, a target selector, or a UUID.
Permits entities other than players.
`<slot>`

Specifies the inventory slot to be modified. Valid values depend on whether a block or an entity is being modified.
**For blocks**, must be `container.<slot_number>` where <slot\_number> is replaced with a number specifying the slot.
* Chests, dispensers, droppers, hoppers, and trapped chests are numbered 0 for the top-left slot and then increase first horizontally, then vertically (so, for example, a chest's top row slots are numbered 0 to 8 from left to right). Double chests and double trapped chests are treated as two single container blocks.
* A brewing stand's bottom slots are numbered 0 to 2 from left to right, its top slot is 3 and the fuel slot is 4.
* A furnace's slots are numbered 0 for the input slot, 1 for the fuel slot, and 2 for the output slot.

Other blocks which hold items but don't have inventory GUIs (flower pots and jukeboxes) can be changed only with `/data`.
**For entities**, must be one of the following, where <slot\_number> is replaced with a number specifying the slot:

The inventory of an item frame can be changed only with `/data`.
`<count>`

Specifies the number of consecutive slots to be filled. Must be between 0 and 2147483647 (inclusive). If the target is a block, `<slot_number> + <count>` cannot exceed the greatest slot number.
`<tool>`

Specifies an tool to mine or fish. Must be an item ID or a block ID for which an item exists (for example, `minecraft:golden_sword`).
`<target>`

Specifies one entity to kill simulatively. Must be a player name, a target selector, or a UUID.
Permits entity other than players.
-Result
Fails if the arguments are not specified correctly or the specified source entity doesn't have a loot table (for example, players do not have loot tables).

On success, drops items from loot.

-History

1. ↑ https://bugs.mojang.com/browse/MC-148612
2. ↑ https://bugs.mojang.com/browse/MC-135636
3. ↑ https://twitter.com/henrikkniberg/status/1268765029777772549