Discuss Minecraft's scripting and modding capabilities, including APIs, tools, customization, automation, and creator workflows. Share ideas and feedback on how players and creators can extend and customize Minecraft.

← Scripting and Mods
3
Follow

Self references of loot tables

What is the change?
Allow loot tables to reference the same loot table in data packs before them.

For example, allow a zombie loot table to generate the default loot as well as some additional loot from this pack. (example loot table is attached below). This would allow data packs to extend on others or even the default game without having to copy the files.

How should it work?
Currently a self reference results in an error:

With this change a self-reference would look in the data packs before it for a loot table to draw from.

In the attached example zombies would drop the regular drops as well as a diamond 50% of the time.

This would only happen in loot tables that reference themselves. Other tables that reference them would maintain the same behaviour of getting the table from the current data pack.

One special case would be if a loot table references another that then references the first.

E.g. zombie -> creeper -> zombie.

The proposed way of handling this would be to disallow indirect references.(recursion error mentioned previously) While removing certain possibilities with loot tables, it makes sure behaviour is consistent.

In Summary:
Loot tables can reference themselves directly (not indirectly though), resulting in the equivalent table being used from the data packs before them. This behaviour would be similar to tags being able to append contents rather than overwrite.

Loot table for "minecraft:entities/zombie"

Avatar
Registered User shared this idea

2 Comments

Post a new comment:

Please sign in to leave a comment.

Date Votes
Sorted by oldest
  • 0
    Registered User commented
    Comment actions Permalink

    I like this idea. I had a similar idea where you'd actually get to use real loot-table tag-types and list up and target all your loot-tables more freely.

    Your approach would require datapacks to be loaded in a certain order to get the desired order of execution of "parent" loot-tables. And loot-tables would also need to allow to be extended (just like real tags) instead of just being overridden if the next datapack loads the same resource-location.

    I guess it'd be more consistent/cleaner to add a new tag-type instead since they serve that purpose exactly and self-references usually (or actually always) result in recursive/circular behavior (think about mcfunction recursion).

  • 0
    Registered User commented
    Comment actions Permalink

    I don’t think this is the best way to solve the problem. Self-references could happen by pure accident, and the mechanism you’re suggesting doesn’t support operations such as adding a new entry to an existing pool of a loot table.