RetroAPI

A content library for Minecraft Beta 1.7.3: register blocks, items, mobs, dimensions and world features without hand-rolling id management, and without your mod corrupting the world it is installed in.

Where this sits

Beta 1.7.3 is the version a lot of people mean when they say they miss Minecraft. Quiet worlds, that particular green, terrain that goes up and then stops. It is also, by modern standards, a version with no modding support whatsoever: no registries, no data packs, no ids that survive a mod being removed.

Plenty of work has already gone into fixing that, and RetroAPI stands on it rather than replacing it:

What RetroAPI is actually for

Two things, and it is worth being blunt about them because everything else follows.

1. Making ordinary mod work short

Registering a block should be one call, not an id allocation scheme, an atlas patch and a save-format decision. Most of this wiki is that: a builder for the common case, an escape hatch for the rest.

RUBY_ORE = RetroBlockAccess.create(Material.STONE)
    .strength(3.0F)
    .texture(id("ruby_ore"))
    .needsTool(RetroToolTier.IRON)
    .register(id("ruby_ore"));

2. Not eating the world

This is the part that matters more, and it is the reason the library has the shape it does.

Beta stores a block as a byte plus a 4-bit metadata nibble. There is no room in that format for a modded block, so every approach to modded content on this version has to answer the same question: where do the extra bits live? Answer it by writing modded ids into the vanilla arrays and you get worlds that are fine right up until the mod is removed or its ids shift, at which point chunks come back as the wrong blocks, or do not come back at all.

That is also why RetroAPI can hand you 32,000 block slots, block states wider than the nibble, and per-stack data components on a version with none of those things: they are sidecar features, not edits to the format the vanilla game reads.

Code-driven or data-driven, your choice

Almost everything here can be declared two ways: as a call in your mod, or as a JSON file the game loads. Textures, block states, models, tags and translations all work either way, and they mix freely, one block can take its textures from code and its variants from a blockstate file.

This wiki shows both. Wherever the two differ, a switch sits directly above them, flip it and the whole site follows, and it remembers your choice:

MACHINE = RetroBlockAccess.create(Material.STONE)
    .facing()
    .sided(id("machine_top"), id("machine_side"), id("machine_front"))
    .register(id("machine"));

{
  "parent": "minecraft:block/orientable",
  "textures": {
    "top":   "example_mod:block/machine_top",
    "side":  "example_mod:block/machine_side",
    "front": "example_mod:block/machine_front"
  }
}

{
  "properties": { "lit": ["false", "true"] },
  "variants": {
    "lit=false": { "model": "example_mod:block/lamp_off" },
    "lit=true":  { "model": "example_mod:block/lamp_on" }
  }
}