Talk:Commands/Archive 2

From Minecraft Wiki
Jump to: navigation, search
This page is an archive of past discussions. Do not edit the contents of this page. 
If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Proper uses for the not function in target selectors

Does anyone have some sort of complete list of valid uses for the not function for the target selectors? It doesn't seem to ever work for any selectors that use numbers, such as @a[score_test=!1], as far as I can tell, but it does work with team names and player names, such as for @a[name=!name], @a[team=!RedRobins], or @e[type=!Player]

Is it completely restricted to selectors that aren't numbers? Kavukamaritalk 06:28, 2 January 2015 (UTC)

It's only available for string-based parameters, being limited to those you've listed. Skylinerw (talk) 14:36, 2 January 2015 (UTC)

Not accurate /kill description

The wiki page says the following about the kill command :

"On success, inflicts 1000 ((heart) × 500) void damage to targets "

To test that, I gave myself Health Boost 255 and healed myself completely, so I had 1044 hp, or 522 hearts (I checked it with the scoreboard), then used the /kill command.

Instead of putting me to 44hp, I died instantly.

This is what sould be expected from a "kill" command, but isn't what the page says.

I also noticed that /kill ignore absorbtion hearts, putting you at 0 normal heart without removing any of them (wich kills you anyway).

Tested on 1.8.1 in SinglePlayer. -- 21:12, 14 January 2015 (UTC)

Looks like this was changed in 1.6; instead of 1000 damage, it now does Float.MAX_VALUE, roughly 3.4 x 1038. -- Orthotopetalk 20:59, 14 January 2015 (UTC)
This is slightly off topic, but when the page says, "the appropriate death message," does it mean anything other than "Player fell out of the world"? I have never seen a different message from this command, but it sounds like there are multiple. SuperDyl19 (talk) 00:09, 12 December 2015 (UTC)
The kill command only produces one death message but localization can change it (different languages, pirate speak, etc.) which is not relevant to the command so we just link to the relevant article. See this old discussion. —munin · 16 px 16 px · 14:47, 13 December 2015 (UTC)

Achievement info

Just wondering when the "take" option was added to achievement. I'm in 1.7.10 and "/achievement give" is the only option. Was expecting to find it in the history section at least. WildBluntHickok (talk) 14:27, 19 January 2015 (UTC)

So you're playing in 1.7, and asking when the take option was added. I'm gonna go with "1.8" SuperStarWars237 (talk) 16:34, 6 July 2015 (UTC)

Inputting multiple commands at once.

Hi, so I have been playing around with the fill and set block commands to make relatively complex structures (like houses and castles) that can be made entirely by typing commands and so can be shared with friends and easily recreated in different worlds. However, this gets really laborious when they start to get complicated because every command has to be entered separately - this takes loads of time and has too much room for error in my liking. Is there a way to copy and paste a whole load of commands at once? Is there a notation I can use to separate them? or is there a mod that allows you to do this? Please let me know - I am bored to death of "ctrl c , open text, ctrl v, enter, ....." repeat til you're sick :(

Thank you!!! –Preceding unsigned comment was added by DragonzFriend (talkcontribs) at 16:36, 26 January 2015 (UTC). Please sign your posts with ~~~~

  1. Pressing and while in chat allows to scroll the chat’s input history, including commands, and these can be sent/run again with ↵ Enter. In other words, press then ↵ Enter to repeat last text written in chat.
  2. Running multiple commands at once requires multiple command blocks synced to a redstone circuit, or a bunch of other players, as long as they and you run the commands simultaneously.
  3. Please sign your comments with ~~~~. LauraFi added the “Preceding unsigned comment...” message using a template called {{t|AutoUnsigned}}. I may explain it later.
I’m Nick the Red37, f.k.a. Naista2002 16:53, 26 January 2015 (UTC)

