Changes to the thread, primarily caused by 17w14a:
Shared data
Changes
1. The shared data "entity object" has a new condition: "distance", which checks how far away the advancement-earning player was from some origin (the origin changing depending on the trigger).
Additions
1. New shared "damage object" has been added, using data from the original "minecraft:player_damaged" trigger, albeit in a new format.
2. New shared "location object" has been added, using data copied from the "minecraft:location" trigger, and is also used with the new "minecraft:slept_in_bed" trigger.
3. New shared "damage flags object" has been added, being a set of flags concerning a damage source (originally used with the previous "player_damaged" trigger).
4. New shared "death object" has been added, containing an "entity object" with an additional "killing_blow" (damage object) condition.
Triggers
Changes
1. The "minecraft:player_damaged" trigger has been renamed to "minecraft:entity_hurt_player". This trigger as a whole has also been dramatically rewritten and now uses the shared "damage object".
2. The "minecraft:player_killed_entity" trigger now uses the shared "death object" instead of the "entity object".
3. The "minecraft:bred_animals" trigger has had its "parents" condition removed, replaced with "parent" and "partner" conditions (both being shared "entity objects").
4. The "minecraft:location" trigger now uses the shared "location object".
5. Old triggers "bred_animals", "player_killed_entity", and "summoned_entity" now include details about the origin for the new "distance" condition in the shared "entity object".
Additions
1. A new trigger "minecraft:player_hurt_entity" has been added, using the shared "damage object" and "entity object".
2. A new trigger "minecraft:entity_killed_player" (opposite of "minecraft:player_killed_entity") has been added, using the shared "death object".
3. A new trigger "minecraft:slept_in_bed" has been added, using the shared "location object".
4. A new trigger "minecraft:cured_zombie_villager" has been added, with conditions "zombie" and "villager" (both being entity objects).
5. A new trigger "minecraft:villager_trade" has been added, with conditions "villager" (entity object) and "item" (item object).
Display
Changes
1. This section as a whole has been rewritten to be more organized.
2. The "title" string can actually be a JSON object, so that section has been updated to include an example. This is not new to 17w14a.
3. The "frame" string now accepts a value of "goal".
Could you walk me through what I need to do once I have the JSON files to actually add the advancements to the game?
All advancement files for the world will be placed within the "/data/advancements" folder and they'll automatically be loaded in, but be aware that there is currently a bug with namespaces (MC-115064), which would require you to rewrite every reference to all advancements. Even further, this location may not be final, as a 'server pack' of sorts will be added to hold all server-relevant plugins.
For example, if you had the filepath /world/data/advancements/custom/test.json, you would currently reference it as "minecraft:custom/test" when using it as a parent or in the /advancement command. When the bug is fixed, you'd reference it as "custom:test" instead. Make sure to keep all letters lowercase to circumvent issues with differing file systems.
All advancement files for the world will be placed within the "/data/advancements" folder and they'll automatically be loaded in, but be aware that there is currently a bug with namespaces (MC-115064), which would require you to rewrite every reference to all advancements. Even further, this location may not be final, as a 'server pack' of sorts will be added to hold all server-relevant plugins.
For example, if you had the filepath /world/data/advancements/custom/test.json, you would currently reference it as "minecraft:custom/test" when using it as a parent or in the /advancement command. When the bug is fixed, you'd reference it as "custom:test" instead. Make sure to keep all letters lowercase to circumvent issues with differing file systems.
Thank you very much!
So if a modder wants to add some advancements as well as doing other things, he needs to distribute two different files? One for the advancements (or server pack, or whatever), and one for the mods folder?
Is it possible to replace or alter an existing vanilla advancement? If so, how?
So if a modder wants to add some advancements as well as doing other things, he needs to distribute two different files? One for the advancements (or server pack, or whatever), and one for the mods folder?
Is it possible to replace or alter an existing vanilla advancement? If so, how?
Modders only need to distribute 1 file, just like mojang's jar, the default recipes/advancements/loot tables will be in there.
I wonder what insane command creation Skylinerw could make if he put his mind to it. This is completly off topic but for real Skylinerw its as if mojang uploads all their information about commands and such directly to your brain.
I wonder what insane command creation Skylinerw could make if he put his mind to it. This is completly off topic but for real Skylinerw its as if mojang uploads all their information about commands and such directly to your brain.
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.
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.
I'm pretty sure you don't need these "pre" things =)
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):
[spoiler=Advancement(s)]
Paste advancement(s) here, along with filepath
[/spoiler]
[spoiler=Error]
Paste error & stacktrace here
[/spoiler]
I'll figure some solution out next time the thread needs a content update.
There were seemingly no changes in 17w16a. But there have been some changes for 17w16b:
Shared data
1. The "item" shared object now contains a "durability" range. 2. The "item" shared object accidentally had the "data" key written as being a range, when it's instead just a simple integer.
Triggers
Additions
1. A new "item_durability_changed" trigger has been added.
Changes
1. The "enchanted_item" trigger's "item" object now checks the item after it was enchanted, rather than before it was enchanted.
MC-116477 (""delta" option for "item_durability_changed" trigger inversely compares damage") has been closed as "Working as Intended". The thread has been updated to reflect that.
1. The "location" shared object now contains a "feature" string. 2. The "damage flags" shared object now contains a "source_entity" entity object. 3. The "damage flags" shared object now contains a "direct_entity" entity object.
Triggers
1. A new "levitation" trigger has been added.
Display
1. The "icon" is now an object rather than a string, currently containing an item ID and a new metadata value.
Rewards
2. The "commands" reward type was added, allowing commands to be run when an advancement is fulfilled.
There's also a new bug (MC-116671) but it's too minor to include in the main post. Once the pre-releases start, I'll finish the command info section, Q&A section, and will add a set of example advancements.
Can I ask if there's a way to remove the default advancements on a server?
Do I have to manually edit each advancement such that the trigger is impossible, or is there a better way to do it?
Currently it seems that you do have to replace every advancement. While you can replace just the root to hide all advancements from displaying in the "Advancements" menu, the popup notifications will still appear.
Changes to the thread, primarily caused by 17w14a:
Shared data
Changes
1. The shared data "entity object" has a new condition: "distance", which checks how far away the advancement-earning player was from some origin (the origin changing depending on the trigger).
Additions
1. New shared "damage object" has been added, using data from the original "minecraft:player_damaged" trigger, albeit in a new format.
2. New shared "location object" has been added, using data copied from the "minecraft:location" trigger, and is also used with the new "minecraft:slept_in_bed" trigger.
3. New shared "damage flags object" has been added, being a set of flags concerning a damage source (originally used with the previous "player_damaged" trigger).
4. New shared "death object" has been added, containing an "entity object" with an additional "killing_blow" (damage object) condition.
Triggers
Changes
1. The "minecraft:player_damaged" trigger has been renamed to "minecraft:entity_hurt_player". This trigger as a whole has also been dramatically rewritten and now uses the shared "damage object".
2. The "minecraft:player_killed_entity" trigger now uses the shared "death object" instead of the "entity object".
3. The "minecraft:bred_animals" trigger has had its "parents" condition removed, replaced with "parent" and "partner" conditions (both being shared "entity objects").
4. The "minecraft:location" trigger now uses the shared "location object".
5. Old triggers "bred_animals", "player_killed_entity", and "summoned_entity" now include details about the origin for the new "distance" condition in the shared "entity object".
Additions
1. A new trigger "minecraft:player_hurt_entity" has been added, using the shared "damage object" and "entity object".
2. A new trigger "minecraft:entity_killed_player" (opposite of "minecraft:player_killed_entity") has been added, using the shared "death object".
3. A new trigger "minecraft:slept_in_bed" has been added, using the shared "location object".
4. A new trigger "minecraft:cured_zombie_villager" has been added, with conditions "zombie" and "villager" (both being entity objects).
5. A new trigger "minecraft:villager_trade" has been added, with conditions "villager" (entity object) and "item" (item object).
Display
Changes
1. This section as a whole has been rewritten to be more organized.
2. The "title" string can actually be a JSON object, so that section has been updated to include an example. This is not new to 17w14a.
3. The "frame" string now accepts a value of "goal".
Bug fixes
The following bugs have been fixed:
- "loot" reward for advancements does not provide items
- All instances of entity-matching conditions do not function for advancements
A lot of stuff was changed up due to the expansion of the shared objects, so some examples might be wrong. Please let me know if you find any issues!
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
Could you walk me through what I need to do once I have the JSON files to actually add the advancements to the game?
All advancement files for the world will be placed within the "/data/advancements" folder and they'll automatically be loaded in, but be aware that there is currently a bug with namespaces (MC-115064), which would require you to rewrite every reference to all advancements. Even further, this location may not be final, as a 'server pack' of sorts will be added to hold all server-relevant plugins.
For example, if you had the filepath /world/data/advancements/custom/test.json, you would currently reference it as "minecraft:custom/test" when using it as a parent or in the /advancement command. When the bug is fixed, you'd reference it as "custom:test" instead. Make sure to keep all letters lowercase to circumvent issues with differing file systems.
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
Thank you very much!
So if a modder wants to add some advancements as well as doing other things, he needs to distribute two different files? One for the advancements (or server pack, or whatever), and one for the mods folder?
Is it possible to replace or alter an existing vanilla advancement? If so, how?
Modders only need to distribute 1 file, just like mojang's jar, the default recipes/advancements/loot tables will be in there.
Should be possible by using the same file path.
So YouTubers can make custom advancements and the viewers can easily copy and paste them for their Minecraft world?
YouTube https://www.youtube.com/channel/UC21Z2rupws5IulGQMxB1Plg
Why would youtubers make advancements for their viewers? But, yes, if they provide the files.
I wonder what insane command creation Skylinerw could make if he put his mind to it. This is completly off topic but for real Skylinerw its as if mojang uploads all their information about commands and such directly to your brain.
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.
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
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
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
I'm pretty sure you don't need these "pre" things =)
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.
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
Rough prismarine is actually an animated block, is slowly fades through each pase of the image.
Make a new texture containing only the prismarine part you want, in a resource pack snd reference that texture.
There were seemingly no changes in 17w16a. But there have been some changes for 17w16b:
Shared data
1. The "item" shared object now contains a "durability" range.
2. The "item" shared object accidentally had the "data" key written as being a range, when it's instead just a simple integer.
Triggers
Additions
1. A new "item_durability_changed" trigger has been added.
Changes
1. The "enchanted_item" trigger's "item" object now checks the item after it was enchanted, rather than before it was enchanted.
New bugs
The following notable reports have been added:
- "durability" option for item-based triggers succeeds for items without durability
- "delta" option for "item_durability_changed" trigger inversely compares damage
- "item_durability_changed" not triggered by armor durability loss
- "item_durability_changed" triggers when base change is 0, but not when Unbreaking modifies the change to 0
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
MC-116477 (""delta" option for "item_durability_changed" trigger inversely compares damage") has been closed as "Working as Intended". The thread has been updated to reflect that.
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
Changes to the thread caused by 17w17a:
Shared data
1. The "location" shared object now contains a "feature" string.
2. The "damage flags" shared object now contains a "source_entity" entity object.
3. The "damage flags" shared object now contains a "direct_entity" entity object.
Triggers
1. A new "levitation" trigger has been added.
Display
1. The "icon" is now an object rather than a string, currently containing an item ID and a new metadata value.
Rewards
2. The "commands" reward type was added, allowing commands to be run when an advancement is fulfilled.
Bugs
- Fixed: Unsuccessful advancement test command has player and advancement name interchanged
- Fixed: "durability" option for item-based triggers succeeds for items without durability
- CR: "item_durability_changed" not triggered by armor durability loss
- Fixed: "item_durability_changed" triggers when base change is 0, but not when Unbreaking modifies the change to 0
There's also a new bug (MC-116671) but it's too minor to include in the main post. Once the pre-releases start, I'll finish the command info section, Q&A section, and will add a set of example advancements.
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
Can I ask if there's a way to remove the default advancements on a server?
Do I have to manually edit each advancement such that the trigger is impossible, or is there a better way to do it?
Changes to the thread caused by 17w17b:
Shared data
1. The "location" shared object now contains a "dimension" string.
Triggers
1. A new "changed_dimension" trigger has been added.
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
Currently it seems that you do have to replace every advancement. While you can replace just the root to hide all advancements from displaying in the "Advancements" menu, the popup notifications will still appear.
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/