The Meaning of Life, the Universe, and Everything.
Join Date:
2/11/2017
Posts:
662
Member Details
Currently, when a player hits a button, the only way a command block can access that player is with @p. And that's not guaranteed to hit the correct player. Just the nearest one. If there was another player that happened to be closer to the command block at the time, it would be executed on that player, and not the one who hit the button. This becomes more of a problem with chain command blocks. At the beginning of the chain, it may hit the right player, but at the end of the chain, it could hit a completely different one. You could use "execute at x y z" to fix this, but that makes commands even more complicated than they already are, which makes for less understanding and harder editing. This problem is nonexistent in single player mode, as there is only 1 player to target. But on a server, this problem gets more prominent the more people are on the server.
What I'm suggesting is a target selector that gets the person who originally started the redstone chain. Maybe it could be called @x for "executor". If a player hits a button, the button tracks the player and the command block that is activated communicates with that button to figure out which player to target. If the command block was activated by another command block, it asks the command block that started the chain what to target, who asks the button. Same for levers, pressure plates, etc. If you ask a redstone dust (or anything else carrying a signal), it will ask the initiator of that redstone path (the block that activated the first redstone). If the initiator happens to be a block (such as an observer, redstone block, etc.), it will ask the command block or entity that originally placed that block there. If that block was generated by the computer, it will ask whatever player created the world. If the initiator doesn't exist anymore in the world, it will throw an error saying the entity was not found and stop the command.
If you wanted to target a specific player, use "if @x[type=player]". If you run this selector through the chat box (or any other method that did not use a redstone signal, such as with an "execute as" command), it behaves in the same way as the @s selector. If the command is within a command block, however, it will ask the parent block.
This is originally what I thought @s would do, so you should probably change the description of that, too.
EDIT: It will also fix the problem that the selector @p with restraints doesn't work as most would expect. "@p[score={money=10}]" would find an entity if any player existed that had money of 10, not necessarily the nearest player. Most likely the player that is farther away was not the intended recipient of the command. The only solution I have found is to do this: "execute as @p run execute if @s[score={money=10}]". With this selector, you would always know that you are targeting the intended recipient because it can only possibly target 1 entity. You could use "@x[score={money=10}]"
To download the other ones you need to make a folder in the versions folder for minecraft and put the client and JSON file for the versions in there. They all need to be named the same aside from file extensions. Once you do that, you will be able to choose that version when making a new profile with the minecraft launcher.
Currently, when a player hits a button, the only way a command block can access that player is with @p. And that's not guaranteed to hit the correct player. Just the nearest one. If there was another player that happened to be closer to the command block at the time, it would be executed on that player, and not the one who hit the button. This becomes more of a problem with chain command blocks. At the beginning of the chain, it may hit the right player, but at the end of the chain, it could hit a completely different one. You could use "execute at x y z" to fix this, but that makes commands even more complicated than they already are, which makes for less understanding and harder editing. This problem is nonexistent in single player mode, as there is only 1 player to target. But on a server, this problem gets more prominent the more people are on the server.
What I'm suggesting is a target selector that gets the person who originally started the redstone chain. Maybe it could be called @x for "executor". If a player hits a button, the button tracks the player and the command block that is activated communicates with that button to figure out which player to target. If the command block was activated by another command block, it asks the command block that started the chain what to target, who asks the button. Same for levers, pressure plates, etc. If you ask a redstone dust (or anything else carrying a signal), it will ask the initiator of that redstone path (the block that activated the first redstone). If the initiator happens to be a block (such as an observer, redstone block, etc.), it will ask the command block or entity that originally placed that block there. If that block was generated by the computer, it will ask whatever player created the world. If the initiator doesn't exist anymore in the world, it will throw an error saying the entity was not found and stop the command.
If you wanted to target a specific player, use "if @x[type=player]". If you run this selector through the chat box (or any other method that did not use a redstone signal, such as with an "execute as" command), it behaves in the same way as the @s selector. If the command is within a command block, however, it will ask the parent block.
This is originally what I thought @s would do, so you should probably change the description of that, too.
EDIT: It will also fix the problem that the selector @p with restraints doesn't work as most would expect. "@p[score={money=10}]" would find an entity if any player existed that had money of 10, not necessarily the nearest player. Most likely the player that is farther away was not the intended recipient of the command. The only solution I have found is to do this: "execute as @p run execute if @s[score={money=10}]". With this selector, you would always know that you are targeting the intended recipient because it can only possibly target 1 entity. You could use "@x[score={money=10}]"
Remember those versions that minecraft pranked us with? Specifically:
Those are still downloadable! Watch this video for 2.0:
https://www.youtube.com/watch?v=PQdu9LKAdIU
To download the other ones you need to make a folder in the versions folder for minecraft and put the client and JSON file for the versions in there. They all need to be named the same aside from file extensions. Once you do that, you will be able to choose that version when making a new profile with the minecraft launcher.
15w14a is on this link:
http://minecraft.gamepedia.com/15w14a
1.RV-Pre1 is here:
http://minecraft.gamepedia.com/1.RV-Pre1
Minecraft 3D is here:
https://minecraft.gamepedia.com/Java_Edition_3D_Shareware_v1.34