Talk:Commands

Split between Java Edition Commands, Bedrock Edition Commands, and Education Edition Commands. I  Oppose the split because the command subpages will also be split. The Great Spring (talk | contribs) (Tagalog translation) 04:03, 9 December 2020 (UTC)Reply

 Oppose not for that (which wouldn't happen) but because it's unnecessary, the table shows edition specificity well enough.  Nixinova   T   C   04:20, 9 December 2020 (UTC)Reply

I  Support the split because it will be easier to navigate. I hate that we have three different versions of Minecraft commands all jampacked into one single page. It's extremely dumb... Though the subpages wouldn't need to be split tho that's fine. The commands page is just too long. (posted 19 jan 2021) --VykeType (talk) 03:23, 20 January 2021 (UTC)Reply

Use the below discussion. TheGreatSpring (talk) 03:32, 20 January 2021 (UTC)Reply

I  Support the split for the same reasons as above. --99.111.19.232 13:47, 22 February 2021 (UTC)Reply

 Support the split. Bedrock and Java commands are no were near similar when working on them, a lot of people when changing from one version to another had issues because of them not being the same. Having all of them in the same page makes it really confusing for new people learning commmands (especially youngest people and in bedrock version). When I helped some knowns learn most of the questions I got is why this command does not work, and it was because it did not exist in Bedrock and was only a java command. In my opinion this should be in a way were new people in the game could easily understand which commands they can use. At this moment we have a really long list of command and columns which when seen innthe middle of it you only see a bunch of random red and green boxes which are hard to understand what they do refer too, bedrock?, java?, permissions? Until we get full parity in commands (which does not seem to happen soon), I think this page and all subpages should be split and have in them in the top links to their java/bedrock counterpart. Bedrock and Education Edition commands should be in the same page as they are identical except for some exceptions which are education edition only. --DrAv0011 (talk) 21:55, 1 March 2021 (UTC)Reply

I propose a different way to approach this split. I don't think the subpages are that much of a problem, and we can just turn Commands into a disambiguation of the three pages. The subpages will remain where they are. Here is my proposal:

1. The subpages remain the same
2. Commands will become a disambiguation listing the three pages
3. The three pages will list each of their features and how they work, due to how commands in these three editions vary differently.

Any thoughts? I personally  Support this change. Blockofnetherite ^{Talk Contributions} 18:53, 17 December 2020 (UTC)Reply

 Support I think it isn't necessary to create different pages for every command for the different versions as a lot of the information would be repeated. However, I think it's a good idea to split the Commands page as it is quite long and somewhat confusing. - Cherryblossom000 (talk/contributions) 06:59, 23 December 2020 (UTC)Reply

 Oppose Splitting along edition lines. The majority of information is relevant to Java Edition, so splitting the pages would only slightly shrink its page. The Bedrock/Education Edition pages would also require a lot of duplicate information. The only real chunk of information that would be removed from the Java Edition page is the BE Debug commands. I would support splitting those or collapsing them since they aren't really useful except from a historical perspective. Jahunsbe (talk) 15:04, 17 January 2021 (UTC)Reply

 Support but personally, I am  Neutral TheGreatSpring (talk) 03:32, 20 January 2021 (UTC)Reply

 Oppose per Jahunsbe. BDJP ^(t|c) 07:00, 20 January 2021 (UTC)Reply

I  Support and welcome this change, as a Bedrock player trying to understand broken commands is already hard, but having explanations crammed up and mixed with Java features makes it impossible! MetalManiac at ya' service fellow human! (talk) 17:20, 2 February 2021 (UTC)Reply

 Oppose I had rewritten this page, see [1], and made commands in each edition clearer. So I think it unnecessary to split it now.--Chixvv (talk) 14:29, 6 February 2021 (UTC)Reply

 Disagree, thank you for rewriting the page but we still should split it as per the discussion below. Blockofnetherite ^{Talk Contributions} 16:43, 26 February 2021 (UTC)Reply

 Support Personally, I find Commands really long and confusing. Thedolanduck (talk) 12:39, 22 April 2021 (UTC)Reply

I am also proposing a different way to approach this split:

1. Commands will stay the same
2. most subpages also stay the same.
3. Only the subpages like Commands/execute where bedrock and java are very different get changed.
4. Those subpages get two other sub-subpages like: Commands/execute/(Java Edition) and Commands/execute/(Bedrock Edition)
5. Those new sub-subpages are more or less just a copy of the original page (for now), where only the all the other parts are deleted.
6. The main subpage can be changed to only explaining in general what the command can be used for and about the differences between the two versions.
7. The main subpage also gets two big buttons leading to the two sub-subpages (which now have the detailed information about how it works in each version and so on)

This system does not have to be implemented to all subpages at once and would be very easy to understand. It also works with existing bookmarks of users. I would be willing to make the sub-subpages for the execute command as a prove of concept.

My background: I am an experienced command user and i have made multiple datapacks for java but also for the bedrock market place. I have used this wiki a lot, but at some point I got frustrated enough so I now decided to try to change it. (please don't understand it wrong, I love this wiki, but sometimes I get confused by this mess, which can cost hours of time while coding) (I have already written about this idea on the discord: https://discord.com/channels/447104142729674753/1158428792797282364)

What do you think? I personally  Support this change.LordOfSpyro (talk) 19:11, 2 October 2023 (UTC)Reply

 Support making the edition division with commands more easy to understand. Although BE and JE commands have become closer over the last few updates, there's still grave differences between them due to the different engines used. I'm not 100% sure though how the pages should be split – possible naming schemes would be Java Edition commands/execute, Commands/Java Edition/execute, Commands/execute (Java Edition) or Commands/execute/Java Edition. | violine1101 ^(talk) 22:10, 2 October 2023 (UTC)Reply

 Support. I can see value in splitting a command so different between editions that it makes the article unwieldy. ManyOursOfFun (talk) 12:02, 6 October 2023 (UTC)Reply

 Strong support. Commands are so different between Java and Bedrock, so I think this is an excellent idea. Besides, I think the wiki overcomplicates commands. We could even keep the current pages, and have those as overview pages. However,  note that it would be a lot of splitting. Nerdyguy2000 (talk) 17:39, 7 July 2024 (UTC)Reply

 Support splitting commands that are very different in java and bedrock. I support naming pages Commands/execute/Java Edition or Commands/execute (Java Edition). Miner(talk contributions) 12:36, 7 October 2024 (UTC)Reply

Coming back to this discussion after months, my opinion has not changed. -~- Nerdyguy2000   Talk   Edits  14:32, 7 October 2024 (UTC)Reply

 Support splitting commands with significant differences between editions, I agree that the main Commands page is probably organized enough as is and does not itself warrant splitting. Commands/execute (Java Edition) would probably make the most sense if there is no separate "Java Edition commands" subpage being proposed, and would work with {{Infobox command}} automatically changing the display title to "/execute (Java Edition)". Compared to Commands/execute/Java Edition, it generates an automatic backlink to Commands instead of the main /execute subpage, depending on which is preferred. –⁠Sonicwave ^talk 17:26, 21 June 2025 (UTC)Reply

 Support Splitting as proposed. "Commands/execute (Java Edition)" is the best way to go, I think; the "Commands" bit is just for technical reasons; treat it like a namespace prefix and then apply naming conventions as normal.  Nixinova   T   C   08:31, 28 July 2025 (UTC)Reply

The proposal above proposes to split the article into the two editions. I propose to instead split it into, for example (I'm open for other suggestions):

• "Commands" for a basic overview
• "Target selectors" (currently you actually need to click a link to view this section, why not extract it altogether?)
• "Data tags"
• "Coordinates" (article already exists, could be expanded to add local and relative coordinates; alternatively have a separate article "Coordinate notation"?)
• "Command syntax" (?)
• "Permission level"
• "List of commands"

The current article is kind of a mess and makes it difficult to find something specific.

Note that this split is not necessarily incompatible with the one above. Both can happen at the same time if desired (although I don't think that makes much sense) | violine1101 ^(talk) 12:47, 15 February 2021 (UTC)Reply

 Support I am constantly frustrated by this page. I don't think I'm alone in that the way I most often use it is to reach a specific command I'm interested in, but the summary table is inexplicably and ridiculously at the very bottom of the page. (I realize I could go directly to the command subpage, but readers shouldn't be expected to know when or how to do that.) This page should be the summary, with table entries linking to subpages and everything else moved to a {{main}} page or at least collapsed until it's needed, depending on length. — Auldrick (talk) 14:10, 15 February 2021 (UTC)Reply

 Support Yep. Each one of these topics is very distinct and is very important. They should all be pages OR subpages. VykeType (talk) 03:01, 16 February 2021 (UTC)Reply

I will  Support this, because it seems like because many people dislike splitting among edition lines, it ends up creating a large page which will definitely help, but not enough. Really, I just wanted this page split somehow to clean up this mess. This seems to be a better option, and I assume the subpages will remain the same. Not sure about making these subpages (like Commands/Data tags, Commands/Target selectors, Commands/Command syntax, or Commands/Permission level), because although it generally makes sense, the issue is 1) It may be confusing with the existing subpages (of course, the commands /data_tags to /permission_level have ever existed), 2) Subpages are not so well supported or promoted by wiki infrastructure (from the random page button never getting there, and other things), and 3) More than just commands may use these proposed split pages, as Functions use target selectors and permission level, right? Blockofnetherite ^{Talk Contributions} 00:40, 19 February 2021 (UTC)Reply

