Actually, it is impossible to detect when a mob dies with scoreboards or nbt checking; when a mob dies they lose all of their scoreboard objectives and the ability to be detected with a command block (wasn't always this way, but it is now). If you don't want to use loot tables, the best way to detect if a mob died is with an advancement. Use https://minecraft.gamepedia.com/Advancements and https://minecraft.gamepedia.com/Advancements/List_of_triggers for the best tutorials. Try to create an advancement that is invisible, re-enabled every tick, and uses the trigger "player_killed_entity". Despite the fact that you are unable to summon an item directly where the mob died and have to give the item to the player directly, you gain compatibility with other datapacks.
If you don't like this solution, there is also a long-winded method that involves summoning an armor stand at every entity every tick, checking after each tick at the armor stands if there is a mob still there. You would kill & check each armor stand and tag every entity checked. Every tick. This would be very laggy, but it solves the problem.
To be honest, the best solution is still loot tables, though mojang decided not to add the ability to append your loot tables to the defaults. This means that if you use loot tables you lose compatibility with any other datapack that modifies loot tables as well.
It's a bit unclear what you're trying to ask; however, I can teach you how to divide scoreboard objectives if that's what you want.
In code, I assume what you want to do is:
mWalked = cmWalked / 100
This means set "mWalked" to "cmWalked" divided by 100. Unfortunately, doing this with scoreboards is currently impossible. However, you can work around Minecraft's limitations with this kind of code instead:
1. Set the value of some other scoreboard objective to 100. This is important because we cannot divide by 100 directly. Command:
/scoreboard players set Fake_Player some_other_score 100.
2. Copy the value of cmWalked into mWalked for every player. Command:
/execute as @a run scoreboard players operation @s mWalked = @s cmWalked
3. Divide the value of mWalked by the score set earlier. Command:
/execute as @a run scoreboard players operation @s mWalked /= Fake_Player some_other_score
You need to make sure that "some_other_score" is a real score, and you should note that "Fake_Player" can be anything. I recommend changing "Fake_Player" to "100" for easier readability, though it doesn't matter what you change it to.
So I recently created a datapack that plays custom music based upon the situation you are in (https://www.curseforge.com/minecraft/customization/trigger-the-music), but it doesn't have custom music that plays based upon if its raining due to the fact that detecting Minecraft rain is complicated. Detecting rain is actually one of the main bottlenecks in creating ambient noises, since I don't want birds to be chirping during a storm. I've figured out two different ways of doing it relative to each player, and I need help deciding which one is better; please don't vote if you don't understand this post.
1: Detecting rain with an entity. This method involves summoning an invisible armor stand that is on fire (above the world height so it doesn't get in the way of players by flickering) above each player that will have its fire tag put out prematurely if its raining. I can then detect if the armor stand is on fire, kill the armor stand, and run the checking mechanism again after so many ticks.
Pros:
Compatibility. Will work with every other datapack that impacts the weather.
Simple. Doesn't confuse players by making it harder to change the weather.
Cons:
Laggy. The more players in the world, the more armor stands spawn.
Flickering. The armor stand flickers high up in the world due to it being on fire.
2: Detecting rain by overwriting the current weather system. This method involves permanently setting the gamerule doWeatherCycle to false and modifying weather manually with the datapack. I can instantly know what the global weather is simply by setting a scoreboard objective whenever I change the weather, and I know if its raining in a biome because I already have a biome scoreboard objective.
Pros:
Fast & Accurate. I know exactly what the weather is at all times because I set it manually.
Cons:
Confusing: Makes it harder for players to change the weather.
Incompatibility. Will not work with other datapacks that manually change the weather.
Lol, nice pun by the way. If you're on a server then you can do this easily with plugins; however, you probably want to do this without them. The main problem with giving players their own heads is that you can not store that player's NBT data (their name to be specific) into the head. Even with scoreboards and the /data command 1.13, this is still sadly impossible. However, when 1.14 comes out, you can modify the loot tables of players (using datapacks) to make them drop their own heads. I'm not exactly sure how these features work as of right now, but hopefully when they do come out you can use them (even though it is 2 months late)
First off, the selector @a[distance=100] is checking for a player that is precisely 100 blocks away from the command block rather than 100 blocks or less. To avoid any issues, use @a[distance=..100], which will check for a player within 100 blocks. Secondly, the summon command doesn't work with selectors; the /gamemode command uses selectors in order to determine which players to change the gamemode of. In order to only run a command when a specific entity is found, use the execute command: /execute if entity @a[distance=..2] run summon minecraft:elder_guardian ~ ~1 ~
When put into a repeating command block that is powered with redstone, this command will summon elder_guardians constantly when a player is within 2 blocks of the command block.
You could also split up the commands and do this:
Where the command block on the left is set to repeating and has the command
/execute if entity @a[distance=..5]
And the command block on the right has the command /summon minecraft:elder_guardian ~ ~1 ~
This will summon an Elder Guardian only once when the player gets close enough and again after they leave and come back.
Play around with the settings a bit more if you want too! You can actually change the location from where the distance is checked too with x, y, and z: @a[x=x,y=y,z=z,distance=..d] (replace x, y, and z with numbers).
This means you could actually place the command blocks below the ground and have them check if a player is right above them.
The syntax of the command is wrong. If you run /say @e[type=zombie], you will see that the zombie is not named, making him unable to be found by the kill command. If you look at the summon command very carefully, you will see that the CustomName:"\"Lock\"" tag is put inside of the ActiveEffects tag rather than with the ordinary tags (Invulnerable:1, Silent:1, NoAI:1, etc.). The correct command should look like this:
Commands are complicated and easy to loose track of. For many cases you can use MCStacker and or other generators to help you see where the errors are in your commands as soon as you get them.
I know it's an old post, but I found a replacement after researching for a few hours. I've wanted one of these two, and I found one for 1.7+. For 1.6.X you can use BookZ. But for anything above, you can use Ghostwriter. It is updated all the way to 1.12.2 as of today. I have no idea why Google had trouble finding it when I looked up "minecraft 1.12.2 book editor". For future viewers, you are welcome.
You should be okay to test for and setblock with no problem, provided you use the correct syntax and different scoreboard objectives. I find it interesting though, you never actually change the value of the "chesthasitem" objective (Unless you are using something behind the scenes, like a stats command); obviously it would never delete the block because there is no player that has a score of "chesthasitem" that is at least 1. a series of /testforblock commands to determine if the block near a player has an item in it. Keep in mind, if you want to test for the item in any inventory, you are going to have to test not only chests, but every other block that has an inventory as well. I can work on a function that could do this for you, but I suggest other simpler solutions if possible. Could I have a bit more information about what you are doing this on? Here are some questions that may help me determine another option if possible.
1. Are you doing this on an adventure map? If so, can your players place down any blocks that have inventory?
I figured as such, I may be able to fiddle with a few things if I want it sooner. I've got other things I can add for now, but this is a great idea I may add in the future.
I can't think of a simple solution other than by using plugins. To my knowledge, there is no way of testing for a specific item is in a chest other than by testing billions of billions of possibilities, and it is impossible to do this easily (correct me if I'm wrong). Also, note that you can't go too complex, functions lag if you run too many commands; I deal with it myself. You may be able to do a workaround for what you are trying to do though; could you tell me why you need to prevent the item from going into chests? The more background you give the better (just don't make it too long)
Edit:
I didn't realize that testing inventories of chests is similar to testing players inventories. This could be possible, see my response below
Commands in Minecraft BE are extremely tedious if you're on a console (I use Xbox One). I haven't checked out the Windows 10 version (I don't have Windows 10, but I assume it's easier). First of all, you cannot move back and forth on a command; if you want to edit something close to the beginning, you have to delete the whole command up until that point. Second, coordinates are difficult to distinguish if you are in creative and don't have your map (I lost mine and now cannot see my coords without typing "/tp ~ ~ ~"). Third, typing commands takes a very long time without some form of chatpad, and even with it. Finally, when you actually figure out how to use a clone or fill command and fail with it, you cannot undo (Have this problem with the Java Edition)
I suggest Mojang add these things to the Bedrock Edition:
1. The ability to move back and forth in a command
2. The ability to see some kind of debug screen (maybe in the pause menu or using another keybind, that would be helpful)
3. Autocompletion using a keybind or by pressing "A" on the screen
4. The /undo and /redo commands to undo and redo the last block-changing command in the server, maybe even could be used more than once (This would be helpful for the Java Edition as well)
Some people don't even know how a zipper works and are still able to use it. One day artificial intelligence will fully replace humans becauseit will be better than us at doing its job, belive it or not.
Be careful when speculating too far into the future, some people thought books would soon grow out of style, but with computers and mechanisms today they're as popular as ever. Personally, due to the large numbers of science-fiction books and movies based on robot takeovers, I think people would actually do everything in their power not to let that happen, if it would even be reasonable. Once again, we can't see too far into the future and can only make inferences, so all we can really do is pick the most reasonable answers and conclude based on the evidence.
There's no issue to use generators on something like one command generator (is this a thing).
Generators are rly the best tool to do repetitive stuff for humans. (Although I don't. Haha)
BUT if they rely on the generators, and just begging and shouting for help fixing the issues a generator causes, just imagine...
0
Actually, it is impossible to detect when a mob dies with scoreboards or nbt checking; when a mob dies they lose all of their scoreboard objectives and the ability to be detected with a command block (wasn't always this way, but it is now). If you don't want to use loot tables, the best way to detect if a mob died is with an advancement. Use https://minecraft.gamepedia.com/Advancements and https://minecraft.gamepedia.com/Advancements/List_of_triggers for the best tutorials. Try to create an advancement that is invisible, re-enabled every tick, and uses the trigger "player_killed_entity". Despite the fact that you are unable to summon an item directly where the mob died and have to give the item to the player directly, you gain compatibility with other datapacks.
If you don't like this solution, there is also a long-winded method that involves summoning an armor stand at every entity every tick, checking after each tick at the armor stands if there is a mob still there. You would kill & check each armor stand and tag every entity checked. Every tick. This would be very laggy, but it solves the problem.
To be honest, the best solution is still loot tables, though mojang decided not to add the ability to append your loot tables to the defaults. This means that if you use loot tables you lose compatibility with any other datapack that modifies loot tables as well.
0
It's a bit unclear what you're trying to ask; however, I can teach you how to divide scoreboard objectives if that's what you want.
In code, I assume what you want to do is:
This means set "mWalked" to "cmWalked" divided by 100. Unfortunately, doing this with scoreboards is currently impossible. However, you can work around Minecraft's limitations with this kind of code instead:
You can do this kind of thing in three steps:
1. Set the value of some other scoreboard objective to 100. This is important because we cannot divide by 100 directly. Command:
2. Copy the value of cmWalked into mWalked for every player. Command:
3. Divide the value of mWalked by the score set earlier. Command:
You need to make sure that "some_other_score" is a real score, and you should note that "Fake_Player" can be anything. I recommend changing "Fake_Player" to "100" for easier readability, though it doesn't matter what you change it to.
0
So I recently created a datapack that plays custom music based upon the situation you are in (https://www.curseforge.com/minecraft/customization/trigger-the-music), but it doesn't have custom music that plays based upon if its raining due to the fact that detecting Minecraft rain is complicated. Detecting rain is actually one of the main bottlenecks in creating ambient noises, since I don't want birds to be chirping during a storm. I've figured out two different ways of doing it relative to each player, and I need help deciding which one is better; please don't vote if you don't understand this post.
1: Detecting rain with an entity. This method involves summoning an invisible armor stand that is on fire (above the world height so it doesn't get in the way of players by flickering) above each player that will have its fire tag put out prematurely if its raining. I can then detect if the armor stand is on fire, kill the armor stand, and run the checking mechanism again after so many ticks.
Pros:
Compatibility. Will work with every other datapack that impacts the weather.
Simple. Doesn't confuse players by making it harder to change the weather.
Cons:
Laggy. The more players in the world, the more armor stands spawn.
Flickering. The armor stand flickers high up in the world due to it being on fire.
2: Detecting rain by overwriting the current weather system. This method involves permanently setting the gamerule doWeatherCycle to false and modifying weather manually with the datapack. I can instantly know what the global weather is simply by setting a scoreboard objective whenever I change the weather, and I know if its raining in a biome because I already have a biome scoreboard objective.
Pros:
Fast & Accurate. I know exactly what the weather is at all times because I set it manually.
Cons:
Confusing: Makes it harder for players to change the weather.
Incompatibility. Will not work with other datapacks that manually change the weather.
0
Lol, nice pun by the way. If you're on a server then you can do this easily with plugins; however, you probably want to do this without them. The main problem with giving players their own heads is that you can not store that player's NBT data (their name to be specific) into the head. Even with scoreboards and the /data command 1.13, this is still sadly impossible. However, when 1.14 comes out, you can modify the loot tables of players (using datapacks) to make them drop their own heads. I'm not exactly sure how these features work as of right now, but hopefully when they do come out you can use them (even though it is 2 months late)
1
First off, the selector @a[distance=100] is checking for a player that is precisely 100 blocks away from the command block rather than 100 blocks or less. To avoid any issues, use @a[distance=..100], which will check for a player within 100 blocks. Secondly, the summon command doesn't work with selectors; the /gamemode command uses selectors in order to determine which players to change the gamemode of. In order to only run a command when a specific entity is found, use the execute command:
/execute if entity @a[distance=..2] run summon minecraft:elder_guardian ~ ~1 ~
When put into a repeating command block that is powered with redstone, this command will summon elder_guardians constantly when a player is within 2 blocks of the command block.
You could also split up the commands and do this:
Where the command block on the left is set to repeating and has the command
/execute if entity @a[distance=..5]
And the command block on the right has the command
/summon minecraft:elder_guardian ~ ~1 ~
This will summon an Elder Guardian only once when the player gets close enough and again after they leave and come back.
Play around with the settings a bit more if you want too! You can actually change the location from where the distance is checked too with x, y, and z: @a[x=x,y=y,z=z,distance=..d] (replace x, y, and z with numbers).
This means you could actually place the command blocks below the ground and have them check if a player is right above them.
Happy to help out a fellow Tree Puncher!
0
The definition of this redstone circuit is called a demultiplexer (or demultiplexor). Here's the minecraft wiki article on it: https://minecraft.gamepedia.com/Miscellaneous_circuits#Demultiplexor
Here is a design I came up for a 5x3 demultiplexor:
0
The syntax of the command is wrong. If you run /say @e[type=zombie], you will see that the zombie is not named, making him unable to be found by the kill command. If you look at the summon command very carefully, you will see that the CustomName:"\"Lock\"" tag is put inside of the ActiveEffects tag rather than with the ordinary tags (Invulnerable:1, Silent:1, NoAI:1, etc.). The correct command should look like this:
/summon minecraft:zombie -48.42 63.00 298.75 {Invulnerable:1,Silent:1,NoAI:1,Rotation:[40f,0f],CustomName:"\"Lock\"",ActiveEffects:[{Id:14,Amplifier:0,Duration:999999,ShowParticles:0b}]}
Commands are complicated and easy to loose track of. For many cases you can use MCStacker and or other generators to help you see where the errors are in your commands as soon as you get them.
1
I know it's an old post, but I found a replacement after researching for a few hours. I've wanted one of these two, and I found one for 1.7+. For 1.6.X you can use BookZ. But for anything above, you can use Ghostwriter. It is updated all the way to 1.12.2 as of today. I have no idea why Google had trouble finding it when I looked up "minecraft 1.12.2 book editor". For future viewers, you are welcome.
1
You should be okay to test for and setblock with no problem, provided you use the correct syntax and different scoreboard objectives. I find it interesting though, you never actually change the value of the "chesthasitem" objective (Unless you are using something behind the scenes, like a stats command); obviously it would never delete the block because there is no player that has a score of "chesthasitem" that is at least 1. a series of /testforblock commands to determine if the block near a player has an item in it. Keep in mind, if you want to test for the item in any inventory, you are going to have to test not only chests, but every other block that has an inventory as well. I can work on a function that could do this for you, but I suggest other simpler solutions if possible. Could I have a bit more information about what you are doing this on? Here are some questions that may help me determine another option if possible.
1. Are you doing this on an adventure map? If so, can your players place down any blocks that have inventory?
2. Is this a survival world?
3. Do you just want the function?
0
I figured as such, I may be able to fiddle with a few things if I want it sooner. I've got other things I can add for now, but this is a great idea I may add in the future.
1
I can't think of a simple solution other than by using plugins.
To my knowledge, there is no way of testing for a specific item is in a chest other than by testing billions of billions of possibilities, and it is impossible to do this easily (correct me if I'm wrong).Also, note that you can't go too complex, functions lag if you run too many commands; I deal with it myself. You may be able to do a workaround for what you are trying to do though; could you tell me why you need to prevent the item from going into chests? The more background you give the better (just don't make it too long)Edit:
I didn't realize that testing inventories of chests is similar to testing players inventories. This could be possible, see my response below
0
Commands in Minecraft BE are extremely tedious if you're on a console (I use Xbox One). I haven't checked out the Windows 10 version (I don't have Windows 10, but I assume it's easier). First of all, you cannot move back and forth on a command; if you want to edit something close to the beginning, you have to delete the whole command up until that point. Second, coordinates are difficult to distinguish if you are in creative and don't have your map (I lost mine and now cannot see my coords without typing "/tp ~ ~ ~"). Third, typing commands takes a very long time without some form of chatpad, and even with it. Finally, when you actually figure out how to use a clone or fill command and fail with it, you cannot undo (Have this problem with the Java Edition)
I suggest Mojang add these things to the Bedrock Edition:
1. The ability to move back and forth in a command
2. The ability to see some kind of debug screen (maybe in the pause menu or using another keybind, that would be helpful)
3. Autocompletion using a keybind or by pressing "A" on the screen
4. The /undo and /redo commands to undo and redo the last block-changing command in the server, maybe even could be used more than once (This would be helpful for the Java Edition as well)
0
Be careful when speculating too far into the future, some people thought books would soon grow out of style, but with computers and mechanisms today they're as popular as ever. Personally, due to the large numbers of science-fiction books and movies based on robot takeovers, I think people would actually do everything in their power not to let that happen, if it would even be reasonable. Once again, we can't see too far into the future and can only make inferences, so all we can really do is pick the most reasonable answers and conclude based on the evidence.
Lol, I know how ASCII works.
I do agree though, it is important to know how something works so you can fix the issues that arise from it.
0
Interesting work, it's helpful to have a shower that doesn't drown us minecrafters in water
0
Could you be more specific about what you cannot set up right? A picture or video would also be helpful.