In 1.16.5 (I don't know about other versions), when place a block "text" and "italic" in the name becomes "italic" and "text" when you break it.
This means that you can detect custom blocks with the name tag that were broken by a player in survival mode.
Item frames are automatically centered when summoned, this can be used in conjunction with tagged firework rockets to get centered marker armor stands easily for custom blocks.
A comparator coming out of an always active repeating command block leading to a block holding a redstone torch leading to an iron door that was placed open makes a door that will only open if certain conditions are met and can't be triggered with other types of redstone, like a button or lever.
If a non-opped creative player is trapped in barriers (and with their head in a barrier) and each barrier has a tagged marker armor stand at its location and every tick a falling glass block is summoned, then the creative player cannot leave the 'cage'. Note: If you want to trap a non-opped survival player give them resistance 10 and saturation forever so they don't die from suffocation.
execute as @e[type=minecraft:armor_stand,tag=unbreakableglass] at @s unless block ~ ~ ~ minecraft:barrier run kill @s
execute at @e[type=minecraft:armor_stand,tag=unbreakableglass] run summon minecraft:falling_block ~ ~ ~ {BlockState:{Name:"minecraft:glass"},NoGravity:true}
A great thing about using tagged armorstands at the locations at custom blocks is that you can set their location to air and kill all of them to remove them quickly.
Giving an item frame the Invisibility:1b (I think) makes the item frame invisible, but not the item its holding.
If you have any tricks you would like to add, please do
Great tips! I do have a few Questions, Nitpicks, and Corrections though, I'll do them in order:
In 1.16.5 (I don't know about other versions), when place a block "text" and "italic" in the name becomes "italic" and "text" when you break it.
This means that you can detect custom blocks with the name tag that were broken by a player in survival mode.
That's cool, I didn't know that, however, block entities (blocks that can store data such as custom names) are very computationally taxing (cause a lot of lag) in large quantities, so to reduce that not all blocks can store data. Hence, not all blocks keep their name when placed and broken, so when using this you'd theoretically need to use a block entity (chest, furnace, banner, barrel, dispenser, beacon, etc.)
Item frames are automatically centered when summoned, this can be used in conjunction with tagged firework rockets to get centered marker armor stands easily for custom blocks.
Although this is true what advantage does this have over 'execute align'? Whenever I need to summon something centered 'execute align' is usually my go-to.
A comparator coming out of an always active repeating command block leading to a block holding a redstone torch leading to an iron door that was placed open makes a door that will only open if certain conditions are met and can't be triggered with other types of redstone, like a button or lever.
Cool trick once again, however, one small nitpick with it is able to be met and un-met quickly then there's a chance that the user could abuse that to burn out the torch. one workaround if this is the case is having 2 command blocks, one the sets the redstone torch if the condition is not met, and one that removes the redstone torch if it is. That way you won't have any problems with burnout. However, if your condition cannot be met and un-met that quickly then this way will work perfectly
If a non-opped creative player is trapped in barriers (and with their head in a barrier) and each barrier has a tagged marker armor stand at its location and every tick a falling glass block is summoned, then the creative player cannot leave the 'cage'. Note: If you want to trap a non-opped survival player give them resistance 10 and saturation forever so they don't die from suffocation.
execute as @e[type=minecraft:armor_stand,tag=unbreakableglass] at @s unless block ~ ~ ~ minecraft:barrier run kill @s
execute at @e[type=minecraft:armor_stand,tag=unbreakableglass] run summon minecraft:falling_block ~ ~ ~ {BlockState:{Name:"minecraft:glass"},NoGravity:true}
A few things: First, what's the use of the barrier in the player's head? wouldn't it just work if it was only the falling_block at the player's head position? that way it would prevent the suffocation problem. And Second, for whatever reason the NoGravity tag is a 'Byte' tag instead of a 'Boolean' tag, so instead of true/false, it accepts 1b/0b (technically a byte tag supports numbers -128 - 127 however only the numbers 1 & 0 are used here) so it would be: 'NoGravity:1b' instead of 'NoGravity:true'
A great thing about using tagged armorstands at the locations at custom blocks is that you can set their location to air and kill all of them to remove them quickly.
Indeed, this is a good way to quickly remove custom blocks
Giving an item frame the Invisibility:1b (I think) makes the item frame invisible, but not the item its holding.
Close, it's 'Invisible:1b' not 'Invisibility:1b'
Again, these are great tips, however, those are just a few problems I wanted to address.
In 1.16.5 (I don't know about other versions), when place a block "text" and "italic" in the name becomes "italic" and "text" when you break it.
This means that you can detect custom blocks with the name tag that were broken by a player in survival mode.
Item frames are automatically centered when summoned, this can be used in conjunction with tagged firework rockets to get centered marker armor stands easily for custom blocks.
A comparator coming out of an always active repeating command block leading to a block holding a redstone torch leading to an iron door that was placed open makes a door that will only open if certain conditions are met and can't be triggered with other types of redstone, like a button or lever.
If a non-opped creative player is trapped in barriers (and with their head in a barrier) and each barrier has a tagged marker armor stand at its location and every tick a falling glass block is summoned, then the creative player cannot leave the 'cage'. Note: If you want to trap a non-opped survival player give them resistance 10 and saturation forever so they don't die from suffocation.
execute as @e[type=minecraft:armor_stand,tag=unbreakableglass] at @s unless block ~ ~ ~ minecraft:barrier run kill @s
execute at @e[type=minecraft:armor_stand,tag=unbreakableglass] run summon minecraft:falling_block ~ ~ ~ {BlockState:{Name:"minecraft:glass"},NoGravity:true}
A great thing about using tagged armorstands at the locations at custom blocks is that you can set their location to air and kill all of them to remove them quickly.
Giving an item frame the Invisibility:1b (I think) makes the item frame invisible, but not the item its holding.
If you have any tricks you would like to add, please do
Great tips! I do have a few Questions, Nitpicks, and Corrections though, I'll do them in order:
That's cool, I didn't know that, however, block entities (blocks that can store data such as custom names) are very computationally taxing (cause a lot of lag) in large quantities, so to reduce that not all blocks can store data. Hence, not all blocks keep their name when placed and broken, so when using this you'd theoretically need to use a block entity (chest, furnace, banner, barrel, dispenser, beacon, etc.)
Although this is true what advantage does this have over 'execute align'? Whenever I need to summon something centered 'execute align' is usually my go-to.
Cool trick once again, however, one small nitpick with it is able to be met and un-met quickly then there's a chance that the user could abuse that to burn out the torch. one workaround if this is the case is having 2 command blocks, one the sets the redstone torch if the condition is not met, and one that removes the redstone torch if it is. That way you won't have any problems with burnout. However, if your condition cannot be met and un-met that quickly then this way will work perfectly
A few things: First, what's the use of the barrier in the player's head? wouldn't it just work if it was only the falling_block at the player's head position? that way it would prevent the suffocation problem. And Second, for whatever reason the NoGravity tag is a 'Byte' tag instead of a 'Boolean' tag, so instead of true/false, it accepts 1b/0b (technically a byte tag supports numbers -128 - 127 however only the numbers 1 & 0 are used here) so it would be: 'NoGravity:1b' instead of 'NoGravity:true'
Indeed, this is a good way to quickly remove custom blocks
Close, it's 'Invisible:1b' not 'Invisibility:1b'
Again, these are great tips, however, those are just a few problems I wanted to address.
Thanks for the corrections, I did not have Minecraft open at the time and was just writing from memory