Overall, here are my thoughts about this page:

1.  Strong support splitting in general
2.  Support splitting upon edition lines
3.  Stronger support splitting upon Violine1101 (talk • contribs • logs)'s proposal to split among topic (currently the only proposal that doesn't split upon edition lines, may be improved).
   1.  Extremely weak support The same proposal as above that I put "Stronger support", only that these pages would be subtopics, as I prefer having them independent rather than a subpage for the 3 reasons
4.  Oppose splitting the existing subpages for each command, as they are fine the way it is
5.  Strong oppose not splitting at all.

Blockofnetherite ^{Talk Contributions} 00:53, 19 February 2021 (UTC)Reply

I did not take splitting the subpages into consideration and I'm not advocating for it. My proposal is exclusively about splitting the "Commands" article itself and wouldn't affect the command subpages. | violine1101 ^(talk) 10:19, 19 February 2021 (UTC)Reply

To add onto this, I'd personally also prefer these new split-off articles to not be subpages of Commands but articles in their own right. The subpages of "Commands" should be reserved for the commands themselves. | violine1101 ^(talk) 10:23, 19 February 2021 (UTC)Reply

 Strong support. TheGreatSpring (talk) 00:44, 19 February 2021 (UTC)Reply

 Support, this page is so messy, confusing, and hard to navigate. I also personally  Support per above.Humiebee (talk) 01:00, 19 February 2021 (UTC)Reply

 Support Atomising this page. Weak oppose splitting on editions.  Nixinova   T   C   22:05, 1 March 2021 (UTC)Reply

 Support – I'd like to see this split before splitting on edition (which I have no opinion on at the moment). The block and item argument descriptions should be moved to Argument types (which currently links to these sections), but perhaps the rest of the syntax part and the success conditions can remain on this page? –Sonicwave ^talk 02:07, 22 March 2021 (UTC)Reply

 Support — MDLC01 (talk) 20:04, 20 April 2021 (UTC)Reply

 Strong Support However, if done this way, Commands should have different sections for Bedrock Edition and Java Edition commands, such as command subpages do. We should reach consensus soon as to start splitting pages right away and not confuse fellow players anymore, considering the changes 1.17 is introducing for mapmakers. Thedolanduck (talk) 12:49, 22 April 2021 (UTC)Reply

