Hytale Platform

Hytale Platform

EverNifeCore has a second platform implementation for Hytale, alongside the Bukkit one. It lives in the hytale module and provides the same common core to a Hytale server through its own IPlatform implementation.

Maturity. The Hytale port is under active development. It compiles on this branch and mirrors the Bukkit bootstrap, but it has not had the same real-server validation the Bukkit platform has. Treat it as a work in progress: the API shape is settling, and not every subsystem is proven end-to-end. The Bukkit platform is the mature, validated target.

For how a platform plugs into the core in general, see Platform Abstraction.

---

What's in the module

Piece	Role
EverNifeCoreHytalePlugin	The plugin entry point (com.hypixel.hytale...JavaPlugin subclass).
HyPlatform	The IPlatform implementation (getPlatformProviderId() returns "hytale").
HyECPluginExtractor / HyECEventDispatcher	The other two providers.
HyConfigTypes	Registers Hytale's config types (vectors, locations) on ConfigFactory.
HyFCScheduler	The real class behind the api-contracts scheduler stub.
HytaleFPlayer	The FPlayer adapter for a Hytale PlayerRef.
HyVaultIntegration / HyPAPIIntegration	Economy (VaultUnlocked) and PlaceholderAPI hooks.
HyCommandRegisterer	Registers the Hytale-only debug command; the shared commands come from the core (below).

Bootstrap

EverNifeCoreHytalePlugin follows the same shape as the Bukkit loader (Architecture Overview):

• Constructor - registers the three providers (IECPluginExtractor, IPlatform, ECEventDispatcher), sets the Hytale region grid, and calls onLoaderInstantiate(...).
• setup() - runs EverNifeCore.instance.onLoadPre() (the common bootstrap: ConfigManager, Cooldown, CommandRegisterer), then HyVaultIntegration.initialize(), HyCommandRegisterer.registerCommands(...), the login listener, and onLoadPost().
• shutdown() - calls onUnload(), which flushes dirty player data and closes storage.

Because onLoadPre() runs the shared CommandRegisterer, the framework's own admin commands (/account, the storage transfer/status commands, the cooldown command, ...) are registered on Hytale the same way they are on Bukkit. HyCommandRegisterer only adds a Hytale-specific debug command on top.

---

Java 25, and why the shadow jar is heavier

hytale is plain Java 25 - the Java 25 toolchain with no Jabel and no bytecode cap, unlike the dual-target Bukkit modules. Records and modern APIs are fine here. See Java Versions and Toolchains.

The Hytale runtime has no libby (the runtime dependency loader the Bukkit side uses) and does not ship the common libraries a Bukkit server provides. Two consequences shape the shadow jar:

• The whole EveryDatabase stack is embedded in the jar and relocated to br.com.finalcraft.everydatabase.libs.* - the same relocation pairs minecraft/build.gradle and EDBDependencies use, so the classes and their rewritten references line up. On Bukkit those heavy deps are downloaded by libby at runtime; on Hytale they are baked in.
• The jar carries commons-lang3 and guava. The bundled :common code uses StringUtils/Validate/Guava, which a Bukkit server already provides but Hytale does not - so the Hytale jar must supply them itself. (This is why hytale/build.gradle declares them even though the module's own sources barely touch them.)

The shadow jar uses classifier Hytale (artifact base name EverNifeCore) and is published as evernifecore-hytale.

---

Backends available on Hytale

Storage backends work the same way as on Bukkit - the admin picks one in storage.yml (see Storage Backends) - with one exception:

MySQL / MariaDB is not available on Hytale. The MySQL driver is GPLv2, so it is deliberately excluded from the shadow jar to avoid imposing GPL on the artifact - and there is no libby to fetch it at runtime. Use PostgreSQL, H2, MongoDB, or the file/memory backends on Hytale instead. (On Bukkit the driver is downloaded by libby, so MySQL works there.)

---

Pinned server API

The Hytale server API is pinned in the version catalog:

hytale-server = "0.5.6"

It is pinned on purpose: a floating version lets an unannounced API change break the module without anything in this repository having moved. Bump hytale-server deliberately when you want to build against a newer API, and expect to fix up call sites.

The Hytale-specific dependencies (VaultUnlocked, placeholderapi-hytale) are compileOnly; the manifest.json declares a required dependency on Hytale:EntityModule and optional dependencies on the PlaceholderAPI and VaultUnlocked Hytale plugins.

---

See also

• Platform Abstraction - how HyPlatform and the platoverride stubs plug into the core.
• Java Versions and Toolchains - why Hytale is plain Java 25.
• Building from Source - :hytale:shadowJar and the Hytale repositories.
• Storage Backends - the storage.yml backend picker (and the MySQL caveat above).