FAQ

Browse the FAQ

Search by question or keyword.

General

Which modloader do I need?

All Let’s Do mods are built on Architectury and work on both Fabric and NeoForge.

What is Architectury API and why is it required?

Architectury API is a shared library that allows mods to run on multiple modloaders using a single codebase. All Let’s Do mods are built on Architectury to ensure consistent behavior across platforms. Architectury API is always required, no matter which modloader you use.

Why do I need Fabric API when using Fabric?

Fabric API provides core hooks and functionality used by many Fabric mods, including Let’s Do. When running Let’s Do mods on Fabric, both Architectury API and Fabric API must be installed.

What happens if a required API is missing?

If a required API is missing, Minecraft will usually fail to start and display an error message listing the missing dependency. This simply means a required library has not been installed yet.

Which Minecraft versions are supported?

Development currently focuses on Minecraft 1.21.1 and will likely stay there for a while. We prefer to take our time and do things properly. Where it goes from here, we’ll see.

Do I need other dependencies?

Architectury API is always required. When using Fabric, Fabric API is required as well. Additional dependencies may exist depending on the mod and are always listed on the mod page.

Is there a config file?

Some mods already include configuration options. If you don’t see a config yet, it simply means it’s planned for the future and will be added as the mod continues to grow.

Can I use Let’s Do in my modpack?

Yes, modpacks are absolutely allowed. You may include Let’s Do mods in modpacks distributed via official platforms such as Modrinth or CurseForge. However, re-uploading, redistributing, or modifying the original mod files themselves is not permitted. Always link back to the official download page.

How to install

How do I install Let’s Do mods?

Install a compatible modloader such as Fabric or NeoForge. Then install Architectury API. If you are using Fabric, Fabric API is required as well. Download the Let’s Do mod jar and place it into your Minecraft mods folder. Launch the game and verify the mods show up in the Mods list.

Where can I download Let’s Do mods?

Let’s Do mods are officially distributed via Modrinth and CurseForge. Please download mods only from these official platforms. Re-uploading or redistributing the original mod files is not allowed. If you share the mods, always link back to the official download page.

Where do I get Fabric or NeoForge?

Official websites:
fabricmc.net
neoforged.net

Compatibility

Are Let’s Do mods compatible with worldgen mods?

Yes. As long as other mods rely on vanilla biome tags, Let’s Do world generation will integrate alongside them. For example world generation mods like Terralith work seamlessly. Just keep in mind that worldgen features will only show up in new chunks.

Do Let’s Do mods work with performance mods?

Sodium- and Rubidium-based performance mods generally work well. In some cases, custom renderers may behave differently depending on the rendering setup.

Why do I see “No data fixer registered” in the logs?

This message refers to Minecraft’s DataFixerUpper, a system Minecraft uses to update and convert very old world data between versions. Let’s Do mods do not rely on DataFixers, as changes are handled directly within the mod logic. The message is harmless and can safely be ignored.

Resource Packs

What are resource packs?

Resource packs are a vanilla Minecraft system used to change visuals and audio. They control textures, models, animations, particles, UI elements, fonts, and sounds. Resource packs do not change gameplay logic.

How does Let’s Do use resource packs?

Some Let’s Do mods include optional built-in resource packs for specific features such as bushy leaves or CTM support. These packs are optional and can be enabled in the Resource Packs menu if available.

Can I create my own resource pack for Let’s Do?

Yes. You can create a resource pack that overrides Let’s Do textures or models. This works the same way as overriding vanilla assets. Only visual elements can be changed through resource packs.

Data packs

What are datapacks and how do they work?

Datapacks are a vanilla Minecraft system that allows changing or extending game behavior using JSON files. They operate on the server side and can modify recipes, loot tables, tags, advancements, and world generation. Following we provide example datapacks in this FAQ to help you understand how overrides work and to make it easier to experiment, test changes, and customize your worlds.

How do I create a datapack?

Below in this FAQ, you will find step-by-step explanations and complete JSON examples for recipes, loot tables, tags, and world generation. Simply copy the structure shown here, create your own datapack folder, and override the files you want to change. Only the files you modify need to exist inside your datapack.

How can datapacks be loaded?

Datapacks can be placed directly into a world’s datapacks folder. Alternatively, mods like OpenLoader or Global Datapacks can load datapacks globally across all worlds. Datapacks are applied when a world is loaded or reloaded.

What can I change using datapacks?

Datapacks can be used to change recipes, loot tables, mob drops, tags, and world generation behavior. Many Let’s Do features are controlled through tags, allowing you to enable, disable, or extend behavior. This includes things like spawn rules, interactions, and structure placement.

Datapack tutorial and example pack

Create a folder in: saves/<world>/datapacks/
Add a pack.mcmeta file
Add the files you want to override using the exact same path
Run /reload and verify with /datapack list

Example pack download: lets-do-example-datapack.zip

pack.mcmeta

{
  "pack": {
    "pack_format": 48,
    "description": "Let’s Do Datapack"
  }
}

pack_format

This defines which Minecraft version the datapack targets. For Minecraft 1.21.1 the correct pack format is 48. If this number does not match your Minecraft version, the pack will show as incompatible.

description

This is the display name shown in the datapack menu inside Minecraft. It does not affect functionality and can be anything you like.

Note: World generation changes only apply to new chunks. Existing terrain will not be retroactively updated.

How do I change recipes?

Let’s say we want to override a normal Farm & Charm crafting recipe. This is how the original recipe looks:

Original shaped recipe

{
  "type": "minecraft:crafting_shaped",
  "pattern": [
    "###",
    "###",
    "###"
  ],
  "key": {
    "#": {
      "item": "farm_and_charm:barley"
    }
  },
  "result": {
    "id": "farm_and_charm:barley_ball",
    "count": 1
  }
}

If we want to change the output, we only modify the result section:

Changing the output

{
  "type": "minecraft:crafting_shaped",
  "pattern": [
    "###",
    "###",
    "###"
  ],
  "key": {
    "#": {
      "item": "farm_and_charm:barley"
    }
  },
  "result": {
    "id": "minecraft:diamond",
    "count": 1
  }
}

Now crafting nine barley will produce a diamond instead of a barley ball.

If we instead want to change the required ingredient, we modify the key section:

Changing the input

{
  "type": "minecraft:crafting_shaped",
  "pattern": [
    "###",
    "###",
    "###"
  ],
  "key": {
    "#": {
      "item": "minecraft:diamond"
    }
  },
  "result": {
    "id": "farm_and_charm:barley_ball",
    "count": 1
  }
}

Now the recipe requires diamonds instead of barley.

Note:
In shaped recipes every row in the pattern must have the exact same length. Spaces matter. Each string represents one full row of the crafting grid.

Valid (row lengths match)

"pattern": [
  "b  ",
  "   ",
  "   "
]

Invalid (row lengths differ)

"pattern": [
  "b",
  "   ",
  "   "
]

Not all recipes use minecraft:crafting_shaped. Custom crafting blocks use their own recipe types.

Example: A Cooking Pot recipe in Farm & Charm:

Cooking Pot recipe

{
  "type": "farm_and_charm:pot_cooking",
  "ingredients": [
    { "tag": "farm_and_charm:corn" },
    { "tag": "farm_and_charm:corn" },
    { "tag": "farm_and_charm:flour" }
  ],
  "requireContainer": true,
  "container": {
    "id": "minecraft:bowl",
    "count": 1
  },
  "result": {
    "id": "farm_and_charm:corn_grits",
    "count": 1
  },
  "requiresLearning": false
}

Notice the type is different. Each custom crafting system defines its own structure and required fields. Always check the original recipe to understand which keys are required.

How do I extend or change tags?

Tags are one of the cleanest ways to tweak behavior. In most cases you want to extend an existing tag, not replace it. Use "replace": false to keep the original entries and only add your own.

Example: Let’s say we want the diamond block to be considered a valid heat source for the Cooking Pot. We look for the heat source tag and add minecraft:diamond_block to the list.

Heat source tag (extended)

{
  "replace": false,
  "values": [
    "farm_and_charm:stove",
    "minecraft:redstone_block",
    "minecraft:magma_block",
    "#minecraft:campfires",
    "minecraft:diamond_block",
    {
      "id": "farmersdelight:stove",
      "required": false
    },
    {
      "id": "meadow:stove_tiles_wood",
      "required": false
    }
  ]
}

Tags can also reference other tags. When you want to include another tag, the # prefix is required:

Referencing another tag

{
  "replace": false,
  "values": [
    "#c:grains/barleys"
  ]
}

How do I change loot tables?

Loot tables control what blocks, chests, mobs, or other sources drop. To change a drop, override the loot table JSON in your datapack using the exact same file path and name.

Here is a simple block loot table example:

Example block loot table

{
  "type": "minecraft:block",
  "pools": [
    {
      "bonus_rolls": 0.0,
      "conditions": [
        {
          "condition": "minecraft:survives_explosion"
        }
      ],
      "entries": [
        {
          "type": "minecraft:item",
          "name": "farm_and_charm:fertilized_soil"
        }
      ],
      "rolls": 1
    }
  ]
}

What do these fields mean?

pools: A loot table can have multiple pools. Each pool is rolled separately.
rolls: How many times this pool is rolled. If rolls is 1, the pool runs once.
bonus_rolls: Extra rolls added on top of rolls.
conditions: Rules that decide if the pool is allowed to run.
entries: The actual things that can drop.

Example: We want farm_and_charm:fertilized_soil to drop a diamond instead. We override the block loot table and change the item entry.

Important: For block drops, the loot table file name must match the block id.
Example path: data/farm_and_charm/loot_tables/blocks/fertilized_soil.json

Fertilized Soil drops diamonds

{
  "type": "minecraft:block",
  "pools": [
    {
      "bonus_rolls": 0.0,
      "conditions": [
        {
          "condition": "minecraft:survives_explosion"
        }
      ],
      "entries": [
        {
          "type": "minecraft:item",
          "name": "minecraft:diamond"
        }
      ],
      "rolls": 1
    }
  ]
}

That’s it. Reload your datapacks and test the drop.

How do I change world generation?

World generation is fully data-driven. Most features consist of two parts: configured features and placed features.

Important:
World generation changes only apply to new chunks. Existing terrain will not be retroactively updated.

1. Configured Feature

The configured feature defines what is generated and how it behaves. Example: wild barley patch from Farm & Charm.

Configured Feature

{
  "type": "minecraft:random_patch",
  "config": {
    "feature": {
      "feature": {
        "type": "minecraft:simple_block",
        "config": {
          "to_place": {
            "type": "minecraft:simple_state_provider",
            "state": {
              "Name": "farm_and_charm:wild_barley"
            }
          }
        }
      }
    },
    "tries": 11,
    "xz_spread": 7,
    "y_spread": 2
  }
}

Key fields explained:

type: Defines the feature logic. Here: random patch.
Name: The block that gets placed.
tries: How many placement attempts per patch.
xz_spread: Horizontal spread size.
y_spread: Vertical variation.

2. Placed Feature

The placed feature defines where and how often the configured feature appears.

Placed Feature

{
  "feature": "farm_and_charm:wild_barley_chance",
  "placement": [
    {
      "type": "minecraft:rarity_filter",
      "chance": 40
    },
    { "type": "minecraft:in_square" },
    {
      "type": "minecraft:heightmap",
      "heightmap": "WORLD_SURFACE_WG"
    },
    { "type": "minecraft:biome" }
  ]
}

Key fields explained:

feature: Links to the configured feature.
rarity_filter: Controls how rare the feature is.
chance: 1 in X chunks. Lower number means more common.
heightmap: Controls vertical placement logic.
biome: Restricts to matching biomes.

Example: Make Wild Barley Rarer

If the current rarity is "chance": 40 it means roughly 1 in 40 chunks. To make it rarer, increase the value:

Rarer placement

{
  "feature": "farm_and_charm:wild_barley_chance",
  "placement": [
    {
      "type": "minecraft:rarity_filter",
      "chance": 120
    },
    { "type": "minecraft:in_square" },
    {
      "type": "minecraft:heightmap",
      "heightmap": "WORLD_SURFACE_WG"
    },
    { "type": "minecraft:biome" }
  ]
}

Tip:
If you want fewer plants per patch, reduce tries in the configured feature.
If you want fewer patches overall, increase chance in the placed feature.

Where can I learn more about datapacks?

If you want to dive deeper into datapack mechanics, these resources are very helpful:

Misode Datapack Generator
https://misode.github.io/

Interactive JSON generators for recipes, loot tables, worldgen and more.

Minecraft Wiki (unofficial)
https://minecraft.wiki/w/Data_pack

Detailed explanations of datapack structure, pack formats and file paths.

Licensing & Support

What license do the mods use?

Can I ask about asset usage?

Yes. If you are unsure about asset usage, just ask.

Where should I report bugs or issues?

Preferred: GitHub Issues
Let’s Do - GitHub Issues

Alternative: Discord
Let’s Do - Discord

How should I report an issue?

To help resolve issues faster, please include: Minecraft version, mod name and version, confirmation that you are on the latest version, a short description, steps to reproduce, and logs or crash reports if available.

Why is direct feedback important?

Let’s Do is built with a lot of personal dedication. I constantly revisit older systems, refactor them, improve performance, and try to raise the overall quality of the projects.

If you encounter bugs, performance issues, compatibility problems, or design flaws, please tell me directly. Open an issue, share logs, describe the steps to reproduce it. I genuinely want to improve things.

Public criticism without direct communication makes it harder to fix real problems. Constructive feedback shared directly helps the project grow.

Short version:
If something is wrong, tell me. I will listen.

Can I help with translations?

Yes. Community translations are always welcome and can be contributed via Pull Requests.

Can I support development?

Support is possible via Patreon. All mods remain fully playable without support.