For mod developers

BuildPrint has five public APIs, all in the package com.buildprint.api and all on the client. The examples use the Mojang names of Minecraft 26.x.

Only that package is kept stable. Everything else in BuildPrint can change in any release, so a mixin into those classes will break sooner or later.

Keep BuildPrint optional #

BuildPrint is client-side, and most players of your mod will not have it. Two ways to call it without making it a requirement:

• Check FabricLoader.getInstance().isModLoaded("buildprint"), and keep the calls in a class of their own, so BuildPrint's classes only load when it is there.
• Or call it by reflection. BuildprintBlueprints, BuildprintPlacements and BuildprintHud take only Java types (String, int, arrays, Map, java.util.function), so there is nothing to compile against. See the example.

The editor and format APIs have you implement BuildPrint's interfaces, so they need the jar to compile. An editor add-on registers through a Fabric entrypoint, which Fabric only calls when BuildPrint is installed, so your mod still runs without it.

public final class MyModClient implements ClientModInitializer {
    @Override
    public void onInitializeClient() {
        if (FabricLoader.getInstance().isModLoaded("buildprint")) {
            BuildprintCompat.init();
        }
    }
}

// A class of its own: BuildPrint's classes only load when it is there.
final class BuildprintCompat {
    static void init() {
        BuildprintHud.hideWhile("mymod", MyTool::isOpen);
    }
}

Compiling against it #

BuildPrint is on Modrinth, so the Modrinth Maven works. One file covers both Minecraft versions, so the version number as Modrinth shows it is enough, +26.x included.

repositories {
    maven { url = "https://api.modrinth.com/maven" }
}

dependencies {
    // 0.1.17 or newer, as Modrinth lists it.
    compileOnly "maven.modrinth:buildprint:0.1.17+26.x"
}

Questions #

Something the API should do, or something that does not work: ask on Discord.