Mineralogy 6 Developer Guide

Developer Guide

Mineralogy 6 documentation: M6 index | OreSpawn provider | Modpack guide

Mineralogy 6 owns geological content. OreSpawn 4 owns the supported world-generation integration surface.

Integration boundary

Mineralogy owns	OreSpawn owns
Blocks, items, fluids, and block entities	Terrain replacement and formations
Models, textures, language, recipes, and loot	Geomes and biome influence
Mining, family, and crafting tags	Ore and fluid-deposit placement
Registry aliases and old-save compatibility	Profiles, UI, retrogen, and templates
Mineralogy's provider declaration	Provider loader and public Java API

Do not build a new worldgen integration against Mineralogy's internal classes. Publish an OreSpawn provider or use the supported zone.moddev.mc.orespawn.api package.

Depending on Mineralogy content

Use registry IDs and tags rather than Java fields from internal packages.

Useful public data contracts include:

• mineralogy:rocks as block and item tags;
• mineralogy:standard_rocks as block and item tags;
• the broad sedimentary, metamorphic, and igneous rock tags;
• mineralogy:crafting_materials/<rock> for matching recipes.

Use Forge and vanilla stone or cobblestone tags when broad compatibility is intended. Keep a material-specific recipe narrow when its output must match the input rock.

Supplying worldgen

A content mod should:

1. register and own its blocks or fluids;
2. publish a declarative OreSpawn provider;
3. use stable, namespaced provider rule IDs;
4. declare valid hosts, dimensions, and optional biome rules;
5. let OreSpawn validate and bake the profile;
6. suppress its native generator only when OreSpawn confirms takeover.

Do not put provider callbacks, registry lookups, configuration reads, or logging inside terrain or ore placement loops.

Read the OreSpawn Developer Guide and OreSpawn Java API for the current integration surface.

Packaged Mineralogy provider

The reference provider is:

src/main/resources/data/mineralogy/orespawn/provider.json

When changing it:

1. Keep provider-owned IDs stable.
2. Increase provider_revision when new IDs or defaults should be discovered by existing worlds.
3. Preserve user-edited world profiles.
4. Validate the JSON against the matching OreSpawn schema.
5. Run provider tests and an integrated world-generation smoke.

OreSpawn's optional vanilla ore presets are not Mineralogy-owned and must not be copied into this provider.

Backward compatibility

Historical Mineralogy blocks with names that now overlap vanilla content remain registered for old saves. New terrain can use aliases to select the vanilla blocks.

Changing a registry ID requires a deliberate migration. Renaming a Java field does not migrate a block already stored in a world.

The historical aliases mineralogy:pummice and mineralogy:saprolite also belong to the saved-world compatibility contract.

Building a current branch

Use the Java and Forge toolchain required by that Minecraft branch. For the current public Mineralogy 6 reference branch, use Java 17 and run:

.\gradlew.bat test build javadoc --no-daemon
.\gradlew.bat genEclipseRuns eclipse --no-daemon

Validation should include:

• unit and provider tests;
• JSON and language-file checks;
• processResources and a complete build;
• Javadocs and publication jars;
• Eclipse run generation;
• a bounded client resource smoke;
• a fresh-world generation check.

Private workspace notes and coding-agent files are not public documentation and must not be copied into the wiki.

Exact reference

The source guide is available in the canonical Mineralogy 6 branch.

The installed build exports its exact guide to:

config/mineralogy-guide/