For my Prison Game I have a shop for buying, but the @p selector is hard to make work in the case of more than one player nearby. I have a Scoreboard called money used for currency. The commands I'm using for the shop are:

/give @p[r=4,score_money_min=50] minecraft:wooden_pickaxe 1 0 {CanDestroy:["minecraft:log","minecraft:log2","minecraft:stone","minecraft:iron_ore"]}

/scoreboard players remove @p[r=5,score_money_min=50] money 50

I'm using 1.9 for this. If possible I would like to select the individual players who press the button to activate the commands and not rely on the @p command.

  • I can't think of a way to do this with a button, per say - Buttons and levers are unaware of who pressed them, as they only save toggle state. Perhaps use a pressure plate instead, with the first command block below as an objective setter followed by a chain of commands that only apply to a value for that objective? That would certify that the closest. I'll write this up as an answer if you want more clarification on what I mean, but if you really need a button, I don't think I can help with that. Commented Mar 10, 2016 at 11:35
  • No, I only wrote button because that is what I was using. I see what you mean in theory, but an answer would be great for clarifying.
    – Jason_
    Commented Mar 10, 2016 at 17:09

2 Answers 2


I'm writing this answer to clearly state the usage of a sign for this process. Signs in Minecraft have a JSON tag specifically for running commands called "clickEvents". I made a system using this idea with a focus on reducing the amount of commands active at once.


With this process, I assume:

  • you wish to only allow the player to buy items while in the shop
  • you wish to permit players to buy items if and only if they have enough money for it
  • the Buy trigger made in this process is already enabled
  • there already exists a dummy objective for money
  • your current Minecraft version is 1.9

Reference Image (mostly for later)



Before we can begin making our signs, we need to do a few things.


Firstly, let's make our test to make certain that the player is in the shop.

/scoreboard objectives add inShop dummy

Next, we need to make the trigger that will allow the player to show that they wish to buy something.

/scoreboard objectives add Buy trigger

We'll set the buy trigger differently according to the item we wish to buy, that way, we have less conditionals to follow. You need to enable this trigger for all players every time a player enters the store.

I'll leave it to you to decide how the player is shown to be in the shop, but if they are in the shop, you should set inShop to a value above 0, and then back to 0 when they leave. If you want me to add a method that I would personally suggest for doing this, please leave a comment and I will do so.

Now that we've set up our objectives, it's time to move onto command blocks that will permit us to see whether or not our player is buying an item. Set up a repeating command block with the following command:

/scoreboard players test @a[score_inStore_min=1] Buy 1 16

Replace 16 with however many different buy options you have. This block returns whether or not players inside the shop are currently buying anything, and is seen as the leftmost block in System 1. We still want to keep inShop as a test case to prevent players outside of the shop from buying items.

Now we need to set up the blocks that will actually trigger when affected. The next block in the sequence should be an always active conditional chain command block with the following command:

/execute @p[score_Buy_min=1,score_Buy=1] ~ ~ ~ setblock <x> <y> <z> redstone_block

Replace with coords directly beneath the bottom command block of System 2. You cannot use ~ ~1 ~, as this will be in reference to the player.

The bottom command block, an impulse block, should be activated by the previous command's redstone setblock, and should reset that block to air using the following command:

/setblock ~ ~-1 ~ air

In the next couple of command blocks, you should change <desired cost> to the desired cost, and similarly with <desired item> The always active chain command block above it should contain the following command:

/give @a[score_Buy_min=1,score_Buy=1,score_inStore_min=1,score_money_min=<desired cost>] <desired item>

Then, the next up:

/scoreboard players remove @a[score_Buy_min=1,score_Buy=1,score_inStore_min=1,score_money_min=<desired cost>] money <desired cost>

The final block up:

/scoreboard players set @a[score_Buy_min=1,score_Buy=1,score_inStore_min=1] Buy 0


The rightmost command block of System 1 should contain the following command:

/scoreboard players enable @a Buy

How to extend with this process

We used score_Buy_min=1,score_Buy=1 for our selector conditionals previously; to continue, simply add another chain command block (unconditional this time) before the final command block in System 1 with the following contents:

/execute @p[score_Buy_min=<number>,score_Buy=<number>] ~ ~ ~ setblock <x> <y> <z> redstone_block

Simply replace <number> with the next Buy value, and repeat the steps for System 2 directly above this block in the same fashion.

We now have an extendable system for trade! Now onto the signage.

Using sign clickEvents

If you don't already have a sign generator, you can use this one. Change the Command Type box to "Set Block" and fill in the text information as you see fit. For our purposes, I have posted a simple possible result based on the information specified in the question using the Buy value of 1.

/give @p sign 1 0 {BlockEntityTag:{Text1:"{\"text\":\"Wooden Pickaxe\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"trigger Buy set 1\"}}"}}

This is a sign that looks like this:


And, when run, will act as though the player has executed the following from the command line:

/trigger Buy set 1

You now have a clickable buying mechanism.

If you need any clarifications, let me know, and I'll do my best to answer them.

  • For the /scoreboard objectives add Buy trigger you think I should enable and remove it depending on weather the player is in the shop? Is there any disadvantages for not disabling it?
    – Jason_
    Commented Mar 10, 2016 at 21:54
  • @Jason_ Rather, there are no advantages to disabling it. Since these commands only apply to players within the range anyways, their Buy triggers will be retained until they are within the area. Also, there is no way to disable an objective without entirely removing it, which is problematic. Commented Mar 10, 2016 at 21:55
  • So in this case the player closest who clicks the sign will be given the item, correct?
    – Jason_
    Commented Mar 10, 2016 at 22:26
  • @Jason_ The person who clicks the sign, regardless of distance, will be given the item if they have the money for it (which is later deducted). Commented Mar 10, 2016 at 22:36
  • When the player enters the entrance should I use a testfor command to activate the other Scoreboards inShop and Buy? Or is there a more reliable way?
    – Jason_
    Commented Mar 10, 2016 at 22:51

Use a custom sign with a 'click_on' command such as '/trigger bought_pickaxe_w'. Have some command blocks on a clock with your commands, as well as '/scoreboard players set @a[score_bought_pickaxe_w_min=1] bought_pickaxe_w 0'.

If you dont know how to put commands on signs, then look at this link on Minecraft Wiki which will explain you how to use JSON on a sign.

  • Are you suggesting a new scoreboard also?
    – Jason_
    Commented Mar 10, 2016 at 17:36
  • I have a feeling this may be generalised from the information in @VTCAKAVSMoACE's answer Commented Nov 28, 2016 at 8:20
  • @FungusKing I have a feeling that an answer posted at 4:14 pm can't be taken in any way from a similar answer posted at 8:38 on the same day.
    – Angelica
    Commented Nov 28, 2016 at 19:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .