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