Since we all agreed with it, I'll split it on topic next month.--Chixvv (talk) 17:18, 19 May 2021 (UTC)Reply

The "Success Count" column on the output tables gives no useful information to the reader. The success count, which is written to the command block NBT, is the amount of contexts that ran successfully. It always matches the success column (next to it), and it can increase when commands like /execute as fork the command into multiple contexts. But the /execute page doesn't even have an output table. On Bedrock Edition the success count does depend on the command, but I think it can reuse the "Success" column, with a tooltip giving more info.

I propose the following changes, using the /experience command as an example.

Current:

Command	Edition	Situation	Success Count	/execute store success ...	/execute store result ...
Any	Java Edition	On fail	0	0	0
/... query ...		On success	1	1	the number of experience points or levels the player have
/... add ... /... set ...		On success	1	1	the number of targeted players
Any	Bedrock Edition	On fail	0	N/A	N/A
		On success	the number of players who are given or taken experience.	N/A	N/A

Proposed:

Command	Edition	Situation	Success	Result
any	Java Edition	On fail	0	0
/... query ...		On success	1	the number of experience points or levels the player have
/... add ... /... set ...		On success	1	the number of targeted players
any	Bedrock Edition	On fail	0	N/A
		On success	the number of players who are given or taken experience	N/A

