Avstar98
- Avstar98
- avstar98
- America/New_York
- Yes
- No
When the new saturation effect came out, I used command blocks to give me hunger points. It seemed like at amplifier 0 for 1 second I got 1 hunger point. When I put the same effect on a potion using NBT editors, even 1 second at amplifier 0 filled my entire hunger bar, when it should act the same as /effect. The issue is that when the command says the effect was applied for x seconds, it was actually applied for x ticks.
Saturation Potions don't work like /effect saturationcustom potions have consistent behavior for all effects, but the command does not
When signs with a clickEvent that runs a /give command is clicked, the item goes into the player's inventory, but does not show up until you reload the world.
To reproduce, type the following command into a command block, activate it, and then click the sign that appears. Reload the world to see the item it gives you.
Command:
setblock ~ ~1 ~ standing_sign 0 replace {Text1:"{text:\"text\",clickEvent:{action:run_command,value:\"give @p emerald 1\"}}"}
Upon further investigation, selecting the slot that the item should be in and pressing 'q' will drop the item. Once you pick it up (you may have to do this more than once) the problem won't occur the next time you hit the sign.
Unable to reproduce, assuming Avstar98's comment helped.
Make sure you're using
{Something:1b}
instead of
{Something:1}
to specify that the type you're looking for is byte.
If you are still having this issue, please open a new ticket and provide details about the issue you are experiencing using the Bug Report Guidelines Here.


Technically giants aren't undead, they just don't have their own texture, so they use the zombie's.
Items in the beacon are also lost upon closing a world and re-opening it.
I've seen redwood forests (Mega Taiga), though they are rare, much like how Ice Plains Spikes are rare. Biome frequency will probably be adjusted, but for now they will stay rare and you can probably find seeds that will put you near them.
Sand entities require a Time value greater than 0, otherwise they will despawn. To get a falling sand entity to fall properly, the command should look like this:
/summon FallingSand x y z {Time:1,...}You can avoid this by adding DropItem:0 into the data brackets, though I agree it should obey the gamerule.
I can confirm this, though I can't actually type in that command as it goes over the command character limit.
This is not a bug, I realize now that the item requires a "count" tag.
I've attached the world file if you want to take a look. The comparator does not output when the command is run, but there is no reason that it shouldn't. It is a /testfor @p command, which should always be true.
It seems to work now that I've broken and replaced the comparator. Maybe it is a comparator bug rather than a command block bug.
I can confirm this. I was also over a void, making a map and when I made it, the game crashed. The strange part was that the void I was over wasn't completely empty, I had placed a block in it.
Also affects 1.7.3 Prerelease.
The third set of coordinates that you clone to will be the position of the northwest corner of the selection, not the center. This is why it moves in the z direction.
Technically the blocks are removed, they just leave a "ghost block" behind. Right clicking the blocks will cause them to disappear, and if you attempt to clone the ghost blocks, it will instead clone the air block that should be there.
Tags require you to specify the type of tag they are when using /testfor. For example, the Sleeping tag is a byte, so to testfor someone sleeping you would use
{Sleeping:1b}
{Sleeping:1}Just writing
defaults to a string tag, which doesn't exist.
Does this affect all 64x resource packs? If it doesn't it's likely just a problem with the pack.
It's shaky because the slime blocks make you bounce. Since you didn't fall from a large height, the bounce is very small.
This does not actually work as intended. The /worldborder max is 30 mil in length, meaning you can only go to 15 mil, 15 mil, much smaller than the actual world.
MC-53390describes the problem better.This works as intended. The redstone that is attached to the command block on the right is not ever at signal strength 0, but rather is switching between 1 and 14, which is intended behavior. Therefore the command will only be powered once. You can see this for yourself by pressing F3 and looking at the blockStates on the right side of the screen.
Edited for typo.
I was unable to reproduce this issue, so there must be more to it. Regardless, you can likely fix it by adding a c=10 argument to the selector.
execute @e[name=FlameBringer,c=10] ~ ~ ~ setblock ~ ~ ~ minecraft:fire 0 keep
This will ensure that 10 entities named FlameBringer execute the command.
Were you on singleplayer? Spectators will not keep entities loaded, so going into spectator mode with no other players around causes every hostile/neutral/unnamed mob to despawn, except for Elder Guardians, who do not despawn.
Your command is incorrect. You need the full item name in quotes:
FVBico, your command doesn't work either. The 'minecraft:' isn't required in give commands, but when using testfor, the json must match the entity's NBT data exactly.
This can happen to all entities.
I get this as well in my creative world. It doesn't happen with just bedrock, but rather to any block directly above the void.
Actually, it's the Oak Door that has its handle on the wrong side. Unless of course you're placing it next to another Oak Door.
An entity can have rotation and motion tags without having an AI.
This is intended. For the time being, names can only be used in commands, and are just an alias for the effect numbers.
Any block above a zombie, transparent or not, will prevent a zombie from burning. This is intended behavior.
Are you sure you didn't open your world in 1.7? Downgrading to 1.7 will delete all items in inventories due to a change in how item IDs work.
The beacon beam bug is a duplicate of
MC-68247. As for the fireworks, you're using blank maps instead of paper.I'm not sure if I'm experiencing a different bug or this bug is just more extensive than reported, but in 1.8.1-pre2, the command
returns the error:
while the command
works fine.