Talk:Commands/Archive 3

Console?
The article refers to a server "console". This suggests that there's a GUI beyond the mere comand window from which the server is run. Either the wording should be changed to "command window", or else "console" should be linked to an anchor in the Server article where console form and function (comand window in which messages and input are both operative) could be (but are not yet) clarified. Jeffryfisher (talk) 20:01, 30 January 2014 (UTC)

/killall command?
I have seen another command! it's /killall... (SORRY IF ITS ALREADY THERE. AND I DON'T LIKE ADMINS HOW THEY BULLY ME AND IM 11 YEARS OLD.) 123.243.222.122 04:16, 11 January 2014 (UTC)


 * This is added by mods (such as Single Player Commands) and/or modded servers (Bukkit, Tekkit, etc.); it's not in vanilla Minecraft. -- Orthotopetalk 05:28, 11 January 2014 (UTC)
 * I know what I'm saying now is unnecessary, but you CAN do /killall (sort of) in the new 1.8 snapshots. You can do /kill @e, although that will kill you, so you can do /kill @e[type=!Player]. Willingham yAAOz (talk) 01:30, 29 January 2014 (UTC)

Snapshot
Didn't 14w02a add more arguments for testfor? I have seen {SelectedItemSlot} --tonkku107 « Talk User Page » 15:49, 12 January 2014 (UTC)


 * Yes it did. You can now put NBT Data after the player selector like { SelectedItemSlot :0} or something DoowawM (talk) 01:37, 18 February 2014 (UTC)

Add planned tp angle argument
Can someone do this? Not quite sure what or where this information belongs.--72.83.62.225 23:02, 18 January 2014 (UTC)

Clone command does not work in Nether
...Nether:

I'm not too sure if this is true, but I was testing something in the Nether and the /clone command doesn't seem to work there. It says "Cannot copy blocks out of world" or something similar. It seems that /clone was meant for the overworld "world", and not for other dimensions (similar to how compasses don't work or beds explode). I haven't tried this in the End, but I think it's the same that goes for that. Willingham yAAOz (talk) 01:30, 29 January 2014 (UTC)

...Single Player:

v 1.7.4 says "unknown command". I wanted to practice with this uber-powerful command before unleashing it on my server, but that appears to be impossible.

Further note: Clone shows an optional [mode] parameter, but no explanation is given for what that's for. Can anyone add that? Jeffryfisher (talk) 01:31, 10 February 2014 (UTC)


 * As stated in the article's history section, /clone was added in the 1.8 snapshots, so it does not exist in 1.7.4 . Added clarification of the mode parameter. -- Orthotopetalk 01:55, 10 February 2014 (UTC)

Article structure
Some questions to consider:


 * 1) Should the title of this article be singular? "Command" instead of "Commands", leaving the plural as a redirect here?
 * 2) Should the sections on identifiers and their arguments (@p, etc.) from Command Block be moved here?
 * 3) Is it time to arrange the commands by headings rather than as table rows? With some of these commands there is a lot more that could be discussed, examples that could be provided, etc. – and it's difficult to do that in a table cell.

&mdash;munin &middot;  &middot; 04:43, 17 February 2014 (UTC)


 * Since the article is inherently about multiple commands, not just one, I think it makes more sense to have the title plural, similar to the Mobs and Flowers articles. -- Orthotopetalk 15:36, 18 February 2014 (UTC)


 * 1. I think it should be Commands, because it is about more than one command.
 * 2. A brief summary of the @p, @a, @r, and the upcoming @e should probably be included, but it should also be on the command block page as that it what I think they were meant for (I think).
 * 3. I think they should be under headings to have spaces for examples and detailed ways they work. Dragon29 29 (talk) 13:02, 24 February 2014 (UTC)

So, I'm giving some serious thought to #3 – organizing the commands as headings rather than as table tows. But it's a big step and I haven't get a lot of feedback yet. There's a lot more that could be said about many of these commands, and table cells just don't cut it.

