Slime Worlds (SWM)

Slime is a compact world format from the SlimeWorldManager family (Grinderwolf SWM, Infernal's Advanced Slime Paper, and compatible forks). Instead of a folder of region files per world, a slime world is one small blob loaded into memory or a database. For skyblock, where a server can hold thousands of small per-island worlds, that means far less disk, much faster load and unload, and no filesystem churn.

IgniteSky can host per-island worlds in slime format through the SWM hosting strategy. On an Advanced Slime Paper server it works with no code at all: IgniteSky ships a built-in bridge that registers itself automatically. It is entirely optional, and with no slime backend it simply uses normal world folders.

When to use it

Turning it on

Set the mode's hosting strategy to SWM (see World Hosting Strategies):

modes:
  skyblock:
    hosting: SWM

On an Advanced Slime Paper server that is all you do: IgniteSky detects ASP and registers its built-in provider for you at startup. If SWM is set but ASP is not present, IgniteSky logs it and falls back to a folder copy, so the server never breaks.

How it plugs in

SlimeWorldProvider is a small typed SPI in the public API. A bridge implements it against a specific SlimeWorldManager's API (a real dependency, no reflection) and registers it with Bukkit's services manager. IgniteSky looks the service up and, when it needs a new island world, calls one method:

// the SPI IgniteSky defines
Optional<World> provisionWorld(String name, long seed, boolean natural);

• name -the world IgniteSky wants created or loaded.
• seed -the world seed (for example ChunkBlock terrain).
• natural -true for vanilla terrain (ChunkBlock), false for a void island world (Skyblock / OneBlock).
• An empty result means the provider could not supply the world, so IgniteSky falls back to a folder copy.

Registering a bridge:

Bukkit.getServicesManager().register(
    com.ignitedev.ignitesky.api.world.SlimeWorldProvider.class,
    myAswmBridge,                 // your implementation, calling the SWM API
    plugin,                       // your bridge plugin / addon
    org.bukkit.plugin.ServicePriority.Normal);

That is all IgniteSky needs. The bridge owns the translation from this one call to whatever the underlying SlimeWorldManager API expects (loaders, property maps, and so on).

Why a bridge instead of built in

SlimeWorldManager is a separate plugin with its own API, several competing forks, and version-specific methods. Compiling IgniteSky's core against one fork would bloat it, pin it to that fork's version, and break the others, for a feature most servers do not use. Keeping it behind a typed SPI keeps the core lean and lets any fork supply a bridge.