Quote from TheMinecraftNerd1»
So it seems that mojang tweaked the Chain Command Blocks and how NBT parsing works. Will this affect any or break current maps using NBT or Chain Command Blocks when the update is released?
For the command block change, it should ideally not break much. It reorders how command blocks are scheduled, fixing an issue where a chain shut off via a Chain block will still fire the next tick (more details here). What might break are any in-game attempts to circumvent that issue, though that depends on the method being used I suppose.
As for NBT changes, if you used quotes for all your strings and did not use list indices, you're good to go. There are a number of changes that were made to the parser though (as it was essentially completely rewritten), so I've got a more detailed post here.
0
/clear's syntax:
/clear [target] [item] [Damage] [max amount] {NBT}The NBT data starts within the "tag" tag of the item format. If you are unfamiliar with the item format, see here. The "Damage" tag is not in the "tag" tag, and is instead defined by the /clear command's syntax:
/clear @p minecraft:diamond_pickaxe 0 1 {display:{Lore:["Made Of Adamantite"]}}0
Resource packs are for clients and cannot change server information. Custom recipes would normally be placed with other world-specific data like loot tables and advancements.
However, currently we cannot add custom recipes without modding the jar, but it will eventually be possible.
0
When testing for pre-existing data, you'll need to specify that data as it's saved. The "Damage" tag is saved as a short, so you append the numerical value with an "s":
/scoreboard players tag @e[type=item,tag=!orange] add orange {Item:{id:minecraft:stained_hardened_clay,Damage:1s}}0
Unfortunately the forum will not let me format that the way it needs to be. It'll either show "pre" or it'll show "p" depending on if the "pre" is there. I'm not sure why either because it doesn't happen outside the first post, e.g. using "pre" (copy/pasted directly from the original post's bbcode):
I'll figure some solution out next time the thread needs a content update.
0
Changes to the thread, primarily caused by 17w15a:
Index
Reordered slightly to separate data structures from intro.
Errors
Completely new section to describe locating error logs and asking for assistance.
Shared data
Changes
1. The shared data "location object" accidentally had a full "minecraft:location" advancement as an example instead of a generic object example for the biome.
File editing
Completely new section to describe file editing for advancements.
Display
Additions
1. A new "description" tag has been added. Section intro changed slightly to indicate that a description is required.
Parent (now "Tree display")
This section has been rewritten to accommodate the new "File editing" section and the fix of MC-115064.
External links
A link to a Chinese translation has been added
Bug fixes
The following bugs have been fixed:
- Custom advancements in world folder use the "minecraft" namespace instead of folder name
- F3 + T does not reload advancements but does reload loot tables
0
Changes in 17w15a:
Tile Entity: minecraft:bed
Beds are now tile entities, where each part (head and foot) has its own color.
"color" (integer)
The standard wool color of the bed, values 0 to 15.
/setblock ~ ~1 ~ minecraft:bed default replace {color:15}0
There's a "food" objective-type you can use in order to run /effect commands on players only when relevant.
Prerequisites:
Objective to track hunger.
Clock commands:
The following must be run in numerical order on a Repeating clock.
1. Give players the Hunger effect if their hunger is higher than 6.
2. Give players the Saturation effect if their hunger is lower than 6 (causing hunger of 6 to be the equilibrium).
The "food" objective-type will start players out with no score, so they can't be immediately detected. Unfortunately it's also read-only, so you can't force it to change using /scoreboard. Logging in will cause players to have a score though so you wouldn't have to worry about it for newcomers, but for your own testing you can just relog.
0
You are missing a comma between the closing square branch for "ench" and the "RepairCost" tag. As well, you must specify the namespace for an item ID when testing for it, as that's how it's saved (defaulting to "minecraft"):
testfor @e[type=item] {Item:{id:"minecraft:slime_ball",Count:1b,tag:{ench:[{lvl:3s,id:34s}],RepairCost:1,display:{Name:"Aurum Key"}}}}1
Hehe, I suppose to make it on-topic, I could list out things off the top of my head that we can do now with commands, using the current triggers for advancements:
1. Obviously we now have control over adding our own, custom achievements.
2. "bred_animals": We can now detect specifically who bred a pair of animals. While we could detect the animals having mated, we could only guess as to who caused them to breed.
3. "construct_beacon": Not too special, but we can detect if the player is within range of any beacon (even those without a pyramid) without using block-testing commands. Could hide a stray beacon in certain spots and detect if the player was near them as an alternative to marker entities. No good control over the range though, and can't run commands off the beacon either like you can with regular entities.
4. "enchanted_item": While we had a "stat.itemEnchanted" objective that incremented when the player enchanted any item, we couldn't feasibly determine what item was enchanted, nor could we check how many levels were spent on it. It's a bit specific of a function, so general usage is minimal. Currently it can only check data on the item before enchanting, so hopefully it's extended so we can detect the new item (so we can then check enchantments).
5. "entity_killed_player/player_killed_entity": While we already had statistics for detecting what killed the player or what the player killed ("stat.killedByEntity.", "stat.entityKilledBy."), there were some we couldn't check with it (I believe the wither was one of them). We can also check data for that entity, including distance.
6. "inventory_changed": Powerful inventory slot detection. Prior to this we'd have to check each slot individually for being occupied or empty, and was not feasible to check if that slot was full due to varying stack sizes. This advancement easily helps with "burden" mechanisms for full inventories.
7. "location": Coordinate detection is nothing new, but the biome detection is a new and long-requested feature. Unfortunately this is only for players, not any entity, so it's limited.
8. "entity_hurt_player/player_hurt_entity": Very powerful damage detection for damage the player takes or deals. Previously we could only detect just the amount of damage the player takes, not the entity that dealt it nor any metadata about that damage. I imagine this one will be the most used out of all the triggers.
9. "summoned_entity": I'm pretty sure we couldn't accurately detect who constructed a snow/iron golem, so this is just an extra amount of detection. Not that useful though, so probably not going to be used often.
10. "villager_trade": While we could detect when the player traded with a villager already ("stat.tradedWithVillager"), we couldn't determine what the player has purchased. We can also check entity data of the villager that was traded with, so if that entity data gets extended to detect more things in the future, we can potentially determine exactly which villager the player traded with.
Advancements aren't finished yet either, so I suspect we'll see more useful features as 1.12 is developed.
0
/testfor is useful when mixed with CommandStats, such that a score is set based on the number of targets obtained by a selector. Of course, that function can be copied by moving that selector into a /execute command, which in turn runs a /scoreboard command to add to a score.
Another use that it works well for is when you want to check for a specific number of targets without having to use the scoreboard. For instance, the following will set the command block's "SuccessCount" tag to 0 if no players are found, 1 if only 1 player is found, or 2 or 2 or more players are found:
And you'd use /testforblock to check that value. For example, if you wanted to ensure there were at least 2 players online, you'd check a SuccessCount of 2 (which represents 2 or more):
/testforblock X Y Z minecraft:repeating_command_block * {SuccessCount:2}It can sometimes be useful when you want to only run a performance-heavy clock if relevant targets are in existence (since you don't want to have clocks running when they're not needed). You'd have a clock on and running the /testfor command, which will turn on another larger clock if /testfor was successful. However, that /testfor command could usually be replaced with one of the commands in the secondary clock that would target the relevant players, since it would also serve as a test. For secondary clocks that can't move a whole command into a primary testing clock, then /testfor would be useful.
But most of the time, it is quite useless.
0
Your original command is testing if the boots have Sharpness 1, which they don't. You'd need to adjust the command to look for the tags with the values they have, including datatype declaration (as most tags are not auto-corrected for item data). Example:
/scoreboard players tag @a add LevitationBoots {Inventory:[{Slot:100b,tag:{ench:[{id:34,lvl:5}]}}]}0
Yea, that would be the issue. Unfortunately I don't know anything about Spigot permission settings; I would recommend asking about that in Server Support: http://www.minecraftforum.net/forums/support/server-support
0
Are you using vanilla? Checking in 17w14a, being in survival and not OP'd still allows the "BlockEntityTag" tag to function (for some blocks that tag is ignored, can't remember which though).
0
Can you provide the command you're using to provide the boots?
1
There's essentially no performance impact, it's more about being consistent with the concept. The vanilla recipes have some that have a single item in the recipe using shaped crafting, and others that do use shapeless as expected. Just be aware that the files are in their very early stages, and it could have been that shaped crafting was implemented before shapeless (and that the format could be completely different by the end of it all).