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)

The table of op-only commands has become ridiculously long. Unless someone raises some good objections I hope to tackle this conversion soon. I think now I'll just make them all one big list and just list the player and multi-player commands in some convenient spot (or maybe a "quick-link" summary table with one column a sortable "type"). The TOC will be long -- I may have to float it to the right or limit the number of headings shown. We'll see. &mdash;munin &middot;  &middot; 02:10, 18 July 2014 (UTC)


 * For now I've just coverted the table cells into definition sections. I'll work on improving the structure of the descriptions soon (arguments, result, etc.). I decided to use "Syntax" because there's already a big "Usage" section in the article. &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 08:24, 28 July 2014 (UTC)


 * I'm sorry please take this as constructive criticism, but this looks absolutely terrible. You've doubled the length of the article to provide mostly the same information. Plus it's pretty much now a wall of text. Having a bold title, followed by a brief line, followed by a bold title, followed by a brief line, and so on, to describe what each individual command does isn't how this works. A bolded title should be above a large amount of information to break the page off into sections. What you did just all blends together with no easily obvious breaks anywhere. Here, I made a before and after pic: http://i.imgur.com/rEcCEKL.png Now if only there was a simple data structure to display a large amount of information with short descriptions and the same attributes, like a table. TrazLander 14:30, 2 August 2014 (UTC)


 * I think the main problem you have is a consequence of the Minecraft Wiki's poor heading styling which makes headings hard to notice (I do use my own CSS but I am looking at the article unlogged as well). That's one of the reasons I added the infoboxes, so the start of each command would be more obvious (as well as the desire to include small pieces of data about each command without adding to the article length). And it's not the same information -- I'm checking all the commands in-game, making corrections, adding information and examples, etc. It's going to take a few weeks to get through them all. I have considered throwing some HRs at the end of each section to make the breaks clearer, but improving the heading styling for the entire wiki would be a better solution.


 * While it may look like a wall of text when just scrolling through the article, I think you'll find that, when you're concentrating on a single command, the syntax is much easier to read when not line-wrapped in a tight table cell, and it's a lot easier to pick out information about specific arguments when they're not collapsed in a single paragraph (again, a consequence of tight table cells). A table is appropriate for organizing small pieces of info, but not for paragraphs of info. We could put the whole section in a table, one command per cell -- that would also give you the clear separation you're used to. But that's equivalent to saying you like your text on a white background with a line between sections, and you can do that with your own CSS (my CSS adds lines to the h3 headings, so I'm not objecting to such a thing stylistically).


 * As for the article being longer in, what, number of screen scrolls? … is that a problem? I've though about whether the commands should be separated out into category pages (I've actually got a nice set of logical category titles ready to go with 8-10 commands per category) or even put on their own page each ("if this were wikipedia", they would be). But keeping them on a single page is probably best for now.


 * So, anyway, since improving the wiki heading styling might take some doing, think about the HR and single-cell-per-command suggestions as temporary measures.


 * &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 18:40, 2 August 2014 (UTC)


 * Some suggestions I have as for the new layout:
 * Add some sort of sorting to the commands, other then just alphabetical. Basically different sections based on type rather then all in the list. Sections such as "Single Player", "Multiplayer", "Non-op commands", and possibly "Upcoming commands".
 * Add an extra line break or two after each command to better distinguish the sections from each other.
 * Place shortcuts with the actual command, and just add an extra anchor there.
 * --KnightMiner  (t 21:48, 2 August 2014 (UTC)


 * 1) I don't think category sections will help much with TrazLander's objections, and I wouldn't want to push the command headings even deeper (so categories would have to be h2 headings), but here are the categories I considered, which seem logical to me and give a nice balance (roughly the same number of commands in each category):
 * Block Commands — commands which affect blocks: blockdata, clone, fill, replaceitem block, setblock, stats block, testforblock, testforblocks
 * Entity Commands — commands which affect entities, but not specific to players: effect, replaceitem entity, scoreboard, spreadplayers, stats entity, summon, testfor, tp
 * Multiplayer Commands — commands only available in mp: ban, deop, kick, list, op, pardon, save, setidletimeout, stop, whitelist
 * Player Commands — commands only relevant to affecting players: achievement, clear, enchant, gamemode, give, kill, playsound, spawnpoint, title, xp
 * World Commands — commands which affect the world: defaultgamemode, difficulty, gamerule, publish, seed, setworldspawn, time, toggledownfall, weather, worldborder
 * Miscellaneous Commands — all the rest: debug, execute, help, me, particle, say, tell, tellraw, trigger
 * But categories can be arbitrary and there's no way to ensure that future commands may not be equally valid in multiple categories (for example, the give command can only target players, even with @e in the snapshots, but if the player's inventory is full it drops an entity). Maybe each section would just have see also links for the border cases.


 * 2) That could definitely help. It's another workaround for poor heading styling by the wiki, but is worth trying. I think moving the infoboxes above the intro text would help to delineate the section better too (they'll both have the same top level).


 * Just to illustrate my point about the wiki's poor heading styling, here's what part of the page can look like with, IMHO, some better heading styling: . My CSS adds space before the heading, makes the font size larger, uses small caps (which look like regular caps for lowercase headings here), and h3 headings have a line under them. But I definitely understand that that's not what others see, so I'm taking TrazLander's concerns seriously.


 * 3) Are you talking about things like ? and msg being alternative syntaxes for help and tell? There's not too many of them. I guess it could help to remove them from the TOC.


 * I've got some things to do right now, but later this evening I'll try double-spacing before sections, remove/anchor the shortcuts, and move the infoboxes up and see if that helps. Let's see if anyone else has opinions on categories before we try that.


 * I've also noticed that the command help text in the snapshots now says "Usage" so I may need to go back to that from "Syntax".


 * &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 00:24, 3 August 2014 (UTC)


 * As for the categories, my main idea was so it was not just a heap of commands. Those categories seem good.
 * The double line break does help to break up the sections, and I think the line is not added by default because standard page format only requires subsections. I may try it out for a bit though.
 * Yeah, just to keep it a little neater and to prevent the illusion that they are different commands.
 * --KnightMiner  (t 01:23, 3 August 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)


 * Should it be added to the description or trivia? TristanLuigi (talk) 03:23, 26 June 2014 (UTC)


 * The command's description. It is real information about how the command works. &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 05:30, 26 June 2014 (UTC)

