How can I test a players inventory for 5 or more emeralds?
Currently I have this command, but it only detects if the player has exactly 5:
execute if entity @p[x=-2104,y=54,z=-2153,distance=..6,nbt={Inventory:[{id:"minecraft:emerald",Count:5b}]}]
I tried some of the new range syntax for 1.13 replacing Count:5b with Count:5..b and Count5b.., but neither works.
Well first, make sure you do have the scoreboard "b"
Edit: Oh, I see why...
execute as @a[x=-2104,y=54,z=-2153,distance=..6] store result score @s b run clear @s emerald 0
Here's the fix.
Third, apparently if you /clear players 0 items, the result will store how many of that item is in your inventory.
I pieced a few things together after looking up this new execute/store function
Ended up using this for a shop:
/execute store result score @p[gamemode=adventure,x=-2104,y=54,z=-2153,distance=..6] isEmeraldCount run clear @p[gamemode=adventure,x=-2104,y=54,z=-2153,distance=..6] minecraft:emerald 0
with a chain command after using this:
execute if score @p[gamemode=adventure,x=-2104,y=54,z=-2153,distance=..6] isEmeraldCount matches 15.. run clear @p[gamemode=adventure,x=-2104,y=54,z=-2153,distance=..6] minecraft:emerald 15
Had no idea you could store properties as a score now, or that the clear command is somehow what you use to test for an amount of an item rather than NBT data. But you helped me find exactly what I needed including testing for an inventories total.
I'd just like to point out that you should use "as [target]" instead of repeating the same selector multiple times. It's much more efficient both in terms of performance as well as for typing. You'd use the "@s" selector in other parts of the same command in order to target the entity selected by "as [target]". It will be nearly identical to what YMbrothers provided:
/execute as @p[gamemode=adventure,x=-2104,y=54,z=-2153,distance=..6] store result score @s isEmeraldCount run clear @s minecraft:emerald 0
For your second command, you do not need to use /execute at all. Since /clear has a selector, just use that and the "scores" parameter, which again reduces duplicate selectors, boosting performance and readability:
I'd just like to point out that you should use "as [target]" instead of repeating the same selector multiple times. It's much more efficient both in terms of performance as well as for typing. You'd use the "@s" selector in other parts of the same command in order to target the entity selected by "as [target]". It will be nearly identical to what YMbrothers provided:
/execute as @p[gamemode=adventure,x=-2104,y=54,z=-2153,distance=..6] store result score @s isEmeraldCount run clear @s minecraft:emerald 0
"/execute as [target]" will fail if that target is not an op.
Quote from undefined »
For your second command, you do not need to use /execute at all. Since /clear has a selector, just use that and the "scores" parameter, which again reduces duplicate selectors, boosting performance and readability:
Those two commands have different result in multiplayer. The original command will test if the nearest player has a number of a score while your command will find the nearest player who has a number of score.
"/execute as [target]" will fail if that target is not an op.
Those two commands have different result in multiplayer. The original command will test if the nearest player has a number of a score while your command will find the nearest player who has a number of score.
For the first, are you sure? I know this was an issue with the old CommandStats system, but this is much different. I cannot test it myself unfortunately. If this is the case, can you provide a link to the bug report?
For the second, the end result is the same. Using "if entity" followed by performing a command on the exact same target is no different than having a redundant /testfor command pre-1.13.
EDIT: I've conferred with the /r/MinecraftCommands discord server who can confirm that both "execute as" and "execute store" do not require the target to be an OP. Make sure you're not having permission clashes from something like Spigot.
For the first, that's just what I think. Minecraft will execute as if the player is the executor, so it might fail il that player is not an op?
For the second, that's when "if entity" is used, but this is "if score" so that's different.
For the first it's not the case. "/execute as" marks the player as a 'command sender', which is not reliant on the player being an OP. It primarily means that the target is the one to target with "@s" (though there are some other things, such as who is sent command feedback as controlled by "sendCommandFeedback" gamerule). Prior to 1.13, a 'command sender' also included XYZ location for command execution, though in 1.13 that has been split into "at".
For the second, it still doesn't matter. The "if score" being used is equivalent to the "scores" selector parameter. While "if score" in general does have some extra options, the command that was being used did not use them, thus it could simply be removed in favor of the "scores" parameter.
I tested. For the first, the command still execute even when the target is not an op. For the second, it really matter. The command I used was:
/scoreboard objectives add a dummy
Then I summoned a villager and type:
/scoreboard players set @e[type=!player] a 1
/execute if score @e[sort=nearest,limit=1] a matches 1 run say hi
The chat still empty.
It's likely because you're targeting the wrong entity. You specify "type=!player" in the first selector but don't do that in the second, meaning it's going to target you instead.
And even so, it's irrelevant. I'm specifically talking about the original command in the thread. I'm not about to go through every hypothetical situation when the specific situation in the original topic doesn't need "if score".
That's the point. Original command test if nearest player has isEmeraldCount matches 15.. while your command finds the nearest player with score isEmeraldCount matches 15. Think about a case when a player with 15 emeralds come in, get a score isEmeraldCount of 15, then other player with less than 15 emerald come in, nearer than the first one. The first player drop his emeralds then the second press the button. Because the first command only update the score of the nearest player, your command still recognises the first player has 15 isEmeraldCount score and remove emeralds from him while the original command does not.
That's the point. Original command test if nearest player has isEmeraldCount matches 15.. while your command finds the nearest player with score isEmeraldCount matches 15. Think about a case when a player with 15 emeralds come in, get a score isEmeraldCount of 15, then other player with less than 15 emerald come in, nearer than the first one. The first player drop his emeralds then the second press the button. Because the first command only update the score of the nearest player, your command still recognises the first player has 15 isEmeraldCount score and remove emeralds from him while the original command does not.
I will break down the commands presented in the thread by OP and myself. This has nothing to do with somebody "coming in" and breaking something. That situation literally cannot happen because I'm talking about one command, not multiple. And even then, unless you're using redstone (which you absolutely should not be doing since 1.9), commands are going to run in the specified order before any player movement is handled. The only way player movement could break that is if you used a command mixed in with your detection commands to teleport players around. But that would be the map-maker purposefully breaking it, which isn't an argument.
OP's:
execute if score @p[gamemode=adventure,x=-2104,y=54,z=-2153,distance=..6] isEmeraldCount matches 15.. run clear @p[gamemode=adventure,x=-2104,y=54,z=-2153,distance=..6] minecraft:emerald 15
The first command checks if a player with a score exists. Then, a second time, it checks if that same player exists. Then it clears the emeralds.
The second command checks if a player with a score exists. Then it clears the emeralds.
The second command is the equivalent of the first, without the unnecessary fluff from /execute. They are logically the same, but the second one is much more efficient.
To reiterate, look at both of the selectors in the first command. They are exactly the same. It is therefore redundant and, while normally with /execute, you'd use "as [target]" to remove the redundancy and use "@s" for nested selectors (which is highly efficient). But since you don't need /execute for this operation, it can be removed. The reason you don't need it is because the "if score [target] isEmeraldCount matches 15" is literally the same as "scores={isEmeraldCount=15}" and that same exact player was being targeted in the first command anyways.
They aren't the same. OP's command check for nearest player's score, only the nearest player is affected by that command. Yours find the nearest player who has that score, which mean if can affect the second nearest player if the nearest doesn't match the requirement.
For example, two players stand in range, one with 15 isEmeraldCount, stand further than the second who has 5 isEmeraldCount from the command block. When OP's command is triggered, it finds the nearest player then test his score. Because his isEmeraldCount score is only 5, the command fail. When your command is triggered, if finds the nearest player who has 15 isEmeraldCount, which means the first player who stand further from the command block meets the requirement.The command still success.
They aren't the same. OP's command check for nearest player's score, only the nearest player is affected by that command. Yours find the nearest player who has that score, which mean if can affect the second nearest player if the nearest doesn't match the requirement.
For example, two players stand in range, one with 15 isEmeraldCount, stand further than the second who has 5 isEmeraldCount from the command block. When OP's command is triggered, it finds the nearest player then test his score. Because his isEmeraldCount score is only 5, the command fail. When your command is triggered, if finds the nearest player who has 15 isEmeraldCount, which means the first player who stand further from the command block meets the requirement.The command still success.
Uh hey.... Don't mind if I intervene (or interfere, depends...)
Judging from what the OP wants to do, he's probably attaching a comparator or a conditioned command block to the command block.
That block should enabled certain repeating command chains when /clear is successful.
Hence, it shouldn't matter who will get their emerald cleared, but who will be able to give the 15 emeralds.
I'm not biased, but Skylinerw's command seems to be the simplest. Just...... 1 addition...
I'd just like to point out that you should use "as [target]" instead of repeating the same selector multiple times. It's much more efficient both in terms of performance as well as for typing. You'd use the "@s" selector in other parts of the same command in order to target the entity selected by "as [target]". It will be nearly identical to what YMbrothers provided:
/execute as @p[gamemode=adventure,x=-2104,y=54,z=-2153,distance=..6] store result score @s isEmeraldCount run clear @s minecraft:emerald 0
For your second command, you do not need to use /execute at all. Since /clear has a selector, just use that and the "scores" parameter, which again reduces duplicate selectors, boosting performance and readability:
The first command makes a lot of sense, it is probably good practice to make sure targets don't change. I'll keep this in mind from now on.
The second part I used execute instead of a clear command because I could not find a way to make sure the player has 15 or more emeralds. Using the new syntax of 15.. ( EX: scores={isEmeraldCount=15..} ) doesn't find the target, and =15 in scores requires exactly 15.
I am not worried about multiplayer functions existing otherwise, since I'm just making a single player game. Only making sure I don't target players in spectator mode.
The first command makes a lot of sense, it is probably good practice to make sure targets don't change. I'll keep this in mind from now on.
The second part I used execute instead of a clear command because I could not find a way to make sure the player has 15 or more emeralds. Using the new syntax of 15.. ( EX: scores={isEmeraldCount=15..} ) doesn't find the target, and =15 in scores requires exactly 15.
I am not worried about multiplayer functions existing otherwise, since I'm just making a single player game. Only making sure I don't target players in spectator mode.
ok, this could help me, but i am completely lost. could someone explain to me what this is saying?
(how it works, what i need to do to setup, etc.)
This one's quite an old thread. It might be easier to start a thread of your own.
But basically, we're arguing (or debating, uh... whatever...) about which command is "more" correct and satisfy what the OP (original poster, not operator) needs.
Take Skylinerw's solution mixing with my slight addition as example:
/execute as @p[gamemode=adventure,x=-2104,y=54,z=-2153,distance=..6] store result score @s isEmeraldCount run clear @s minecraft:emerald 0
/clear @p[gamemode=adventure,x=-2104,y=54,z=-2153,distance=..6,scores={isEmeraldCount=15..}] minecraft:emerald 15
These 2 command runs in impulse mode, activated by a button/lever/(other types of signal), and there's a comparator attached to the 2nd command. But you need to create the scoreboard in order for things to work. Here's a sample command to do so:
/scoreboard objectives add isEmeraldCount dummy
What's the 2 command above doing? Well, the 1st one stores the amount of emeralds a player has in a scoreboard (using /clear command in its unexpected way). The 2nd one clears the emerald from the nearest player who has 15+ emeralds.
Honestly, this solution doesn't suit my taste, it's probably because I raised my perfection standard... I feel like the command I provided 6 months ago is incomplete, but the OP probably won't come back and reply. So, like I said at the start, start your own thread so I/we can solve it for you.
How can I test a players inventory for 5 or more emeralds?
Currently I have this command, but it only detects if the player has exactly 5:
execute if entity @p[x=-2104,y=54,z=-2153,distance=..6,nbt={Inventory:[{id:"minecraft:emerald",Count:5b}]}]
I tried some of the new range syntax for 1.13 replacing Count:5b with Count:5..b and Count5b.., but neither works.
execute as[x=-2104,y=54,z=-2153,distance=..6] @a store result score @s b run clear @s emerald 0
Surprise! This actually stores the amount of emerald into the scoreboard "b".
This command as is seems to have the wrong formatting:
http://prntscr.com/ku7mbu
But I'm also not sure what it is trying to do. How is it checking the players inventory for emeralds and storing that value?
Well first, make sure you do have the scoreboard "b"
Edit: Oh, I see why...
execute as @a[x=-2104,y=54,z=-2153,distance=..6] store result score @s b run clear @s emerald 0
Here's the fix.
Third, apparently if you /clear players 0 items, the result will store how many of that item is in your inventory.
I pieced a few things together after looking up this new execute/store function
Ended up using this for a shop:
/execute store result score @p[gamemode=adventure,x=-2104,y=54,z=-2153,distance=..6] isEmeraldCount run clear @p[gamemode=adventure,x=-2104,y=54,z=-2153,distance=..6] minecraft:emerald 0
with a chain command after using this:
execute if score @p[gamemode=adventure,x=-2104,y=54,z=-2153,distance=..6] isEmeraldCount matches 15.. run clear @p[gamemode=adventure,x=-2104,y=54,z=-2153,distance=..6] minecraft:emerald 15
Had no idea you could store properties as a score now, or that the clear command is somehow what you use to test for an amount of an item rather than NBT data. But you helped me find exactly what I needed including testing for an inventories total.
I'd just like to point out that you should use "as [target]" instead of repeating the same selector multiple times. It's much more efficient both in terms of performance as well as for typing. You'd use the "@s" selector in other parts of the same command in order to target the entity selected by "as [target]". It will be nearly identical to what YMbrothers provided:
For your second command, you do not need to use /execute at all. Since /clear has a selector, just use that and the "scores" parameter, which again reduces duplicate selectors, boosting performance and readability:
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
"/execute as [target]" will fail if that target is not an op.
Those two commands have different result in multiplayer. The original command will test if the nearest player has a number of a score while your command will find the nearest player who has a number of score.
ewe
For the first, are you sure? I know this was an issue with the old CommandStats system, but this is much different. I cannot test it myself unfortunately. If this is the case, can you provide a link to the bug report?
For the second, the end result is the same. Using "if entity" followed by performing a command on the exact same target is no different than having a redundant /testfor command pre-1.13.
EDIT: I've conferred with the /r/MinecraftCommands discord server who can confirm that both "execute as" and "execute store" do not require the target to be an OP. Make sure you're not having permission clashes from something like Spigot.
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
For the first, that's just what I think. Minecraft will execute as if the player is the executor, so it might fail il that player is not an op?
For the second, that's when "if entity" is used, but this is "if score" so that's different.
ewe
For the first it's not the case. "/execute as" marks the player as a 'command sender', which is not reliant on the player being an OP. It primarily means that the target is the one to target with "@s" (though there are some other things, such as who is sent command feedback as controlled by "sendCommandFeedback" gamerule). Prior to 1.13, a 'command sender' also included XYZ location for command execution, though in 1.13 that has been split into "at".
For the second, it still doesn't matter. The "if score" being used is equivalent to the "scores" selector parameter. While "if score" in general does have some extra options, the command that was being used did not use them, thus it could simply be removed in favor of the "scores" parameter.
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
I tested. For the first, the command still execute even when the target is not an op. For the second, it really matter. The command I used was:
/scoreboard objectives add a dummy
Then I summoned a villager and type:
/scoreboard players set @e[type=!player] a 1
/execute if score @e[sort=nearest,limit=1] a matches 1 run say hi
The chat still empty.
ewe
It's likely because you're targeting the wrong entity. You specify "type=!player" in the first selector but don't do that in the second, meaning it's going to target you instead.
And even so, it's irrelevant. I'm specifically talking about the original command in the thread. I'm not about to go through every hypothetical situation when the specific situation in the original topic doesn't need "if score".
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
That's the point. Original command test if nearest player has isEmeraldCount matches 15.. while your command finds the nearest player with score isEmeraldCount matches 15. Think about a case when a player with 15 emeralds come in, get a score isEmeraldCount of 15, then other player with less than 15 emerald come in, nearer than the first one. The first player drop his emeralds then the second press the button. Because the first command only update the score of the nearest player, your command still recognises the first player has 15 isEmeraldCount score and remove emeralds from him while the original command does not.
ewe
I will break down the commands presented in the thread by OP and myself. This has nothing to do with somebody "coming in" and breaking something. That situation literally cannot happen because I'm talking about one command, not multiple. And even then, unless you're using redstone (which you absolutely should not be doing since 1.9), commands are going to run in the specified order before any player movement is handled. The only way player movement could break that is if you used a command mixed in with your detection commands to teleport players around. But that would be the map-maker purposefully breaking it, which isn't an argument.
OP's:
Mine:
The first command checks if a player with a score exists. Then, a second time, it checks if that same player exists. Then it clears the emeralds.
The second command checks if a player with a score exists. Then it clears the emeralds.
The second command is the equivalent of the first, without the unnecessary fluff from /execute. They are logically the same, but the second one is much more efficient.
To reiterate, look at both of the selectors in the first command. They are exactly the same. It is therefore redundant and, while normally with /execute, you'd use "as [target]" to remove the redundancy and use "@s" for nested selectors (which is highly efficient). But since you don't need /execute for this operation, it can be removed. The reason you don't need it is because the "if score [target] isEmeraldCount matches 15" is literally the same as "scores={isEmeraldCount=15}" and that same exact player was being targeted in the first command anyways.
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
They aren't the same. OP's command check for nearest player's score, only the nearest player is affected by that command. Yours find the nearest player who has that score, which mean if can affect the second nearest player if the nearest doesn't match the requirement.
For example, two players stand in range, one with 15 isEmeraldCount, stand further than the second who has 5 isEmeraldCount from the command block. When OP's command is triggered, it finds the nearest player then test his score. Because his isEmeraldCount score is only 5, the command fail. When your command is triggered, if finds the nearest player who has 15 isEmeraldCount, which means the first player who stand further from the command block meets the requirement.The command still success.
ewe
Uh hey.... Don't mind if I intervene (or interfere, depends...)
Judging from what the OP wants to do, he's probably attaching a comparator or a conditioned command block to the command block.
That block should enabled certain repeating command chains when /clear is successful.
Hence, it shouldn't matter who will get their emerald cleared, but who will be able to give the 15 emeralds.
I'm not biased, but Skylinerw's command seems to be the simplest. Just...... 1 addition...
/clear @p[gamemode=adventure,x=-2104,y=54,z=-2153,distance=..6,scores={isEmeraldCount=15..}] minecraft:emerald 15
The first command makes a lot of sense, it is probably good practice to make sure targets don't change. I'll keep this in mind from now on.
The second part I used execute instead of a clear command because I could not find a way to make sure the player has 15 or more emeralds. Using the new syntax of 15.. ( EX: scores={isEmeraldCount=15..} ) doesn't find the target, and =15 in scores requires exactly 15.
I am not worried about multiplayer functions existing otherwise, since I'm just making a single player game. Only making sure I don't target players in spectator mode.
It doesn't matter whether the count is 15 or 15..
What matters is whether you're in that ..6 block range and if the scoreboard DID show 15 or more.
(/scoreboard objectives setdisplay sidebar isEmeraldCount is the command to check the score, in case you don't know.)
ok, this could help me, but i am completely lost. could someone explain to me what this is saying?
(how it works, what i need to do to setup, etc.)
This one's quite an old thread. It might be easier to start a thread of your own.
But basically, we're arguing (or debating, uh... whatever...) about which command is "more" correct and satisfy what the OP (original poster, not operator) needs.
Take Skylinerw's solution mixing with my slight addition as example:
These 2 command runs in impulse mode, activated by a button/lever/(other types of signal), and there's a comparator attached to the 2nd command. But you need to create the scoreboard in order for things to work. Here's a sample command to do so:
/scoreboard objectives add isEmeraldCount dummy
What's the 2 command above doing? Well, the 1st one stores the amount of emeralds a player has in a scoreboard (using /clear command in its unexpected way). The 2nd one clears the emerald from the nearest player who has 15+ emeralds.
Honestly, this solution doesn't suit my taste, it's probably because I raised my perfection standard... I feel like the command I provided 6 months ago is incomplete, but the OP probably won't come back and reply. So, like I said at the start, start your own thread so I/we can solve it for you.