• 0

    posted a message on generic.flyingSpeed?

    It is indeed only applicable to parrots. It acts as a modifier, but seemingly only for horizontal flight speed. For example, the following would prevent them from flying horizontally:

    /summon minecraft:parrot ~ ~1 ~ {Attributes:[{Name:"generic.flyingSpeed",Base:0.0}]}


    And the following has them fly double the normal speed (0.4000000059604645):

    /summon parrot ~ ~1 ~ {Attributes:[{Name:"generic.flyingSpeed",Base:0.8}]}


    Although I can't seem to get them moving at insane speeds like you could with "generic.movementSpeed", so I'm assuming there's a limiter presented by the flight AI.

    Posted in: Commands, Command Blocks and Functions
  • 0

    posted a message on Can you make infinite potion with command blocks
    Quote from NutPotato»

    I saw the question and I did the "increase number by one" method of finding out the exact answer. As of 1.12 version of Minecraft, the number that will start to display **:** is 1639 so an example would be:


    If you don't want the particles to show, just add "{ShowParticles:0b}" to the end so it would be:


    Please remember that this is in 1.12, I'm not sure if it's different in past versions. Have fun with knowledge!





    You cannot make a potion effect last infinitely. The duration showing "**:**" simply means the value is too large to convert, as it converts into the "short" type (32,767 maximum, in which 9,999 seconds is 199,980 ticks). The highest you can go with the /effect command is 1,000,000 seconds (20,000,000 ticks):
    /effect <player|entity> <effect> 1000000 <amplifier>


    The highest an effect can go NBT-wise is 2,147,483,647 ticks, roughly 3.4 years. For 'infinite', you would have to apply the potion effect nonstop on a clock.
    Posted in: Commands, Command Blocks and Functions
  • 0

    posted a message on How to assign a player the first unassigned scoreboard value?
    Quote from boxopen»


    Thank you for the help! This is scoreboard stuff way over my head, but I have one question. How would I reset this "fake player" back to 0. As I left the first command running on a clock for a few seconds by mistake, and now every new player starts with an ID in the 600's.



    You can run the following command to set the fake player's score to a specific value (example being 0):

    /scoreboard players set #current ID 0


    However, you'll run into an issue as players were already given the "processed" tag, so you may need to manually fix their scores for whoever it affected (and then adjusting the "#current" score based on the last ID manually set).

    Posted in: Redstone Discussion and Mechanisms
  • 0

    posted a message on Custom Loot Tables (for PE/Win10)
    Quote from Tryashtar»


    I'm rather inexperienced with loot tables. Is this an example of something that Java's loot tables cannot do?



    That's correct, loot tables in Java cannot do this. I'm not sure you could easily replicate it either; that is, have a set of items that always accompanies another set of items. Not without some external force like the "entity_scores" condition, which I just realized is not present in PE/Win10 and have now fixed the thread to include that difference.

    Posted in: MCPE: Map Help & Requests
  • 1

    posted a message on How to assign a player the first unassigned scoreboard value?

    You can cause each new player to increment a fake player's score, and then give that new player the same score:

    Prerequisites

    Objective to track unique IDs:

    /scoreboard objectives add ID dummy


    Clock commands

    The following must be run in numerical order on a clock:

    1. Cause new players to increment a fake player's score by 1. That fake player will always hold the latest ID. The ID will be 1 for the very first new player, then 2 for the next new player, and so on.

    /execute @a[tag=!processed,c=1] ~ ~ ~ scoreboard players add #current ID 1


    2. Set that new player's score equal to the fake player's new score.

    /scoreboard players operation @a[tag=!processed,c=1] ID = #current ID


    3. Then add the "processed" tag to the player so that they will not be considered new anymore.

    /scoreboard players tag @a[tag=!processed,c=1] add processed


    This will support multiple new players joining the game at the exact same time.

    Posted in: Redstone Discussion and Mechanisms
  • 1

    posted a message on Custom Loot Tables (for PE/Win10)

    Index


    Generic info

    1. Intro
    2. Editing

    Pools

    3. Tiers


    Entries

    4. Nested pools


    Functions

    5. minecraft:enchant_book_for_trading
    6. minecraft:enchant_random_gear
    7. minecraft:enchant_randomly
    8. minecraft:exploration_map
    9. minecraft:looting_enchant
    10. minecraft:random_aux_value
    11. minecraft:set_data_from_color_index
    12. minecraft:set_nbt
    13. minecraft:set_attributes

    Conditions

    14. minecraft:killed_by_player
    15. minecraft:random_difficulty_chance
    16. minecraft:random_regional_difficulty_chance
    17. minecraft:entity_scores

    Conclusion

    18. External links
    19. Conclusion



    Generic info



    Intro




    Loot tables are a data-driven method of defining a set of items to provide to relevant context, such as mob loot or mob equipment.

    This guide for the Bedrock codebase (includes Pocket Edition & Windows 10 Edition) is an extension of my Java Edition guide. Many details are the same, so this guide will instead cover the differences between versions. Please view the other guide for more extensive details.

    Editing




    Please view the Creating Behavior Packs wiki page for details on setting up behavior packs, as well as recommended programs for editing.



    Pools



    Tiers




    Tiers are an alternative method of selecting entries as compared to basic rolls. Rather than a random entry being selected from within the list, each entry is a tier, with the tier increasing for each entry specified. The entry to select is dependent on tier options provided. The following table indicates that "stone" is tier 1, "sand" is tier 2, and "grass" is tier 3.

    {
        "pools": [
            {
                "tiers": {
                    
                },
                "entries": [
                    {
                        "type": "item",
                        "name": "minecraft:stone"
                    },
                    {
                        "type": "item",
                        "name": "minecraft:sand"
                    },
                    {
                        "type": "item",
                        "name": "minecraft:grass"
                    }
                ]
            }
        ]
    }

    Without using tiers, the specified order is irrelevant and a random entry is selected as usual.

    When the "tiers" object is specified, the "rolls" option for pools is ignored, rendering "weight" and "quality" for entries useless. For example, given the following table, rolls, weight, and qualities should be removed because tiers have been specified:


    {
        "pools": [
            {
                "tiers": {
                    
                },
                "rolls": 1
                "entries": [
                    {
                        "type": "item",
                        "name": "minecraft:lever",
                        "weight": 1,
                        "quality": 1
                    },
                    {
                        "type": "item",
                        "name": "minecraft:stone_button",
                        "weight": 1,
                        "quality": 1
                    },
                    {
                        "type": "item",
                        "name": "minecraft:stone",
                        "weight": 1,
                        "quality": 1
                    },
                    {
                        "type": "item",
                        "name": "minecraft:sand",
                        "weight": 1,
                        "quality": 1
                    }
                ]
            }
        ]
    }


    Initial range

    An initial range of tiers can be defined as the starting position, intended to be mixed with bonus rolls, specified in the "initial_range" integer (must be 1 or higher). The value of the initial range will correspond to the highest tier that you want to have selected by default, regardless of bonus rolls. For example, given the following table:

    {
        "pools": [
            {
                "tiers": {
                    "initial_range": 2
                },
                "entries": [
                    {
                        "type": "item",
                        "name": "minecraft:stone"
                    },
                    {
                        "type": "item",
                        "name": "minecraft:sand"
                    },
                    {
                        "type": "item",
                        "name": "minecraft:grass"
                    }
                ]
            }
        ]
    }

    "stone" is tier 1, "sand" is tier 2, and "grass" is tier 3. The initial range's value is 2, meaning all tiers between 1 and 2 ("stone" and "sand") will be selected by default. At that point, all of those selected tiers will have an equal chance of being selected. The basic formula for determining the chance of a tier within the range being selected would be:

    chance = 1 / initial_range


    As there are two tiers being selected, each has a 50% chance of being selected, while "grass" has a 0% chance due to having a tier too high for the initial range.

    Bonus rolls & bonus chance

    When bonus rolls are specified, the tier selected from the initial range will increase depending on the values of "bonus_rolls" (the number of times to try moving up a tier, must be 1 or higher) and "bonus_chance" (the percent chance between 0.0 and 1.0 that a single bonus roll succeeds in moving up a tier). Given the following table:

    {
        "pools": [
            {
                "tiers": {
                    "initial_range": 1,
                    "bonus_rolls": 1,
                    "bonus_chance": 1.0
                },
                "entries": [
                    {
                        "type": "item",
                        "name": "minecraft:stone"
                    },
                    {
                        "type": "item",
                        "name": "minecraft:sand"
                    },
                    {
                        "type": "item",
                        "name": "minecraft:grass"
                    }
                ]
            }
        ]
    }

    "stone" will always be the initial tier selected due to "initial_range" being 1. However, there is a 100% chance (via "bonus_chance") of increasing the tier by 1 per bonus roll. In this case, the selected entry will always be "sand" because it is the next tier up. If "bonus_rolls" were 2, then "grass" will always be selected due to it being a 100% per bonus roll to move up 1 tier.

    As another example, given the following table:

    {
        "pools": [
            {
                "tiers": {
                    "initial_range": 1,
                    "bonus_rolls": 2,
                    "bonus_chance": 0.5
                },
                "entries": [
                    {
                        "type": "item",
                        "name": "minecraft:stone"
                    },
                    {
                        "type": "item",
                        "name": "minecraft:sand"
                    },
                    {
                        "type": "item",
                        "name": "minecraft:grass"
                    }
                ]
            }
        ]
    }

    "stone" is always the initial tier due to the initial range of 1. This time there is a 50% chance per bonus roll of increasing the tier by 1. Assuming the first of the 2 bonus rolls succeeds and causes tier 2 to now be selected, there is another 50% chance to use up the last bonus roll to move to tier 3. Thus there is a 25% chance of "stone" remaining as the selected tier after 2 bonus rolls, a 50% chance of "sand" both being bonus-rolled into and kept from there, and a 25% chance of "grass" being selected after both "stone" and "sand" are skipped by the 2 bonus rolls.

    As a final example, given the following table:

    {
        "pools": [
            {
                "tiers": {
                    "initial_range": 3,
                    "bonus_rolls": 1,
                    "bonus_chance": 0.25
                },
                "entries": [
                    {
                        "type": "item",
                        "name": "minecraft:stone"
                    },
                    {
                        "type": "item",
                        "name": "minecraft:sand"
                    },
                    {
                        "type": "item",
                        "name": "minecraft:grass"
                    }
                ]
            }
        ]
    }

    The initial range encompasses all available tiers, meaning each has a 33% chance of being initially selected. There is only 1 opportunity to move up a tier as defined by "bonus_rolls", and that has a 25% chance of succeeding. Thus if "stone" is initially selected, there is a 25% chance that it moves up to "sand" instead. If "sand" is initially selected, it has a 25% chance of becoming "grass". And if "grass" is initially selected, then it has a 25% chance of moving to the next tier. However, there is not a next tier, which means no item will be provided in those cases.



    Entries



    Nested pools




    Unlike Java edition, entries are allowed to have pools of their own. However, this only works if the entry type is "item" or "loot_table", meaning "empty" will not work. The entry must successfully provide item(s), meaning you cannot use the "loot_tables/empty.json" table to stop the entry itself from providing items. Pools can continue to be nested within nested pools. The structure is simply a raw loot table:

    {
        "pools": [
            {
                "rolls": 1,
                "entries": [
                    {
                        "type": "item",
                        "name": "minecraft:stone",
                        "pools": [
                            {
                                "rolls": 3,
                                "entries": [
                                    {
                                        "type": "item",
                                        "name": "minecraft:sand"
                                    },
                                    {
                                        "type": "item",
                                        "name": "minecraft:grass"
                                    }
                                ]
                            }
                        ]
                    },
                    {
                        "type": "item",
                        "name": "minecraft:stick"
                    }
                ]
            }
        ]
    }

    The table will provide either "stone" or "stick" at a 50% split chance, but if "stone" is selected, it will also provide items from the nested pool (3 rolls, with "sand" and "grass" also being split at 50% chance).



    Functions



    minecraft:enchant_book_for_trading




    Enchants an item using a predetermined algorithm for enchanting items sold by villagers. Takes four modifiers with unknown usage: "base_cost", "base_random_cost", "per_level_cost", and "per_level_random_cost". These modifiers may actually do nothing in the context of a loot table, though the item will still be enchanted using whatever default values.

    minecraft:enchant_random_gear




    Randomly enchants the item using a predetermined algorithm used for enchanting worn gear on mobs. Takes a "chance" modifier to manipulate the algorithm. Note that a "chance" modifier of 1.0 does not mean a 100% chance that gear will become enchanted. The following enchants the item based on these factors:

    {
        "pools": [
            {
                "rolls": 1,
                "entries": [
                    {
                        "type": "item",
                        "name": "minecraft:diamond_sword",
                        "weight": 1,
                        "functions": [
                            {
                                "function": "minecraft:enchant_random_gear",
                                "chance": 0.5
                            }
                        ]
                    }
                ]
            }
        ]
    }


    minecraft:enchant_randomly




    While this function exists in Java edition, there are a couple differences. Bedrock edition accepts a "treasure" boolean, allowing treasure enchantments to be toggled when applying random enchantments. However, unlike Java edition, there is no "enchantments" list that allows you to directly specify a list of enchantments to randomly select from.

    The following allows you to enchant randomly but exclude treasure enchantments:

    {
        "pools": [
            {
                "rolls": 1,
                "entries": [
                    {
                        "type": "item",
                        "name": "minecraft:diamond_sword",
                        "weight": 1,
                        "functions": [
                            {
                                "function": "minecraft:enchant_randomly",
                                "treasure": false
                            }
                        ]
                    }
                ]
            }
        ]
    }


    minecraft:exploration_map




    Expected to transform a map into an exploration map (though I could not personally get it to work; might only be usable within villager trading context). Accepts a "destination" string, specifying which structure to locate, with valid values being "monument" and "mansion".

    minecraft:looting_enchant




    While both Java and Bedrock editions have this function, Bedrock does not have the "limit" integer to act as a cap on the number of new items provided through the Looting enchantment.

    minecraft:random_aux_value




    Unknown. Takes a "values" array that crashes the game when inputting more than 1 element.

    minecraft:set_data_from_color_index




    Sets the data value of the item depending on internally-provided context. Because this context cannot be specified manually, this function is useless for all but a few cases, such as sheep wool color (killed or sheared). There are no options for this function. The following table provides stained hardened clay blocks with a data value corresponding to the color of a sheep's wool, provided this table is either used for sheep-killing or sheep-shearing:

    {
        "pools": [
            {
                "rolls": 1,
                "entries": [
                    {
                        "type": "item",
                        "name": "minecraft:stained_hardened_clay",
                        "weight": 1,
                        "functions": [
                            {
                                "function": "minecraft:set_data_from_color_index"
                            }
                        ]
                    }
                ]
            }
        ]
    }


    minecraft:set_nbt




    The "minecraft:set_nbt" function from Java edition does not exist in the Bedrock edition.

    minecraft:set_attributes




    The "minecraft:set_attributes" function from Java edition does not exist in the Bedrock edition.



    Conditions



    NOTE: Currently conditions may not use namespaces for Bedrock edition. Please keep that in mind when porting over any Java edition loot tables, which accept namespaces for conditions.

    minecraft:killed_by_player




    While both Java and Bedrock editions have this function, Bedrock does not have the "inverse" boolean to only allow the condition to succeed if the mob was not killed by a player.

    minecraft:random_difficulty_chance




    This condition will be true based on a chance, modified by the difficulty setting. A base value specified in the "default_chance" double represents the chance that all unspecified difficulties have. Each difficulty, specified as "peaceful", "easy", "normal", "hard", can have their own chance that overwrites the default chance.

    The following table has a 50% chance of succeeding on all unspecified difficulties, while easy and hard difficulties have a 10% and 100% chance respectively.

    {
        "pools": [
            {
                "rolls": 1,
                "entries": [
                    {
                        "type": "item",
                        "name": "minecraft:stone",
                        "weight": 1,
                        "conditions": [
                            {
                                "condition": "random_difficulty_chance",
                                "default_chance": 0.5,
                                "easy": 0.1,
                                "hard": 1.0
                            }
                        ]
                    }
                ]
            }
        ]
    }


    minecraft:random_regional_difficulty_chance




    This condition will be true based on a chance, related to a chunk's regional difficulty. Only a "max_chance" double can be provided. Unsure exactly how chances are modified by regional difficulty.

    minecraft:entity_scores




    The "minecraft:entity_scores" condition from Java edition does not exist in the Bedrock edition.



    Conclusion



    External links




    - Generic JSON Validator
    - Minecraft Wiki: Loot table
    - Javascript loot table generator by MrPingouin1 (for Java edition)

    Conclusion




    If there is information that needs to be added, corrected, or clarified, please post! I do not play Bedrock edition, so I can only go so far with this myself.

    Posted in: MCPE: Map Help & Requests
  • 0

    posted a message on [SOLVED] Two questions about Items AttributeModifiers

    For #1, you would have to have multiple copies of the modifier, with the only difference being the "Slot" value.

    For #2, the default modifiers have a specific hard-coded display. You would have to use the "Lore" tag to try and replicate it, which then means you'd have to manually write down the values instead of the modifiers doing it for you.

    Posted in: Commands, Command Blocks and Functions
  • 0

    posted a message on 1.12 - Custom Advancements (AKA Achievements)
    Quote from scabbed»

    hello, i have a problem


    i made lots of custom advancement i put it on a multiplayer server, when i start the server, no advancement are shown, i have to do /reload, then they all appear


    the problem is that when i restart the server i lost all advancement again and i have to reload again to show them, and player lost all the advancement they had :(


    any fix ?


    thanks




    Sorry, I haven't heard of that problem. You might be better off posting in the Server Support section, especially if the server you're using is not vanilla.




    Added a new section describing the processing order of triggers in relation to other features:

    Processing order of triggers

    The following timeline describes the order in which specific triggers activate in each game tick. This can be useful when running a function as a reward. For example, if you needed to run commands before entities are processed (and after command blocks are processed), the "minecraft:tick" trigger will do so. If you needed to run commands after entities are processed, you would use the "gameLoopFunction" gamerule to run the necessary function.

    Posted in: Commands, Command Blocks and Functions
  • 0

    posted a message on 1.12 - NBT Changes and Additions

    Sorry for the long delay.

    Changes between 1.12-pre1 and 1.12:

    "enteredNetherPosition" (compound), "enteredNetherPosition" > "x/y/z" (double)

    Compound containing three doubles about where the player entered the Nether from, using Overworld coordinates. Does not exist if the player is not in the Nether.

    /testfor @a {enteredNetherPosition:{x:1.0,y:64.0,z:2.0}}
    Posted in: Commands, Command Blocks and Functions
  • 0

    posted a message on Function Issue

    You cannot have forward slashes for commands in functions.

    If you leave the output log open (changed via launcher settings), you'll receive error messages that can help determine that.

    Posted in: Commands, Command Blocks and Functions
  • 0

    posted a message on Function Issue

    You should provide the function itself, as some errors within it can cause that problem.

    First thing to note is the use of an uppercase filename. All filenames should be lowercase to circumvent issues between operating systems. If changing it to lowercase doesn't work, you'll need to paste the function itself here.

    Posted in: Commands, Command Blocks and Functions
  • 0

    posted a message on 1.12 - JSON Text Component (for /tellraw, /title, books, signs)

    Sorry it took so long; updated the thread to 1.12 to include the "keybind" feature.

    Posted in: Redstone Discussion and Mechanisms
  • 2

    posted a message on 1.12 - Custom Advancements (AKA Achievements)

    Sorry for the long delay. I'm now back and have updated the thread with a list of changes between 17w18a and 1.12 release, as well as extra info after studying MCP.

    Shared Data


    1. A new "status effects" shared object has been added.
    2. The "status effects" shared object has been added to "entity".
    3. Added "nbt" strings to the "entity" and "item".
    4. Added "location" shared object to "entity".

    Triggers

    The entire list of triggers has been relocated to this post due to exceeding the character limit in combination with the main body.

    1. The "arbitrary_player_tick" trigger has been removed.
    2. The "effects_changed" trigger has been added.
    3. The "used_totem" trigger has been added.
    4. The "nether_travel" trigger has been added.
    5. The "brewed_potion" trigger defaults the item's potion ID to "minecraft:empty" when the item does not have a "Potion" string tag.
    6. The "entered_block" trigger also activates based on where an enderpearl landed.

    Requirements


    • The "requirements" list has changed from a DNF to a CNF, and descriptions/examples have been updated.
    • Display


    1. Added "hidden" option.

    Rewards


    1. The "commands" reward has been removed.
    2. The "function" reward has been added.




    Some time in the next week I'll be adding a timeline describing when advancements activate in relation to each other and to entities and tile entities. This will be particularly useful for knowing when functions are going to be running.

    If I've missed any other changes, please let me know!

    Posted in: Commands, Command Blocks and Functions
  • 2

    posted a message on 1.12 - Custom Loot Tables
    Quote from homchi»

    hello in 1.11 i used this loot table to allow spawn eggs drop, but in 1.12 snapshots it's broken, and i'm not sure how to fix it


    villager.json


    {
    "pools": [{
    "conditions": [{
    "condition": "killed_by_player"
    },
    {
    "condition": "random_chance_with_looting",
    "chance": 0.01,
    "looting_multiplier": 0.03
    }
    ],
    "rolls": 1,
    "entries": [{
    "type": "item",
    "name": "minecraft:spawn_egg",
    "weight": 1,
    "functions": [{
    "function": "set_nbt",
    "tag": "{EntityTag:{id:minecraft:villager}}"
    }]
    }]
    }]
    }



    The NBT parser has been rewritten and you'll need to use quotes around strings that contain syntax-breaking characters (in your case, the colon in "minecraft:villager" is breaking syntax):

    {
        "pools": [{
            "conditions": [{
                    "condition": "killed_by_player"
                },
                {
                    "condition": "random_chance_with_looting",
                    "chance": 0.01,
                    "looting_multiplier": 0.03
                }
            ],
            "rolls": 1,
            "entries": [{
                "type": "item",
                "name": "minecraft:spawn_egg",
                "weight": 1,
                "functions": [{
                    "function": "set_nbt",
                    "tag": "{EntityTag:{id:\"minecraft:villager\"}}"
                }]
            }]
        }]
    }


    More information concerning NBT syntax changes here: https://www.reddit.com/r/MinecraftCommands/comments/66jj03/changes_to_the_stringtonbt_parser_in_112/

    Posted in: Commands, Command Blocks and Functions
  • 1

    posted a message on 1.12 - Custom Advancements (AKA Achievements)

    I was able to wait until today before becoming unavailable. Changes to the thread caused by 17w18b:

    Shared data

    1. A new "block" shared object was added, holding data used by the "minecraft:placed_block" and "minecraft:enter_block" triggers.

    Triggers

    1. A new "minecraft:arbitrary_player_tick" trigger has been added.
    2. A new "minecraft:consume_item" trigger has been added (item is before consumption).
    3. A new "minecraft:placed_block" trigger has been added.




    The thread has reached the 120k character limit. Not exactly sure what I'm going to do now, especially if more features are going to keep being added. Will probably have to use my second post in this thread to hold all the triggers, which takes up the bulk of the characters.

    Posted in: Commands, Command Blocks and Functions
  • To post a comment, please or register a new account.