Item with negative count
If an item's count is set to -1 and I pick up another identical item, will that slot then be empty? And what happens if I try to drop my -1 pickaxes? Seahen (talk) 00:44, 20 July 2014 (UTC)

/tell and target selectors
I'm not setup to test this properly. Can non-operators use target selectors in /tell, especially target selector arguments? Can you do something like:, and thus potentially identify the positions of other players? &mdash;munin &middot;  &middot; 04:18, 7 August 2014 (UTC)
 * /tell will not parse target selectors in the message, whether the player is OP'd or not. Non-OP'd players also cannot use selectors for the target of the message, though OPs can. EDIT: It appears that using the server console with a target selector within the message will properly parse the selector. Skylinerw (talk) 05:00, 7 August 2014 (UTC)


 * Thanks, I've updated the command. &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 08:09, 7 August 2014 (UTC)

entitydata for chestedhorse tag on skeleton horse
I have a question, could the entitydata command be used to put a chest on a skeleton horse using the chestedhorse tag? It would be much appreciated if someone could tell me if that was possible. Thank you Brickticks (talk) 18:12, 8 August 2014 (UTC)


 * I'm not going to try it because chunk format says: "As of 13w39b, a chested horse that is not a donkey or a mule will crash the game." &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 18:19, 8 August 2014 (UTC)

incorrect information in target selector "count" section?
In Target Selectors, the count section says that when you don't use positioning, the target selector grabs entities in order of creation, but even when I don't use positioning, it grabs them in order of distance from my player

Even with command blocks it does it by distance from the command block rather than order of creation.

no matter what I do, I can't seem to get it to grab them by order of creation.

Is this information just incorrect? Kavukamaritalk 11:44, 20 August 2014 (UTC)


 * Maybe. Which version are you using? &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 11:51, 20 August 2014 (UTC)


 * 14w33c, The way it looks from my testing, it seems to always grab in the order of distance from the command executor, with or without positioning. I thought perhaps I was thinking about it wrong, and it did grab by order of creation, but performed the commands by distance, but I don't think that's the case after messing around a bit more with the values and the order of which I created my test entities.Kavukamaritalk 12:02, 20 August 2014 (UTC)


 * He's correct as of 1.7 (no idea about previous versions), though there is an exception. If the players found happen to be standing at the exact same position (such as from a teleport), the selector then chooses from the list of who appeared first on the server. Assuming the same goes for @e as well. Skylinerw (talk) 12:12, 20 August 2014 (UTC)


 * Cool. Do you want to update it, Kavukamari, since you noticed it? I'm happy to do it if you don't feel comfortable doing it. &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 12:16, 20 August 2014 (UTC)


 * Hm. So that makes  identical to , which seems less useful. &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 12:20, 20 August 2014 (UTC)
 * Speaking of @p, it would also fall under the same rules for checking when the target was created if two match as being the closest. Perhaps instead of stating this under the "Count" parameter (though it's required by @a and @e to obtain the 'created' effect), it would go in the intro of target selectors. But I agree, I can't think of anything off the top of my head @a would be useful for compared to @p, apart from a global selection rather than being required to specify a count. Pretty minimal but saves a lot of work, I guess. Skylinerw (talk) 12:34, 20 August 2014 (UTC)
 * Munin, I could update it, I suppose, but if I don't get to it and someone else does first, that would be fine too, I'm not sure if I'll be able to do it tonight. Also the other information here is actually very useful as well. perhaps the player can force entities to perform commands in order of creation by making them pretend to be in the same position using execute, or by forcing them to teleport to the same position and then performing the target selection with another command. Might be useful to research and add examples to either this page or a tutorial page. Kavukamaritalk 13:31, 20 August 2014 (UTC)


 * two clarifications:
 * "who appeared first on the server" — is that their most recent join, or their original join (I assume the former, but not sure).
 * order of creation only applies to players with the same position, but not to players with precisely the same distances but different positions?
 * &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 19:44, 20 August 2014 (UTC)


 * I haven't been able to test the first one, but I would assume most recent join because I don't know if the server actually keeps track of the first time people joined ever without server mods...
 * As for the second, I have no idea if I'm doing these tests correctly so my information might be wrong, but when I was messing around with entities and distances, it seemed like entities which were the exact same distance away from a command block but different positions would properly select by order of creation. (whoops forgot to sign) Kavukamaritalk 00:57, 21 August 2014 (UTC)
 * Recent join; once they leave the server they're "removed" from the list. Skylinerw (talk) 03:26, 21 August 2014 (UTC)