Öffentliche Addon-API

Die Mod-API läuft in Minecraft unter Java 21 und erweitert Maschinen, Ressourcen und Integrationen. Die HTTP-API der Website liefert nur Dokumentation und Releases; sie liest keine Spielernetzwerke und startet keine Herstellung.

Ein Addon hängt von Nebula ab und kompiliert gegen dev.nebulastorage.api. Optionale Mod-Adapter getrennt halten, damit fehlende Mods keine Klassenladefehler verursachen. API 1.0.0 ist unabhängig von der Alpha-Version. Diese Addon-Beispiele beziehen sich auf Nebula Storage alpha.7 und seine neuen Pakete. Bis alpha.6 veröffentlichte Dateien verwenden noch dev.nexusstorage. Addons müssen beim Upgrade neu kompiliert werden; Minecraft-IDs und gespeicherte Welten bleiben unverändert.

Eine öffentliche NebulaExtension implementieren und den vollständigen Klassennamen in META-INF/services/dev.nebulastorage.api.NebulaExtension als JAR-Ressource ohne .txt eintragen.

Das Beispiel deklariert example:pressing, aber noch keinen Block oder ein Rezept. Ein Maschinenadapter erkennt das echte Item; eine Rezeptquelle liefert exakte Ein- und Ausgaben. Registrierung ohne Weltzugriff durchführen.

package example.nexus

import dev.nebulastorage.api.NebulaExtension
import dev.nebulastorage.api.NebulaRegistrar
import dev.nebulastorage.api.production.ProductionCapabilityId

class ExampleExtension : NebulaExtension {
    override fun register(registrar: NebulaRegistrar) {
        registrar.capability(ProductionCapabilityId("example:pressing"))
    }
}

NebulaRecipeSource.discover erhält verfügbare Fähigkeiten. Nur passende Angebote mit stabilen IDs, garantierten Ausgaben sowie echter Dauer und Energie liefern. Nebenprodukte einschließen; Zufallsdurchschnitte nicht als Garantie ausgeben.

revision bei Quellenänderungen und Datapack-Reload erhöhen. Inventaränderungen betreffen Verfügbarkeit, nicht den ganzen Katalog. Entdeckung und Template-Auflösung bleiben rein und begrenzt.

NebulaPlatformExtension bindet reale Blöcke mit eigener Verarbeitung an. Nur geladene Maschinen auflösen, persistenten Besitzer und alle Prozessein- und -ausgänge erkennen. Energie und Druck bleiben nativ.

Teiltransfers, blockierte Ausgaben, Abbruch nach Verbrauch, Chunk-Unload, Speichern/Laden und Blockersatz testen. Jede Ressource hat stets genau einen Besitzer. Erfolgreiche Simulation garantiert keinen späteren Transfer.

Abfragen in serverStarted erhalten und forPlayer mit der authentifizierten UUID verwenden. Jede Abfrage prüft Rechte. Eine vom Client übermittelte UUID ist kein Identitätsnachweis.

Snapshots sind Beobachtungen, keine Reservierungen. Berechtigungen bei Aktionen erneut prüfen und Referenzen bei serverStopped freigeben. Beobachter ohne Akteur sehen nur öffentliche Historie.