- Misode (talk • contribs) 00:12, 2 November 2023 (UTC)Reply

 Support: Seems reasonable and simplifies things, assuming "success count" and /execute store success ... are indeed the same in every instance. Although, in my experience, I wouldn't even know what such a difference would be, and I'm pretty sure the game itself would only consider success and result without any third variable.

As an additional comment, I also like the green and red cell background colour for success and fail. I think it's a nice touch. ZacNVR (talk) 06:08, 2 November 2023 (UTC)Reply

Changed to  Oppose per Chixvv, but I still think adding functionality for cell coloring is a good idea. – ZacNVR (talk) 02:47, 29 January 2024 (UTC)Reply

 Oppose: Though the "Success Count" column gives no more information, it clarifies the differences between the success count and the stored success value. For cross-edition players, these two are often confused. It is better to have redundant information than to make it more confusing. Moreover, there're some instances that the two column does not match, like /loot. And important info should not be placed in a tooltip, as it is not available in mobile device.--Chixvv (talk) 07:37, 28 January 2024 (UTC)Reply

I see. /loot is an odd command it seems, having an "error" condition, which has 0 success count but cannot store any success or result with /execute. Thanks for the info. – ZacNVR (talk) 02:47, 29 January 2024 (UTC)Reply

The errors of /loot are because of bugs. After checking the code, I found a void function also has 0 success count but has no success or result value, and which is not a bug. See Commands/function.--Chixvv (talk) 06:56, 31 January 2024 (UTC)Reply

I have made a draft template on my user page (User:ZacNVR/Sandbox/Output table). Here's what it looks like when passing the same input parameters as the template above:

Command	Edition	Situation	Success	Result
any	Java Edition	On fail	0	0
/... query ...		On success	1	the number of experience points or levels the player have
/... add ... /... set ...		On success	1	the number of targeted players
any	Bedrock Edition	On fail	0	N/A
		On success	the number of players who are given or taken experience.	N/A

And for a Bedrock exclusive with onlybe=1 (taken from Commands/replaceitem):

Command	Edition	Situation	Success Count
any	Bedrock Edition	On fail	0
/replaceitem block ...		On success	1
/replaceitem entity ...		On success	the number of entities whose items are successfully replaced

It is compatible with both the current syntax {{Output table|1|2|3|4|cmd|edition|onlybe}} and the proposed shortened syntax {{Output table|1|2|3|cmd|edition|onlybe}} by ignoring 3 if 4 is specified and using 4 in place of 3 (check User:ZacNVR/Sandbox/Output table/Test to verify that these formats do produce identical tables). I left out the cell coloring for now as that would likely require an extra parameter, as sometimes commands have more detail than just success or fail (see Commands/function). – ZacNVR (talk) 07:19, 25 January 2024 (UTC)Reply

Could anyone specialist do correct the following phrase, which is either incomplete, erroneous or unclear:

   In Java Edition, whether cheats are enables only affects the permission level of a player.

Possible enables might be corrected as enabled , however as for me, it is still unclear, what this sentence says.

The second phrase is OK:

(If an executor has a high enough permission level, it can use corresponding commands regardless of whether cheats are allowed.)

TwoBlocksMC (talk) 23:54, 23 January 2025 (UTC)Reply

Maybe it means on multiplayer when opened to LAN? That it (cheat permissions) would only affect the host and not the other players who join? Quicklightning (talk) 04:52, 9 November 2025 (UTC)Reply

Here to learn about bedrock edition commands Stuff (talk) 00:10, 5 March 2025 (UTC)Reply

I was wondering if any commands exist in 0.14.3 5.214.38.132 18:55, 3 April 2025 (UTC)Reply

Ok, so in bedrock edition some commands don't show possible strings/values you can insert(to make a successful command). That is annoying and I often came to the wiki to see what I can put, but there just wasn't a list on any of the command pages. /playanimation does sorta have it, but it's incomplete. So my idea is to have a list of possible strings you can put into the command. (Example being /playsound) Dinoman 69 (talk) 14:49, 5 September 2025 (UTC)Reply