Elegir la API adecuada

La API del mod funciona dentro de Minecraft con Java 21 y amplía máquinas, recursos e integraciones. La API HTTP del sitio solo sirve documentación y releases: no accede a redes de jugadores ni inicia crafts.

Un addon depende de Nebula y compila contra dev.nebulastorage.api. Aísla adaptadores opcionales para no cargar clases de mods ausentes. API 1.0.0 es independiente de la versión alfa. Estos ejemplos de addons corresponden a Nebula Storage alpha.7 y sus nuevos paquetes. Los archivos publicados hasta alpha.6 usan todavía dev.nexusstorage. Recompila los addons al actualizar; los identificadores de Minecraft y los mundos guardados no cambian.

Registrar una extensión

Implementa NebulaExtension públicamente y coloca su nombre completo en META-INF/services/dev.nebulastorage.api.NebulaExtension, como recurso del JAR sin .txt.

El ejemplo declara example:pressing, pero no crea bloques ni recetas. Registra un adaptador que reconozca el objeto real y una fuente de recetas con entradas y salidas exactas. No accedas al mundo durante el registro.

Registrar una extensión
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"))
    }
}

Publicar recetas sin escanear el mundo

NebulaRecipeSource.discover recibe capacidades disponibles. Devuelve ofertas aplicables con IDs estables, salidas garantizadas y costes reales. Incluye subproductos, no medias aleatorias.

Incrementa revision al cambiar la fuente o recargar datapacks. Cambiar inventario cambia disponibilidad, no todo el catálogo. Descubrimiento y resolución deben ser puros, limitados y sin transferencias.

Conectar una máquina real con seguridad

NebulaPlatformExtension conecta bloques reales con procesamiento propio. Resuelve solo máquinas cargadas y expone propietario persistente y todas las entradas y salidas. Energía y presión siguen siendo nativas.

Prueba inserción parcial, salida bloqueada, cancelación tras consumo, descarga de chunks, guardado y reemplazo. Cada recurso conserva un único propietario. Una simulación exitosa no garantiza la inserción posterior.

  1. DescubrirLeer capacidades y recetas
  2. PlanificarReservar recursos exactos
  3. EjecutarTransferir al propietario real
  4. RecuperarLeer el recibo guardado
Descubrir no modifica datos. Solo ejecutar transfiere propiedad; recuperar no recrea entradas consumidas.

Leer la red de un jugador

Obtén consultas en serverStarted y usa forPlayer con UUID autenticado. Cada lectura verifica permisos; un UUID arbitrario del cliente no prueba identidad.

Las copias son observaciones, no reservas. Revalida acciones y libera referencias en serverStopped. Observadores sin actor solo reciben historial público.

Fuente

docs/api.md; editorial/es.json

43b4d12d69e6033c24fa8c39dac383ef2429b446