Here's what I'm thinking as a first stab:


 * {| class="collapsible collapsed"

! colspan=2 | Proposed command description
 * style="width:50%" |
 * style="width:50%" |

Gamemode

 * Uses definition headings below so as not to spam the TOC.

Sets the game mode of players.


 * A short description of the command.


 * Usage




 * As close as possible to the in-game help.


 * Arguments


 * mode
 * Must be one of three values:
 * (can be abbreviated as  or  )
 * (can be abbreviated as  or  )
 * (can be abbreviated as  or  )
 * "hardcore" is not a valid option for the mode argument.


 * player
 * 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, player is not optional.


 * Describes the valid values for each argument and possibly the consequences of the choices (it's obvious enough here that it probably can be left unsaid). Sometimes it will make sense to describe argument options in a paragraph, sometimes in a list (mode could probably go either way here). Some arguments might be discussed together (for example, x1 y1 z1 or item data dataTag).


 * Result


 * Fails if arguments aren't specified properly, or if player fails to resolve to one or more online players.


 * If successful, changes the game mode of the default or specified players.


 * Comparator output: Signal strength equal to the number of players affected (maximum 15).


 * Describes what can cause the command to fail. Describes comparator output strength for commands with results more complicated than success or failure (this is going to need some research, I think).


 * Examples


 * To put yourself into creative mode:  or
 * To put all players into spectator mode:


 * Examples to show how commands are really used, or to illustrate complicated uses or implications. Long examples might go on their own line(s). Some commands won't need this section (especially commands with no arguments).


 * Future


 * An additional value for the mode argument is currently available in the 1.8 snapshots:
 * (can be abbreviated as  or  )


 * See also


 * defaultgamemode – sets the initial game mode for players joining the world


 * Some commands might need some additional information (upcoming changes, see also, cautions, etc.). Many commands won't need these sections.
 * }

Some commands have multiple usages and it will probably make sense to describe each one separately under sub-headings (different arguments, different results, etc.).

Despite the differences in content amounts, I think it still makes sense to keep the current division between players commands, operator-only commands, and multiplayer-only commands – rather than collapsing them into a single list with their scope/permission described per command (oh, and leave scoreboard where it is too). It might make sense to have a collapsed table to summarize the op-only commands at the top of that section, for quick scanning.

Yea or nay? I'm happy to discuss alternate presentations/headings/structure/etc.

&mdash;munin &middot;  &middot; 05:25, 1 May 2014 (UTC)


 * Looks good to me. Another option would be to make a single list of all the commands, but with another section listing when each one is available. -- Orthotopetalk 06:25, 1 May 2014 (UTC)

Cubic search overwrites radius search
After some testing I figured that the cubic search always overwrites the radius search, no matter the order it's put (given that you use the argument,value structure, and not the 'trick' where you don't have to insert the argument for the first 4 inputs where the 4th is referred to as the maximum search radius).

Now isn't it an idea to put, behind the description of the cubic arguments, that they overwrite the radius argument? Just to make sure that people don't waist their time trying to insert a radius AND a cubic search (for whatever strange reason that may be).

--Den3107 (talk) 19:53, 18 March 2014 (UTC)

Can I use the kill command on myself
can I use it on myself can you do it please tell me thanks again 96.49.236.201 00:20, 26 April 2014 (UTC)

Tag [upcoming] to new commands and commands with new options
I know this has been done in this wiki when 1.7 is in snapshots, but why hasn't this practice continued? I for one do follow the snapshot changelogs so I can tell that some of these commands, selectors, variables etc. are unavailable to current release version (1.7.9 as of writing) but think about the laymen, new players and whatnot who has not followed the development changes. UMS Molster (talk) 04:27, 22 May 2014 (UTC)

Example for type argument selector is false
In the example "EntityHorse" is put in as type, though then entity name for horse is just "Horse", shouldn't this be changed? --Den3107 (talk) 13:27, 14 June 2014 (UTC)


 * The entity ID for all horses is "EntityHorse". You can find entity IDs here. Skylinerw (talk) 16:29, 14 June 2014 (UTC)

Not NOT
I know that not equals is "!=" not "=!" (in Java). If I use "/give @p[name=!gamegirlxl] minecraft:stone" it says player not found. Is there a bug with "=" vs. "!=" because they seem to work the same?Gamegirlxl (talk) 00:28, 17 June 2014 (UTC)


 * When you use != you're attempting to check the parameter "name!" instead of "name", which is an invalid parameter and thus is ignored. In that case, the nearest player regardless of name will be selected. You'll need multiple players to confirm or simply use 1.8's @e selector. Skylinerw (talk) 00:51, 17 June 2014 (UTC)


 * In java or such languages, not-equals is written as  but in MC selectors things always follow the var=value pattern, with some like name knowing to do a   if their value starts with a  .  --GufNZ (c: (talk) 04:31, 17 June 2014 (UTC)

Particle Colorization
After analyzing Searge's Anti Spleef map and doing a bit of testing on my own, I have discovered that by using /particle reddust you can get smoke of any color, under the following conditions:

- Dx represents the red value*

- Dy represents the green value

- Dz represents the blue value

- Speed represents the strength of the tint

- Count MUST be zero

However, because this is reddust, it naturally has a reddish tint. When dx = 0, it still has a bit of red in it. I have found that the precise value of this tint is around 0.8 to 1 because it has a random strength every time it is generated. To compensate, you should set the R channel to -1. Therefore, /particle reddust ~ ~ ~ -1 0.8 1 1 0 produces a dodger-blue like color. The red value is roughly 0% (remember, we had to compensate for the natural tint, so the actual number is -1), green is at 80%, and blue is 100%. Oddly, the RGB values still function far past 1, but it does not seem to have that big of an effect. Finally, the brightness at values > 0, seems to just be a multiplier on the overall color. 1 would produce values you would expect from a normal RGB spectrum. The brightness can be increased above 1 and will produce very vibrant colors (the dodger blue from earlier will become cyan). This may require more testing, because it does have some odd effects. For instance, at exactly zero, rather than displaying black like 0.01 does, it displays as red.

Should this information be added to the wiki? It seems like it would be very helpful to map creators. TristanLuigi (talk) 20:00, 23 June 2014 (UTC)


 * The particle command description could definitely use some improvement. Go ahead, even if you're not sure about some details. Eventually someone will say "nope, that was wrong" or they'll improve it further.


 * &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 21:43, 23 June 2014 (UTC)