Skip to content

Service Registry

DarkBladeDev edited this page Aug 2, 2026 · 4 revisions

πŸ›οΈ Service Registry (SOA)

MultiBlockEngine is built entirely on a Service-Oriented Architecture (SOA). This means that functionality is divided into independent, decoupled services that communicate through well-defined API contracts, managed centrally by the engine.


πŸ’‰ Dependency Injection (@InjectService)

The engine provides a robust, built-in Dependency Injection (DI) system for both internal core components and external addons.

How to Inject Services

In any class managed by the engine (such as your MultiblockAddon main class or a custom service you register), you can annotate a field to have it automatically populated at runtime:

public class MyMachineLogic {
    @InjectService
    private MultiblockRuntimeService runtime;
    
    @InjectService
    private EnergyService energy;
}

Manual Service Lookup

If you find yourself in a context where field injection isn't possible (e.g., inside a transient object or an unmanaged class), you can retrieve services via the static API:

MultiblockRuntimeService service = AddonAPI.getService(MultiblockRuntimeService.class);

🧩 Addon Service Exposure

A major evolution in MultiBlockEngine is the removal of rigid service boundaries. Addons are no longer restricted to just consuming core services; they can register and expose their own services to the ecosystem.

Why does this matter?

If you create a custom mbe-magic addon, you can register a ManaService. Any other addon installed on the server can then simply use @InjectService private ManaService mana; to interact with your system. This creates a highly modular and interconnected ecosystem without brittle, hardcoded plugin dependencies.


πŸ“‹ Available Core Services

These services are always guaranteed to be present as they are provided by the core orchestrator.

Service Description
MultiblockRuntimeService Manages active multiblock instances, searches, and their runtime lifecycle.
AddonLifecycleService Handles addon discovery, dependency resolution, audit logs, and state transitions.
PersistenceService Provides abstract access to the database (SQLite/MySQL) for saving state.
I18nService Handles i18n-aware messaging, player locale resolution, and addon translation registration.
BlueprintService Manages interactive preview sessions and PacketEvents visual rendering.
ToolSessionService Manages active player tool modes, interaction sessions, and tool metrics.
ToolModeExecutionService Executes modular tool mode actions (LinkPortsMode, DisconnectNodesMode, SplitNetworkMode).

πŸ”Œ Ecosystem Services (Addons)

These services are provided by official addons. They are only available if the respective addon is installed on the server.

Service Addon Description
NetworkService mbe-wiring Manages multi-topological generic graphs and cable connections.
EnergyService mbe-energy Handles power producers, consumers, and energy distribution.
PanelViewService mbe-ui Manages decoupled, declarative UI panels and inventory bindings.

πŸ› οΈ Service Lifecycle

The AddonLifecycleService strictly orchestrates the lifecycle of all services (both core and addon-provided) to ensure dependencies are resolved safely. Services transition through these phases:

  1. Discovery: The engine scans for installed addons and service classes.
  2. Register: The service is instantiated and added to the UnifiedServiceRegistry.
  3. Initialize: The @InjectService fields are populated. The service is ready, but active logic (like ticking or listening to events) shouldn't start yet.
  4. Start (Enable): The server is fully loaded. Services can now safely spawn entities, start background tasks, and process events.
  5. Stop (Disable): Triggered during server shutdown or plugin reload for graceful cleanup and persistent data saving.

Clone this wiki locally