I currently am working on a multiplayer friendly custom crafting, and I've come across a problem. A BIG problem. You can't use testforblocks because it's not multiplayer friendly. So I was wondering if I could eliminate that with /stats block because that would allow for it to be stored in a scoreboard objective instead, making it work perfectly in multiplayer.
That's a solution, yes. You can use the "SuccessCount" CommandStat targeting the iniator (@p), while causing the players to run the intended /testforblocks command via /execute. Their own score is set to 1 if the command succeeded, and 0 if it did not. Keep in mind that their score will be modified for any other commands run through them. You should also be able to use "AffectedBlocks" for a more specific detection.
That's a solution, yes. You can use the "SuccessCount" CommandStat targeting the iniator (@p), while causing the players to run the intended /testforblocks command via /execute. Their own score is set to 1 if the command succeeded, and 0 if it did not. Keep in mind that their score will be modified for any other commands run through them. You should also be able to use "AffectedBlocks" for a more specific detection.
I barely know anything about /stats, and even the wiki was pretty vague (to me at least) so could you elaborate on that?
I barely know anything about /stats, and even the wiki was pretty vague (to me at least) so could you elaborate on that?
Sure! A CommandStat acts as a trigger, which is activated when a command is run. The trigger modifies a scoreboard score based on the success of the command being run. CommandStats can be applied to anything that can run commands, which includes entities, command blocks, and signs. Failed commands always set the score to 0. Here's a list of different triggers, explaining how the score being set is determined:
SuccessCount
The number times the command was run successfully; essentially the same as using a comparator for signal strength output but without the redstone limitation. For example, "/testforblocks" can only succeed once, so the score cannot exceed 1. "/testfor @a" will provide the number of players found.
AffectedBlocks
The number of blocks affected by the command. "/clone" will provide the number of total blocks cloned, while using "/clone" with SuccessCount will only provide a value of 1.
AffectedEntities
The number of entities affected by the command, which is usually the same as SuccessCount but restricted to commands that target entities. "/testfor @a" returns the number of players found.
Affecteditems
The number of items in an inventory that was modified/found. For example, doing "/clear" will provide the total number of items within the player's inventory. Using "/clear @p minecraft:stone 0 0" will not physically remove any items, but will still provide the number of items that could have been removed. "/replaceitem" can only succeed once with SuccessCount, but is set to the number of items placed into the slot (does not consider any items lost during that process though).
QueryResult
This one's a bit different. There are a couple commands that have a specific function for returning a value. This includes "/time query", which tells you the current time in ticks, and "/gamerule [name]", which tells you the value of the gamerule, if it exists. Using this CommandStat will set the score equal to the returned value.
The /stats command allows you to easily apply CommandStats to targets, although you can apply the NBT data directly if using /setblock or /summon.
I'll get into setting it up for /testforblocks.
Prerequisites:
An objective to hold the score that a CommandStat will use.
/scoreboard objectives add BLOCKS dummy
CommandStat:
When using CommandStats, you may need to have the following commands running on a slow clock in order to affect new players joining the server. If the game as a whole does not need to do this, then you can apply the CommandStats before the game begins. It's solely dependent on the game.
The CommandStat to apply to player targets using the "AffectedBlocks" trigger. Whenever the player runs a command that modifies blocks, their own "BLOCKS" score will be set equal to the number of blocks modified.
/stats entity @a set AffectedBlocks @p BLOCKS
In order for CommandStats to modify a score, the target must already be tracked on the scoreboard. You can 'add 0' to the target's score in order to force them onto the scoreboard with a default score of 0, while not modifying scores already stored.
/scoreboard players add @a BLOCKS 0
Triggering:
In order to cause the trigger to fire, have the player run a command.
/execute @a ~ ~ ~ testforblocks . . .
Their "BLOCKS" score will be set equal to the number of blocks matched if there was a perfect match, or 0 if the command itself failed to find a perfect match.
Detecting:
From there, you can target players based on their "BLOCKS" score. For example, the following will say the name of players who had a perfect match:
/say @a[score_BLOCKS_min=1]
And the following should cause the players to announce how many blocks they matched. I currently can't check in-game, but this is assuming /testforblocks will provide "AffectedBlocks" the number of matching blocks upon success:
Sure! A CommandStat acts as a trigger, which is activated when a command is run. The trigger modifies a scoreboard score based on the success of the command being run. CommandStats can be applied to anything that can run commands, which includes entities, command blocks, and signs. Failed commands always set the score to 0. Here's a list of different triggers, explaining how the score being set is determined:
SuccessCount
The number times the command was run successfully; essentially the same as using a comparator for signal strength output but without the redstone limitation. For example, "/testforblocks" can only succeed once, so the score cannot exceed 1. "/testfor @a" will provide the number of players found.
AffectedBlocks
The number of blocks affected by the command. "/clone" will provide the number of total blocks cloned, while using "/clone" with SuccessCount will only provide a value of 1.
AffectedEntities
The number of entities affected by the command, which is usually the same as SuccessCount but restricted to commands that target entities. "/testfor @a" returns the number of players found.
Affecteditems
The number of items in an inventory that was modified/found. For example, doing "/clear" will provide the total number of items within the player's inventory. Using "/clear @p minecraft:stone 0 0" will not physically remove any items, but will still provide the number of items that could have been removed. "/replaceitem" can only succeed once with SuccessCount, but is set to the number of items placed into the slot (does not consider any items lost during that process though).
QueryResult
This one's a bit different. There are a couple commands that have a specific function for returning a value. This includes "/time query", which tells you the current time in ticks, and "/gamerule [name]", which tells you the value of the gamerule, if it exists. Using this CommandStat will set the score equal to the returned value.
The /stats command allows you to easily apply CommandStats to targets, although you can apply the NBT data directly if using /setblock or /summon.
I'll get into setting it up for /testforblocks.
Prerequisites:
An objective to hold the score that a CommandStat will use.
/scoreboard objectives add BLOCKS dummy
CommandStat:
When using CommandStats, you may need to have the following commands running on a slow clock in order to affect new players joining the server. If the game as a whole does not need to do this, then you can apply the CommandStats before the game begins. It's solely dependent on the game.
The CommandStat to apply to player targets using the "AffectedBlocks" trigger. Whenever the player runs a command that modifies blocks, their own "BLOCKS" score will be set equal to the number of blocks modified.
/stats entity @a set AffectedBlocks @p BLOCKS
In order for CommandStats to modify a score, the target must already be tracked on the scoreboard. You can 'add 0' to the target's score in order to force them onto the scoreboard with a default score of 0, while not modifying scores already stored.
/scoreboard players add @a BLOCKS 0
Triggering:
In order to cause the trigger to fire, have the player run a command.
/execute @a ~ ~ ~ testforblocks . . .
Their "BLOCKS" score will be set equal to the number of blocks matched if there was a perfect match, or 0 if the command itself failed to find a perfect match.
Detecting:
From there, you can target players based on their "BLOCKS" score. For example, the following will say the name of players who had a perfect match:
/say @a[score_BLOCKS_min=1]
And the following should cause the players to announce how many blocks they matched. I currently can't check in-game, but this is assuming /testforblocks will provide "AffectedBlocks" the number of matching blocks upon success:
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 barely know anything about /stats, and even the wiki was pretty vague (to me at least) so could you elaborate on that?
Sure! A CommandStat acts as a trigger, which is activated when a command is run. The trigger modifies a scoreboard score based on the success of the command being run. CommandStats can be applied to anything that can run commands, which includes entities, command blocks, and signs. Failed commands always set the score to 0. Here's a list of different triggers, explaining how the score being set is determined:
SuccessCount
The number times the command was run successfully; essentially the same as using a comparator for signal strength output but without the redstone limitation. For example, "/testforblocks" can only succeed once, so the score cannot exceed 1. "/testfor @a" will provide the number of players found.
AffectedBlocks
The number of blocks affected by the command. "/clone" will provide the number of total blocks cloned, while using "/clone" with SuccessCount will only provide a value of 1.
AffectedEntities
The number of entities affected by the command, which is usually the same as SuccessCount but restricted to commands that target entities. "/testfor @a" returns the number of players found.
Affecteditems
The number of items in an inventory that was modified/found. For example, doing "/clear" will provide the total number of items within the player's inventory. Using "/clear @p minecraft:stone 0 0" will not physically remove any items, but will still provide the number of items that could have been removed. "/replaceitem" can only succeed once with SuccessCount, but is set to the number of items placed into the slot (does not consider any items lost during that process though).
QueryResult
This one's a bit different. There are a couple commands that have a specific function for returning a value. This includes "/time query", which tells you the current time in ticks, and "/gamerule [name]", which tells you the value of the gamerule, if it exists. Using this CommandStat will set the score equal to the returned value.
The /stats command allows you to easily apply CommandStats to targets, although you can apply the NBT data directly if using /setblock or /summon.
I'll get into setting it up for /testforblocks.
Prerequisites:
An objective to hold the score that a CommandStat will use.
CommandStat:
When using CommandStats, you may need to have the following commands running on a slow clock in order to affect new players joining the server. If the game as a whole does not need to do this, then you can apply the CommandStats before the game begins. It's solely dependent on the game.
The CommandStat to apply to player targets using the "AffectedBlocks" trigger. Whenever the player runs a command that modifies blocks, their own "BLOCKS" score will be set equal to the number of blocks modified.
In order for CommandStats to modify a score, the target must already be tracked on the scoreboard. You can 'add 0' to the target's score in order to force them onto the scoreboard with a default score of 0, while not modifying scores already stored.
Triggering:
In order to cause the trigger to fire, have the player run a command.
Their "BLOCKS" score will be set equal to the number of blocks matched if there was a perfect match, or 0 if the command itself failed to find a perfect match.
Detecting:
From there, you can target players based on their "BLOCKS" score. For example, the following will say the name of players who had a perfect match:
And the following should cause the players to announce how many blocks they matched. I currently can't check in-game, but this is assuming /testforblocks will provide "AffectedBlocks" the number of matching blocks upon success:
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/
Thanks! I really needed that, as I pretty much have no experience in /stats.
this should help me a lot with what I'm working on