I mean the tag directly. There are two functions used for NBT data on an entity: reading and writing. The "Team" tag is only referenced when reading, so while we can do this (the game reads the NBT data we've provided, which includes "Team"):

/summon Creeper ~ ~1 ~ {Team:"TeamName"}

We cannot do this (the game does not write the "Team" tag back onto the entity):

/testfor @e[type=Creeper] {Team:"TeamName"}

They will still belong to the team of course, and team parameters will work:

I mean the tag directly. There are two functions used for NBT data on an entity: reading and writing. The "Team" tag is only referenced when reading, so while we can do this (the game reads the NBT data we've provided, which includes "Team"):

/summon Creeper ~ ~1 ~ {Team:"TeamName"}

We cannot do this (the game does not write the "Team" tag back onto the entity):

/testfor @e[type=Creeper] {Team:"TeamName"}

They will still belong to the team of course, and team parameters will work:

/say @e[type=Creeper,team=TeamName]

EDIT: Added "conditional" to command blocks from the 15w34b snapshot.

Oh ok thanks

Rollback Post to RevisionRollBack

Check out innovative redstone and command block concepts with The Redstone Scientist!

1. "VillagerProfession" (byte) for zombie villagers, used to determine what profession the zombie is represented as, as well as what profession it will become when cured (EDIT: as of writing this they don't become that profession when cured, but that's very likely a bug considering the existence of this tag in the first place).
2. "auto" (byte) for all command blocks, allowing them to activate their commands without the requirement of a redstone signal.
3. "Slot" (string) for attribute modifiers, allowing us to specify what slot the modifier is used for.

One tag removed:

1. "conditional" for all command blocks. Instead, blockstates are used to determine if it's conditional. /setblock or /fill will be needed, using Damage values.

1.9 will bring a lot of flexibility to command blocks, do you know if they cause more lag than "normal" clocks, they don't update chunks do they? Also, is it weird that I'm lagging a ton in the snapshots?

1.9 will bring a lot of flexibility to command blocks, do you know if they cause more lag than "normal" clocks, they don't update chunks do they? Also, is it weird that I'm lagging a ton in the snapshots?

The new Repeat blocks do not update chunks. They're much more efficient on lag as a result compared using clocks that place blocks. From 1.9 and onward, Repeat blocks should be used for clocks instead of the /fill or /setblock clocks.

I do have some lag in general for the snapshots, but that's just because they're not optimized. Optimization usually happens towards the end of the snapshots.

Alright, thanks! They did some changes in general which will boost performance, just hope that it'll include my computer's too. I really like what they did with the new tags for the command blocks, this is basically what they want us to start using. Hopefully it'll be less lag once they start reaching the end of the snapshots, I wonder when that is...Anyway thanks for your answers.

Added "conditionaMet" byte tag to command blocks. If the command block behind the conditional block was successful, this value is set to 1. Otherwise, it's set to 0. Always 1 for non-conditional blocks.

Just one new tag in 15w37a: "Enabled" byte tag for MinecartHopper entities. When set to 0, the minecart hopper will not pick up items into its inventory. It will still transfer items out of its inventory. When 1, it will pick up items normally. Note that it's only for the minecart variant, not the block.

Wow I just realized I have a lot of work to do in updating my new map to 1.9...... Why did I have to make a map with well over 10'000 command blocks... I was having red stone freezing issues and now with the new command blocks I can alleviate that but wow the strict JSON now is a big change as well.. Now if only They would fix the bug that prevents custom names from showing up on Wither and Ender dragon boss bars I will be in business.. One step at a time I suppose..

The new Repeat blocks do not update chunks. They're much more efficient on lag as a result compared using clocks that place blocks. From 1.9 and onward, Repeat blocks should be used for clocks instead of the /fill or /setblock clocks.

I do have some lag in general for the snapshots, but that's just because they're not optimized. Optimization usually happens towards the end of the snapshots.

But there is the possibility that they CAN break on servers when chunks unload or if the server crashes.

But there is the possibility that they CAN break on servers when chunks unload or if the server crashes.

Can you elaborate with reproduction steps or provide a world download where that occurs? 1.9 command blocks do not suffer from 1.8's unloading issues from what I've observed (even less so because Mojang has taken steps to ensure unloading chunks will not cause issues for numerous tiles/entities, as seen by the "powered" tag for command blocks and noteblocks and "Enabled" for hopper minecarts).

I just set a command block in repeat mode with the command /say hi. I unloaded the chunk, and the messages stopped coming. I went back to the chunk, and the messages did not start going again untill I powered it.

Basically the same issue that seems to happen with /setblock and /fill clocks.