WolfieMario

Confirmed for 1.8-pre3.

Confirmed in 1.8-pre3.

This is a piece of lore text. Instead of adding HideFlags, remove the Lore. The lore is already customizable on its own.

Using "/scoreboard players add <target> <objective> 0" will place the targets on the scoreboard with a default score of 0, while having no effect on targets who already have a nonzero score. Either use it on all players/entities when they initially spawn or enter a relevant area, or use it on them just before you intend to check their scores.

EDIT: For clarification, this is not a way to detect untracked entities, but rather, a way to render them trackable. That's a useful workaround for any score where 0 is your desired default value, as it was in previous versions.

If you actually want to detect untracked entities without giving them a score, create a separate "tracked" objective. Use "/scoreboard players add <target> tracked 1", where <target> includes the arguments "score_name_min=-2147483648,score_name=2147483647" (where "name" is the objective). Also use "/scoreboard players add <target> tracked 0", this time without the score arguments. Untracked players/entities in the objective "name" will have a tracked score of 0, while tracked players/entities will have a tracked score of at least 1.

Confirmed in 1.8-pre2

Possibly Working as Intended. You can replace individual slots with /replaceitem. The current /blockdata behavior makes it possible to reset the contents of a chest, by adding and removing items. Changing this would make it impossible to wipe a chest with /blockdata, and you would need to use a separate command to first destroy the chest (/blockdata was most likely added to prevent the need for that, in the first place).

The current behavior of /blockdata and /entitydata are to merge changes to compounds (the curly-brace groups), but completely overwrite lists (the square-bracket groups). It's possible to "overwrite" a compound by replacing every tag with the desired value. If lists were not overwritten by default, you would either have to explicitly label indices (which is currently optional), or unlabeled indices would have to be appended to the end of the list. This would still make it impossible to remove elements from a list, however.

Confirmed in 1.8-pre1.

Louis, that does not work on affected versions.

The ShowParticles tag goes inside the potion effect compound, like this:

/summon Bat ~ ~1 ~ {Invulnerable:1,PersistenceRequired:1,NoAI:1,Silent:1,ActiveEffects:[{Id:11,Amplifier:100,Duration:1999980,ShowParticles:0},{Id:14,Amplifier:1,Duration:1999980,ShowParticles:0}]}

Horses do not teleport to the player, but rabbits do. Leads are not completely reliable; they frequently snap when the rabbits try to get away. Horses can be penned in without leads, but rabbits cannot.

Either rabbits should not teleport to the player, or they should be able to sit to reliably disable teleportation.

Prior to 1.8, CustomNameVisible did work on animals and mobs. I'm just curious why it doesn't anymore.

Daylight detectors in darkness (no access to skylight) still appear buggy. When not inverted, they produce power for a few minutes as the moon is coming up. When inverted, they produce power almost always, except when the sun is coming up. When exposed to the sky, they appear to behave correctly in either state.

Fixed: skull items and blocks now store Name, (UU)Id, and texture Signature and Value tags (encoding a URL directly to the texture file on the skin servers). This means skulls shouldn't change appearance when a player changes their skin anymore. I also think the Name tag solves the issue FVbico mentioned, but I haven't tested that yet. They also correctly update to these tags even when /given or /setblocked with the old (name-only) tag.

I'm sorry I didn't check this sooner; I think it has used this new format for a very long time now (without the Name tag, however). It just didn't when I first posted this ticket.

Confirmed for 14w30b.

This is not a duplicate of MC-62504. MC-62504 was fixed in 14w30a, while this was not fixed. MC-62504's fix only applies to Damage Taken, not death screen Score.

Confirmed for 14w30a.

See MC-61577: "CommandStats are not used when a command sign is right-clicked by non-OPs". Searge fixed this, making it fairly clear that non-OPs are intended to be able to run OP commands through signs, as much as they can run them through command blocks.

Look at it from a different angle: when a book/chat tellraw is clicked, the player executes the command. When a sign is right-clicked, the sign executes all top-level commands present in its JSON. This is very different from standard tellraw behavior, and more in-line with command block behavior:

• The command's user is not the player who right-clicked it. This makes commands like /kill and /tp fail unless you give the player as an argument or proxy them via /execute.

• Signs are able to execute commands up to as long as a command block's length limit. Books and tellraw are limited to the longest command a player can type, which is much smaller.

• Signs do not need to prefix commands with a / slash, again similar to command blocks.

• The coordinates of the sign are used, rather than the player's coordinates. This is very useful for signs which modify blocks or spawn structures. Once again, you can proxy by /execute if you really need to use the player's coordinates instead.

• The sign's own CommandStats are used to store the command's results, rather than the player's CommandStats. This is the entire reason signs support the CommandStats tag.

• A sign does not check which letter is clicked on. All top-level commands (a maximum of four) are executed, and nested commands are ignored. This works even if the sign is right-clicked on a part which does not contain text, such as the post or the backside.

• A sign cannot be activated inside a spawn-protected area, as your ticket indicates. Last I checked, this behavior is consistent with the fact that doors cannot be opened and buttons cannot activate redstone (or by extension, command blocks) in spawn-protected areas.

It's easier to not think of signs the same way as books and tellraw, and helpful to think of them like command blocks. The syntax similarity is misleading if you're used to tellraw, but signs work very differently, and are intended to do so because it makes them much more useful. And it couldn't have been an accident; signs actually have a dedicated CommandExecutor class in the code.

It makes no sense to only check commands that are inside signs when the activating player is also inside spawn protection.

That's because this isn't what the game does. It checks that the sign (not the player) is inside spawn protection, and does not check what commands the sign has. The game will even block a player from running a "/me says Hello" sign, despite /tellraw and JSON books permitting non-OP players to use the /me command.

players creating these signs shouldn't leave them out and about but it happens and, sometimes, it's easier to do just that.

The same applies to leaving command blocks lying around. You really shouldn't do it, because ordinary players can activate them. There are also perfectly legitimate reasons to let ordinary players activate signs: I've seen a Reddit post where it was used in a portable shop system, and I'm personally working on a magic system which uses them. I don't think misleading syntax is a reason to remove existing and intended features.

Confirmed for 14w29b.

Searge, what rules are used for animals and mobs?

Previously, CustomNameVisible=false would hide the name tag unless the player looks at the entity, while CustomNameVisible=true would show it at all times. Now, it has no effect: it always shows if looking at the entity, and never shows otherwise. Non-players can't be added to teams, so I can't imagine what other rules would apply to them.

If no players exist on team fire with at least a score of 5 in fk, the game will output "The entity UUID provided is in an invalid format". This seems like just the wrong error message; if at least one player has at least a score of 5 and is on team fire, it will successfully find them.

The actual bug here is that the game gives an improper error message for some combinations of failing selector arguments.

"Mob" applies to any living entity; it comes from "mobile object" and not "monster". Server.properties distinguishes Monsters, Animals, and NPCs (villagers), while "Mob" applies to all three categories. Setting doMobSpawning to false has prevented monsters and animals from spawning in versions prior to 14w21b, as it should.

All that being said, doMobSpawning only controls natural spawn events. It doesn't control mobs spawned by players, commands, breeding, or terrain generation. Villagers only spawn (without player interaction) from breeding and terrain generation; the latter must be where your villagers came from (in other words, a new village generated somewhere in the distance - terrain generates quite far from you).