ВЕРСИИ (7)

## 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 portal` commands, 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 `/we` command you ran (or what you were doing) - The line from `latest.log` if there's an error - Your `config/worldengine/` files if a world or portal looks wrong

## Breaking change: All existing obsidian-based portals are automatically deactivated on upgrade. Rebuild portals using ore block frames. ### What's new: - **Custom portal block** — WorldEngine portals now use a dedicated animated block instead of vanilla nether portal blocks. Completely eliminates interference with vanilla nether/end portals. - **Ore block frames** — Build portal frames from iron, copper, redstone, lapis, diamond, gold, emerald, or netherite blocks (entire frame must be one type). - **Ore item activation** — Right-click a linked frame with the matching ore item (e.g., diamond on diamond block frame) to activate. Consumes 1 item in survival. - **Teleport warmup** — 1.5 second delay with action bar countdown. Step out to cancel. - **Client-side rendering** — Animated translucent portal texture with colored particles. Requires the mod on both server and client for portals to function. ### Bug fixes: - Fixed vanilla nether portals routing players through WorldEngine portals on return trips. - Fixed portal re-activation failing when clicking certain frame block positions. ### Upgrade notes: - Old obsidian portals will be cleared automatically on first startup. Rebuild with ore block frames. - Players need the mod installed client-side to see and use custom portals. Without it, portals are non-functional but the server won't crash. - Portal setup workflow unchanged: OP right-click frame (empty hand) → /we portal link <world> → any player activates with ore item.

### Bug Fixes - Fix inventory loss when teleporting via vanilla commands or command blocks — Inventory isolation now correctly handles world changes that bypass /we tp, such as execute in <dimension> run tp from command blocks. Previously, armor and items could be lost when crossing inventory group boundaries through non-WorldEngine teleport methods. - Fix server crash when using /we tp with vanilla world names — Running /we tp overworld (or the_nether, the_end) no longer attempts to create a Fantasy dimension that collides with the vanilla world directory. Vanilla worlds with WorldEngine config overrides (gamerules, gamemode, etc.) are now correctly resolved.

### Bugfix Players no longer lose equipped items (armor, etc.) when logging out in the overworld. The onPlayerJoin handler now only applies saved inventory snapshots when the player logged out from a WorldEngine world, not the vanilla overworld. This fixes regression from 1.2.4 & 1.2.5 where snapshots could overwrite valid vanilla inventory with stale data."

1.2.2 — Two login/restart issues: players in lazy-loaded WE worlds now return to that world on login instead of overworld spawn; inventory (XP, hunger, effects) now correctly restored even when the world isn't in an explicit inventory group. 1.2.3 — Fast-placement throttle fixes: no longer blocks container interactions (chests, furnaces, buttons, levers — only activates when holding a placeable block), and now defaults to disabled in new world configs instead of incorrectly throttling survival worlds. 1.2.4 — Players logging out in a WE world now return to their exact logout position and facing after a server restart, not the world spawn.

## [1.2.1] - 2026-02-24 ### Fixed - World configs for vanilla dimensions (overworld, nether, end) were incorrectly deleted as "stale" on every server restart, causing per-world rules (forced gamemode, gamerules) to be lost - Players returning from a WorldEngine world to the overworld via command block were left in the wrong gamemode because the overworld config had been wiped - Creating a WorldEngine world with the same name as a vanilla dimension (e.g. `overworld`) now returns a clear error instead of silently creating a conflicting Fantasy dimension

# Changelog ## [1.2.0] - 2026-02-23 ### Added - **Named portals** — assign a persistent name to any portal with `/we portal name <name>` - **Bidirectional portal linking** — link two named portals to each other with `/we portal link <portal-name>`; both sides update automatically - **Dual key block support** — portals with two key blocks now scan both correctly and use the first detected key block for particle color - **Portal info command** — `/we portal info` shows name, world, position, size, key block, link type, and destination coordinates for the selected portal - **Custom destination coordinates** — `/we portal link <world> <x y z>` links a portal to a specific coordinate in the target world ### Fixed - Bidirectional portal spawn location now correctly places the player inside the destination frame rather than at the frame's lower corner - Dual key block detection no longer skips the second key block when the first scanned position is air ### Changed - `/we portal link` now auto-detects whether the target is a named portal (bidirectional) or a world name (one-way) - Portal list output now shows link direction: `↔ "name"` for bidirectional links, `→ world` for one-way links --- ## [1.0.0] - 2026-02-01 Initial release. - Multi-world creation and management via Fantasy API (9 generator types) - Per-world gamemode enforcement, PvP, difficulty, and gamerule overrides - Inventory isolation with configurable shared groups (items, armor, ender chest, hunger, XP, effects) - Granular mob spawn control by entity type and spawn category - Fast-placement throttle for survival worlds - Custom obsidian-frame portals with key block particle colors - Performance optimizations: lazy loading, idle auto-unload, staggered async saves - Full `/we` command suite with tab completion