Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

1.16.5 Loot Tables


Recommended Posts

I am able to Generate new Blocks and Items into my very simple mod ( just has Copper Ore ) while I learn. When it comes to those items I am able to generate the texture just fine, but I get a little stuck how how to allow the new blocks to generate their own item. Is Loot tables the correct thing? or should I be looking for something else? Don't even know where to begin, so details would be helpful. 

 

Thank you in advice. 

 

Edited by Huntpor
Link to post
Share on other sites
1 hour ago, Huntpor said:

I am able to Generate new Blocks and Items into my very simple mod ( just has Copper Ore ) while I learn. When it comes to those items I am able to generate the texture just fine, but I get a little stuck how how to allow the new blocks to generate their own item. Is Loot tables the correct thing? or should I be looking for something else? Don't even know where to begin, so details would be helpful. 

 

Thank you in advice. 

 

i just tell you the best way i think is a loot table

Link to post
Share on other sites
26 minutes ago, Huntpor said:

@Luis_ST Okay, but how would I start that? Like where do the folders need to be to get my server to see the Loot table? 

you could write the loot tables by hand, but forge provides a more developer friendly way of adding loot tables through data generators.

here's the docs for data generation: https://mcforge.readthedocs.io/en/1.16.x/datagen/intro/

 

but basically what you'll want to do is:

1- Subscribe to the GatherDataEvent in the Mod Event bus, there you can get the DataGenerator from the event parameter

2- You can register your Data Providers to the DataGenerator using DataGenerator#addProvider(), passing a new instance of your data Provider

3- Then you'll need a Data Provider for the mod's loot tables. You can create a new class that extends LootTableProvider.

3.1- in your LootTableProvider, add a constructor that takes a Data Generator and simply calls super, passing the data generator

3.2- You'll want to override the getTables methods, to return your instance of lootTables. all you need to do is return an ImmutableList of Pairs. the Pairs are composed of the LootTable constructor (We'll look at how to create the lootTables in a few steps), and the corresponding LootParameterSet (e.g.: for items that drops when you break a block: LootParameterSets.BLOCK)

3.3- You'll need to override the validate method, and honestly, the code for this is only boilerplate, so you can copy it like I did:

    @Override
    protected void validate(Map<ResourceLocation, LootTable> map, ValidationTracker validationtracker) {
        final Set<ResourceLocation> modLootTableIds =
            LootTables
                .getReadOnlyLootTables()
                .stream()
                .filter(lootTable -> lootTable.getNamespace().equals(Main.MOD_ID))
                .collect(Collectors.toSet());

        for (ResourceLocation id : Sets.difference(modLootTableIds, map.keySet()))
            validationtracker.addProblem("Missing mod loot table: " + id);

        map.forEach((id, lootTable) ->
            LootTableManager.validateLootTable(validationtracker, id, lootTable));
    }

3.4- Finally, override getName() and simply return your modid suffixed with "_lootTables"

 

4- Okay, now to writing the actual loot tables: you can create a class that overrides BlockLootTables (call it ModBlockLootTables for instance)

4.1- override addTables(), and in here you register the lootTables, the superclass has a lot of usefull helper methods, such as registerDropSelfLootTable, which makes the block drop itself as an item when broken.

4.2- override the getKnownBlocks() method, the code is also very boilerplatey, so here it is:

    @Override
    protected Iterable<Block> getKnownBlocks() {
        return StreamSupport
            .stream(ForgeRegistries.BLOCKS.spliterator(), false)
            .filter(
                entry -> entry.getRegistryName() != null &&
                    entry.getRegistryName().getNamespace().equals(Main.MOD_ID)
            ).collect(Collectors.toSet());
    }

 

5- Don't forget to add the construcor of this class to the List you're returning in the LootTablesProvider, in getTables

 

Regarding folder structure:

create a data package under your main src path, where you'd keep the init, block, and items folder

under I like to create a class DataGenerators, which handles the gatherData event.

then inside the data package, add two packages, one "client", and one "server"

in client you'd add any dataProvider that's client specific: such as a model provider, or a localization provider

in server you'd keep the common data providers: such as recipes, tags, and lootTables

the Custom LootTablesProvider class should go inside the data.server package

inside server add a loot package, whre you'll kep different lootTables, such as the Custom BlockLootTables class

 

EDIT: oh, and after you're done with the data folder, and after every change you make to it, you need to run the runData task, to actually generate the data, any data that is generated will be under the generated [main] folder

 

if you'd like some example code, take a look at my repo: https://github.com/jvcmarcenes/effetewood

Hope I've helped, if you still have any questions, please ask them

Edited by kiou.23
Link to post
Share on other sites

@kiou.23

 

12 hours ago, kiou.23 said:

you could write the loot tables by hand

 

if you konw json its the better way you also can overide the loot tables with a datapack

so i think its the better way.

and I didn't know that there was this possibility. but I'm open to new things.

Link to post
Share on other sites
18 hours ago, Luis_ST said:

@kiou.23

 

 

if you konw json its the better way you also can overide the loot tables with a datapack

so i think its the better way.

and I didn't know that there was this possibility. but I'm open to new things.

the whole point of the Data Generators is for the dev to not waste time writing (copying and pasting) repetitive json

it automates the whole process of generating data.

sometimes it is better to write the json by hand, but if the project is quite big, looking into Data Generators is definetelly the way to go, not only for loot tables, but for everything that uses json erally, such as block and item models, blockstates, lang files, recipe files and tags.

it does save a lot of time, I can guarantee that

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



  • Recently Browsing

    No registered users viewing this page.

  • Posts

    • hm... when I had a similar issue the discord pointed me towards using baked models. but multiparts does seem way simpler, and with datagen I could even do it proceduraly
    • You don't need a custom baked model for this. Look at the composter model for an example.
    • whenever you find a solution by yourself, you can leave the original question, but add a comment mentioning that you fixed it, and how. so that if anyone comes accross the same problem, they can find your solution and try it without needing to make a new topic. also, I don't see how intellij syncing with github has anything to do with forge
    • you need to create a new class which implements IBakedModel, overwrite getQuads (the one which takes an IModelData) an make it return the quads for your model, the IModelData shouls contain the info on the list and you set the info on the IModelData by overwriting getModelData in your tile entity. you need to sync the data from, the Server tile entity, to the client, which you can do by overwriting getUpdatePacket (Server sends updated data to the client), and onDataPacket  (Client handles an update packet received). then, whenever that data changes you can call World#notifyUpdate, and whenever the client receives an update (so in the end of onDataPacket) you call requestModelUpdate().   for the BakedModel, what I do is: I pass in an existing IBakedModel (that works as a base that I can add quads to) to the constructor, and store it in a field. then I can call IBakedModel#getQuads on the base model, which gives a list of BakedQuads, and add any new quads to it. and you can create your quads by using FaceBakey#bakeQuad, it takes the start and end positions of the quad (in block space, so 0 -> 16), an instance of a BlockPartFace, the sprite you want to use, which you can get from an AtlasTexture, the Direction of that quad, a transform (I just use SimpleModelTransform.IDENTITY), a rotation, which you can just pass null, a boolean that tells wether that face should be shaded or not, and then a throwaway ResourceLocation. and you can decide on all those properties, and on what faces to add, given the IModelData   EDIT: oh, and to register it you can do so through the modelRegistry in the ModelBakeEvent (this event is client-side only (I think)) if you need some examples, I used this repo to learn how to use BakedModels: https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe04_block_dynamic_block_models
    • Your code works well, I should have used the yaw player instead of taking yaw from my projectile. Thank you again
  • Topics

  • Who's Online (See full list)

×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.