thanks for your answer but I guess I wasn't very clear before, I was meaning that I want to copy and paste MULTIPLE DIFFERENT written commands from OUTSIDE minecraft (e.g. a text file) into ANY minecraft world and the issue I'm having at the moment is that this all has to be done one command at a time, which takes a long time when there are 50+ commands. I want to paste and enter them all in one go - do you want me to give an example?
Sorry for not signing before,
DragonzFriend (talk) 17:00, 26 January 2015 (UTC)
I don’t think it is possible in Minecraft at all. And, it is generally better to indent comments on talk pages. — I’m Nick the Red37, f.k.a. Naista2002 17:04, 26 January 2015 (UTC)
Ok :( thanks for your help :( DragonzFriend (talk) 17:06, 26 January 2015 (UTC)

Give Command May Not Work as Described

I'd make an edit on the main page myself, but I'm pretty bad with server commands and I wanted to make sure I was correct about this. The "Give" command's "item" parameter says it must be a valid item ID or block ID and gives the example "256" or "minecraft:iron_shovel". Is the former example still valid? In the past I could use give and use the numerical item ID, but now Minecraft seems to not accept numbers and require minecraft:iron_shovel instead. Alex3me0 (talk) 18:44, 20 February 2015 (UTC)

the former example is outdated, I've updated the page appropriately. KnightMiner (t·c) 18:52, 20 February 2015 (UTC)

Redo Table

The table is very bulky, missing command-block information, and poorly formatted. Here's an idea on how to change it:

Combine Op Only and Multiplayer Only into Restrictions. Combine Blocks, Players, Entities, and World into Alters.

Restrictions column:

No command blocks

If some of these restrictions don't apply for a command, use only the rows for the relevant restrictions. If none of these apply, type None.


  • None - White with black text
  • Operator - Cyan with cyan text
  • Multiplayer - Magenta with magenta text
  • No command blocks - Yellow with yellow text
  • Operator and Multiplayer - Blue with blue text
  • Operator and No command blocks - Green with green text
  • Multiplayer and No command blocks - Red with red text
  • Operator, Multiplayer, and No command blocks - Black with white text

Of course, the cell color should be lighter than the text itself except for white and black cells.



Only include the relevant ones. If it doesn't alter any blocks, write None.


  • White if None
  • Orange if Blocks
  • Magenta if Players
  • Light blue if Entities
  • Yellow if World
  • Lime if Blocks and Players
  • Pink if Blocks and Entities
  • Gray if Blocks and World
  • Light gray if Players and Entities
  • Cyan if Players and World
  • Purple if Entities and World
  • Blue if Blocks, Players, and Entities
  • Brown if Blocks, Players, and World
  • Green if Blocks, Entities, and World
  • Red if Players, Entities, and World
  • Black if Blocks, Players, Entities, and World

Wool colors (go figure) and same text color rules as Restrictions. 00:10, 28 March 2015 (UTC)

The table is a summary, it does not need to list command block restrictions as there are exceptions to the rule of "if multiplayer, no command blocks".
Combining restrictions might make sense, though having two columns state a little text compared to a lot of text in a single column is not needed KnightMiner t/c 02:47, 28 March 2015 (UTC)
The problem with combining things into a single column is that it makes it impossible to quickly sort by any one trait so that you quickly get all the commands which affect, say, Players, to the top of the table. That's mostly what i use the table for, personally. —munin · 16 px 16 px · 15:33, 28 March 2015 (UTC)

What about changing everything to Yes and No and adding Command Blocks? 21:26, 2 June 2015 (UTC)

Help with /clear command

Is it possible to do a clear command which clear an item without NBT tag, but will not clear the item with certain NBT tag? For example - it clears the bow without custom name, but it does not clear a bow with a certain custom name? 03:58, 15 April 2015 (UTC)

No, you would have to do a normal /clear command and give them back the bow. 00:35, 2 July 2015 (UTC)


When was /solid removed? 21:24, 2 June 2015 (UTC)

I'll put it on my todo list to investigate -- unless you want to use the launcher and figure it out before I do. – Sealbudsman (Aaron) frameless t/c 22:25, 2 June 2015 (UTC)
Just checking in: perusing the forums, it seemed to be available during Alpha Survival Singleplayer test, and not during Alpha Survival Multiplayer test, so sometime between July and November 2010. I'm sure I can nail it down a bit better than that though. – Sealbudsman (Aaron) frameless t/c 16:41, 3 June 2015 (UTC)
Also, what /solid does is not mentioned anywhere in the article. I found the description in the classic server README file, though: "Switches between placing normal and placing unbreakable stone". --Pokechu22 (talk) 23:53, 26 August 2015 (UTC)
I think that is somewhat self explainatory. Typing /solid cause placing stone to place bedrock instead, and typing it again restores the default placing of stone. KnightMiner t/c 03:43, 27 August 2015 (UTC)
I wouldn't consider that obvious enough to mean that it shouldn't be described in the article. Perhaps a "Removed commands" section would be useful? --Pokechu22 (talk) 16:17, 27 August 2015 (UTC)
 Describing done. – Sealbudsman talk/contr 19:08, 27 August 2015 (UTC)

/give isn't as new as release 1.3.1, it may date back to Alpha or prior

In 12w16a, a snapshot for release 1.3.1, there are listed several commands as being available for cheat mode: /gamemode, /toggledownfall, /time, /give, /xp, /kill. And that's reflected on this page.

But, I found an old forum post (that I stumbled across while investigating /solid) that indicates that /give was available at least during the time of the Alpha Survival Multiplayer test.

So did it move from being a multiplayer command to being a singleplayer command? For me, this throws the origin-date of all these commands into question, I will be putting this on my Todo list. – Sealbudsman (Aaron) frameless t/c 16:39, 3 June 2015 (UTC)

See also: Talk:Commands/Archive 2#/kill in classic. –LauraFi - talk 16:43, 3 June 2015 (UTC)
Thanks, Laura. Funny: that link has a link to a short exchange (User_talk:Dinoguy1000#Commands_like_.2Fgive) I had with Orthotope only 9 months ago, which I'd completely forgotten about. – Sealbudsman (Aaron) frameless t/c 16:58, 3 June 2015 (UTC)
As a point of reference, /give has been around since before this page was created. --timrem (talk) 15:45, 5 June 2015 (UTC)

/setspawn command is missing

The setspawn command is marked as added in the changelog and properly linked but does not appear in the documentation and the link is then not working. –Preceding unsigned comment was added by (talk) at 11:34, 06 June 2015 (UTC). Please sign your posts with ~~~~

That command was removed (likely in favor of spawn), the history section just does not mention that. KnightMiner t/c 18:04, 6 June 2015 (UTC)
Would it be worth re-adding the command description in a "Removed commands" section, the same way we continue to document other removed features? —munin · 16 px 16 px · 19:19, 6 June 2015 (UTC)
 Agree 20:23, 6 June 2015 (UTC)
 AgreeSealbudsman (Aaron) frameless t/c 20:51, 6 June 2015 (UTC)
I would also  Agree to a removed command section. It would be awkward to state it all its usage in the history section, and since this article is a hub article I see no reason that would not work. I think it would make the most sense as a subsection of the history section, to abide with the "keep history in the history section" policy. KnightMiner t/c 23:24, 6 June 2015 (UTC)

I've added a "Removed commands" section with /solid as an entry, but I don't know enough about the syntax of /setspawn to add it. Anyone?

I didn't re-read this topic before adding the section. I have no objection to Knightminer's suggestion to move the section under History. —munin · 16 px 16 px · 20:56, 27 August 2015 (UTC)


This page should note that commands can only be used if cheats are enabled. The Blobs16px 15:08, 27 August 2015 (UTC)

To quote what the article already says when referencing when you can use commands: "In singleplayer, if cheats were enabled at world creation (via the "More World Options..." button)." KnightMiner t/c 15:23, 27 August 2015 (UTC)

Argument colors?

For some commands the arguments can all blend together -- for example, the clone and testforblocks commands each have nine position arguments in a row. For difficult-to-read command syntaxes, would it be a terrible idea to color the arguments to improve reading comprehension? For example, compare these:

testforblocks <x1> <y1> <z1> <x2> <y2> <z2> <x> <y> <z> [mode]
x1 y1 z1 and x2 y2 z2
Specifies two opposing corners …
x y z
Specifies the lower northwestern corner …
testforblocks <x1> <y1> <z1> <x2> <y2> <z2> <x> <y> <z> [mode]
(colors added to make reading easier)
x1 y1 z1 and x2 y2 z2
Specifies two opposing corners …
x y z
Specifies the lower northwestern corner …

Without the colors you have to study the arguments to see how they group. With them, it's a snap. And it helps a little to break up the wall-o-text that this article is.

We'd only color the difficult commands like these, and only those arguments for which it would be helpful?

munin · 16 px 16 px · 20:47, 5 September 2015 (UTC)

I like this idea. --Pokechu22 (talk) 20:49, 5 September 2015 (UTC)
I also like the idea, though I would use yellow instead of that green, as that green is too close the background color. As for which commands need it, other than that ones you mentioned, the only one I can think of is /particle, though a few of the commands with multiple formats might be able to use it as well (as a way to show which part is the difference) –Preceding unsigned comment was added by KnightMiner (talkcontribs) at 03:18, 6 September 2015 (UTC). Please sign your posts with ~~~~
Yellow works. That'll help the reg-green colorblinded too. :) —munin · 16 px 16 px · 04:53, 6 September 2015 (UTC)
Great idea, will definitely help differentiate similar arguments. GoandgooTalk
06:03, 6 September 2015 (UTC)
Also a good idea.  I agree. — Agent NickTheRed37 (talk) 16:00, 6 September 2015 (UTC)

I've added colors to commands with multiple position argument groups (clone, execute, fill, particle, and testforblocks). Are there any other commands that would benefit from colored arguments? —munin · 16 px 16 px · 19:59, 6 September 2015 (UTC)

Conflicting Target Selector Information

Under the section "Selecting targets by count", it says this:

If there are multiple nearest players, caused by them being precisely the same distance away, a player is selected by the time the player most recently joined the server. For example, if equally distant, @a[c=1] will select the player who has been on the server the longest and @e[type=Creeper,c=3] will select the three oldest creepers.

It says that ties are won by the player who "most recently joined the server", and then it gives an example that says that the tie is broken by "the player who has been on the server the longest". This seems to contradict itself. Later in the same section, its example using a negative value for the count selector on an entity would break a tie with the "last three targets created". It does not specify if the tie breaking behaviour for players is reversed as well. -- 04:48, 27 October 2015 (UTC)

I can see how that might be confusing. I've changed it:
If there are multiple nearest targets, caused by them being precisely the same distance away, targets are sorted by the time they have been on the server (since their most recent join for players or their creation for other entities) with the longest times selected first. For example, if equally distant, @a[c=1] will select the player who has been on the server the longest and @e[type=Creeper,c=3] will select the three oldest creepers.
Does that help? —munin · 16 px 16 px · 19:03, 27 October 2015 (UTC)
Yes, thank you. I wonder if this behaviour should not be verified though. The reason that I say this is because under the section describing the @p selector, it says:
Targets the nearest player. If there are multiple nearest players, caused by them being precisely the same distance away, the player who most recently joined the server is selected. 04:48, 28 October 2015 (UTC)

JSON Conflicts

Im a beginner in JSON text, but something I cant figure out. I want to add colors to my titles, but the {color:"color"} doesnt work. maybe its the context? I used this: /title @a title [{color:"gold"},"text"] What did I wrong? 19:28, 30 October 2015 (UTC)

I'm no big user of commands, but,
Try this, with curly brackets surrounding the JSON tag, and with the element values and keys in quotes:
/title @a title {"color":"gold","title":"text"}
Sealbudsman talk/contr 22:05, 30 October 2015 (UTC)