1.3.2
Compatibility
Changes
v1.3.2 — Refactor & Stability Pass
TL;DR: Internal cleanup release. No new features, no behavior changes, no config changes. Drop in and go — your worlds, portals, inventory groups, and rules all keep working exactly as before.
Why this exists
I planned to ship MC 26.1.2 support next, but the dependencies WorldEngine needs (Yarn mappings + the Fantasy multi-world library) haven't published 26.1.2 builds yet, so that update is blocked upstream.
Instead of waiting, I used the time to audit the codebase. Three of the biggest files were doing too much at once and would be painful to retarget when MC 26.1.2 lands. Cleaning them up now means the eventual MC 26.1.2 release will ship faster and with less risk.
What changed under the hood
- Inventory system split into focused modules (group registry, on-disk state, event orchestrator) — same on-disk layout, same group commands.
- Portal system split into command/activation/runtime modules — same
ore-frame portals, same
/we portalcommands, same particles. - Command tree (
/we ...) split per feature (worlds / rules / mobs / inventory / status / portals) — every subcommand and tab-completion is byte-identical, just lives in dedicated files now. - Removed dead code, unused imports, duplicated helpers across the rest of the codebase.
Compatibility
- Minecraft: 1.21.11 (unchanged)
- Fabric Loader: 0.18.4+
- Fabric API: 0.141.3+1.21.11
- Java: 21
- Drop-in replacement for v1.3.1. Configs, world data, inventory groups, and portal records are preserved as-is.
What's next
MC 26.1.2 support is queued behind upstream releases. I'm watching:
- Yarn mappings:
meta.fabricmc.net/v2/versions/yarn/26.1.2 - Fantasy library:
github.com/NucleoidMC/fantasy/releases
When both publish 26.1.2 builds, the next release will jump WorldEngine to 26.1.2 (and Java 25). No timeline — depends entirely on upstream.
Reporting issues
If anything misbehaves after the upgrade, please open an issue with:
- The
/wecommand you ran (or what you were doing) - The line from
latest.logif there's an error - Your
config/worldengine/files if a world or portal looks wrong
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:qjqEpxGC:QedqXlsq"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:qjqEpxGC:QedqXlsq"
}

