The Meaning of Life, the Universe, and Everything.
This is something I know pretty much all command blockers want - even counting only Minecon panels, SethBling mentioned it, Sarc mentioned it, Dragnoz menationed it and Sparks mentioned it... it is the ability to read and change NBT data.
Now the problem with that is that at first glance it seems like this undefined fairy wish - big and difficult to implement. I've never seen anyone suggest the actual specifics of how it could be done. It's always this fuzzy thing of "wouldn't it be nice if we had some way of reading any data field".
Now I've come up with a design for these commands that I believe is reasonably simple to implement, that fits nicely with the commands that we already have but also at the same time provides a maximum amount of expressive power for command block inventions and map making.
So I present to you, /scoreboard players read and /scoreboard players write.
If you want a demonstration of how it could work (and also a spoken form of the rest of this text), see this demo video:
The purpose is simple - one is for reading a value from an arbitrary NBT field into a scoreboard, and one is for taking a scoreboard value and writing it as the new value of an arbitrary NBT field.
@p is the entity in question, HeldColor is the scoreboard objective we want to update... Now comes the interesting bits - the field address is the JSON path to the data field we want to read - here we're reading the color value inside the item held in the player's hand. So if you are holding a dyed leather helmet, for instance, we can read that color value directly into a scoreboard.
The scale at the end is set to one here - we'll get back to the point of that later.
Now the JSON path used for the NBT field address is the interesting part here - it's a pretty natural syntax to anyone who has worked with NBT or JSON before, yet powerful enough to allow access to almost any field in Minecraft - something that would move command blocking ahead by a great leap, opening up for a variety of new ways of making inventions.
And we're only halfway there... the other command is just as important.
Exactly the same syntax, exactly the opposite functionality. Take a scoreboard value, write it into an NBT field addressed by a JSON path.
We're talking about a command here that could have removed over one hundred thousand command blocks from the Predator1 invention I made, and that's only the start. There are so many inventions I come up with that snag because you'd need to be able to read and write values - these commands provide an easy yet implementable way of doing just that.
So what about values that are not integers? Things like Health, which now in Minecraft 1.9 can't be tested for properly on mobs because it's a floating-point value now, not an integer? That's where the scale factor comes in.
When reading NBT values, the scale factor is used to multiply the value before saving it to the scoreboard objective.
This means that if I'm interested in a player's movement speed, I could use a factor of 10 to be able to detect movement speeds of one tenth block per second. This would look like
/scoreboard players read @p XSpeed Motion 10
When writing values, the scale factor is used to divide the value, scaling it back to the same magnitude it was when read.
I believe these two commands would give command blockers almost all they've been asking for and still be reasonably easy to implement with well-known components like JSON paths that both already have existing implementations and come naturally to users.
1 The Predator... couldn't figure out how to link it without getting the entire media display, sorry: