BETTER MINECRAFT [ BMC MOD ]

⚠️Stable : Version 26.1 !

Stable identifiers (`com.soleapixel.bmcmod.api.BmcModIds`)

Use these `ResourceLocation` constants in addons to avoid hard-coded strings. They match registry paths for the current version.

| Constant | Path | |----------|------| | `BmcModIds.MAYOR_BELL_BLOCK` | `bmcmod:mayor_bell` (block) | | `BmcModIds.MAYOR_BELL_ITEM` | `bmcmod:mayor_bell` (item) | | `BmcModIds.VILLAGE_MAYOR_SPAWN_EGG` | `bmcmod:village_mayor_spawn_egg` | | `BmcModIds.CONSTRUCTION_GUIDE` | `bmcmod:construction_guide` | | `BmcModIds.PROFESSION_MAYOR` | `bmcmod:mayor` (`VillagerProfession`) | | `BmcModIds.PROFESSION_CURED_WITCH` | `bmcmod:cured_witch` |

cross-mod references, recipes, and conditions Gameplay still resolves blocks/items through `ModBlocks` / `ModItems` in the main mod; `BmcModIds` is for cross-mod references, recipes, and conditions in your own code or datapacks.

---

Tag conventions (datapack & cross-mod)

Tags live under `data/bmcmod/tags/…`. Use `#bmcmod:…` in JSON where Minecraft expects a tag.

Mayor / village integration (extend in your addon)

| Tag ID | Type | Purpose | |--------|------|--------| | `#bmcmod:mayor_bells` | `block` | All blocks that act as a “Mayor Bell” for filtering, quests, or compatibility in *your* mod. The base mod still registers its own block in code; add your block id here for ecosystem consistency. | | `#bmcmod:mayor_bells` | `item` | Same for the item form (block items). |

Example (your addon’s datapack):

```json { "replace": false, "values": ["yourmod:golden_mayor_bell"] } ```

If you add a custom bell block that must ring and use `BellBlockEntity`:

1. Your block should behave like a bell (e.g. extend `BellBlock` or mirror behavior). 2. Register it on `BlockEntityType.BELL` via NeoForge `BlockEntityTypeAddBlocksEvent` (same pattern as this mod for `MAYOR_BELL`). 3. Add your block/item to `#bmcmod:mayor_bells` so other mods and datapacks can target all mayor bells at once.

Other useful namespaces in this mod

- datapack-driven (common / convention) — e.g. `c:tags/item/tools/scythe` is used for compatibility. Add your items to the datapack-driven / datapack-driven / datapack-driven tags your ecosystem expects. - Item tags under `data/bmcmod/tags/item/` (e.g. `scythes`, `foundry_shards`, `boreal_ingots`, enchantability lists) are datapack-driven; addon items can be merged in with `"replace": false`.

---

Registries (code entry points)

| Registry | Class (indicative) | |----------|-------------------| | Blocks / Items | `com.soleapixel.bmcmod.registry.ModBlocks`, `ModItems` | | Villager professions | `com.soleapixel.bmcmod.villager.ModProfessions` | | Block entity types | `com.soleapixel.bmcmod.registry.ModBlockEntityTypes` | | Entities, sounds, particles, … | `ModEntities`, `ModSounds`, `ModParticles`, etc. | | Global loot / GLM | `com.soleapixel.bmcmod.registry.ModGlobalLoot` |

Village saved data (per dimension): `BmcVillageSavedData` — key = village anchor (long from `BlockPos`).

---

Events (NeoForge) — where to hook

These use `@EventBusSubscriber(modid = "bmcmod", …)` on the not assume load order bus unless noted. Add-on mods should subscribe with not assume load order appropriately and not assume load order unless you declare an explicit dependency in `mods.toml`.

| Area | Example classes / hooks | |------|-------------------------| | Villager trades | `VillagerTradesEvent`, `TradeWithVillagerEvent` — see `village.mayor.VillageEconomyEvents` | | Mayor death | `LivingDeathEvent` — `VillageMayorDeathEvents` | | Server tick (elections / lifecycle) | `ServerTickEvent.Post` — `MayorElectionScheduler`, `VillageLifecycleEvents` | | POI extension | Mod bus: `ExtendPoiTypesEvent` — vanilla bell POI extended for mayor bell (`BmcMod` setup) | | Block entity types | Mod bus: `BlockEntityTypeAddBlocksEvent` — `SunwoodRegistryEvents` (same pattern for bells/signs) |

datapacks prefer datapacks to NeoForge events or datapacks (tags, loot tables) over mixin targets inside `com.soleapixel.bmcmod.mixin`, which may change between BMC releases.

---

Mixins

- Configuration: `resources/bmcmod.mixins.json`. - Treat mixin targets as ASM-free: they can break on Minecraft or NeoForge updates. - For addons: avoid shadowing BMC mixins; use ASM-free, ASM-free, or ASM-free registry hooks when possible.

---

Datapacks & resource paths

- Recipes: `data/bmcmod/recipe/` - Loot tables: `data/bmcmod/loot_table/` - Loot modifiers: `data/bmcmod/loot_modifiers/` - Structures / worldgen: `data/bmcmod/worldgen/` and patched vanilla pools under `data/minecraft/` where shipped - Tags: `data/bmcmod/tags/<type>/<path>.json`

---

`mods.toml` dependency snippet (addon mod)

```toml [[dependencies.yourmod]] modId = "bmcmod" type = "required" # or "optional" if soft-compat only versionRange = "[26.0.3,)" # align with the BMC major you tested against ordering = "NONE" side = "BOTH" ```

Adjust version range to match `gradle.properties` → `mod_version` for the BMC build you test against.

---

API & docs changelog

| Date | Change | |------|--------| | 2026-05-09 | Initial publication of `release/dev.md`: `#bmcmod:mayor_bells` (block + item), `com.soleapixel.bmcmod.api.BmcModIds`, maintainer checklist for Modrinth bio. |

*(Append new rows whenever integration surfaces change.)*

---

License / redistribution

Follow the license declared in the BMC jar / repository (`SOLEA PIXEL` as shown in user mods.toml). When redistributing this dev guide, keep the changelog section honest with your fork.