GlymeraMegaChest - Changelog

v4.0.0 (2026-05-16)

This release rolls up everything addressed from the v3.0.0 CurseForge bug-report thread (BottenRastrd 2026-05-12, Walomart 2026-05-06): a crash-safe persistence rewrite, a header-bar UI fix, an impossible-to-craft recipe corrected, and a deliberate "no" to workbench-pulls-from-chest integration. All four were verified in-game against the live Dev server before release.

1. Persistence: chests no longer lose contents after a hard kill

BottenRastrd reported that previously-placed Network Chests became unopenable after quitting to the main menu and returning, with the net files in the network/ folder showing 0 bytes in VS Code. Standard Mega Chests showed the same symptom under restart pressure.

Root cause. v3 saved each chest with:

try (FileWriter w = new FileWriter(f)) { gson.toJson(c, w); }

FileWriter truncates the target file to zero bytes the moment it is opened, before gson writes anything. If anything went wrong between that truncate and the final stream close — JVM kill (SIGKILL), ConcurrentModificationException on c.items while gson was streaming, an I/O error, OOM during serialization — the target JSON file was left empty on disk. The next load saw a 0-byte file and silently discarded the chest (catch (Exception e) { /* skip bad file */ }). Network Chests were more exposed than standard ones because a single per-owner pool means every item movement touches the same JSON file, multiplying the contention window.

Fix. saveChest was rewritten as an atomic four-step:

1. Serialise the chest to a String under synchronized (c). A ConcurrentModificationException mid-serialisation now aborts the save and leaves the previous good copy on disk untouched, rather than corrupting it.
2. Write the bytes to a sibling <id>.json.tmp.
3. FileOutputStream.getFD().sync() to flush OS buffers to the disk.
4. Files.move(tmp, target, ATOMIC_MOVE, REPLACE_EXISTING) — POSIX-atomic rename. The target points either at the previous good copy or at the new complete copy at every instant, never at a half-written file. Safe even if the JVM is killed between steps 3 and 4 (the .tmp is left behind for the recovery path below).

loadChests now self-recovers: if a target <id>.json is missing or unparsable, the loader looks for a sibling <id>.json.tmp and, if it parses cleanly, promotes it to the target (atomic rename again). This safety net catches the rare case where SIGKILL lands between fsync and rename, and also recovers leftover .tmp siblings from older crashes.

saveConfig was deliberately left on the old pattern. Config is written rarely (plugin startup + reload command); only the per-chest hot path was actually exposed.

Verified with a deliberate SIGKILL test against a populated v4 server: chests/network folders had no 0-byte files, no leftover .tmp siblings, and every item placed before the kill was still in-game after restart.

2. UI: trailing >-button stays inside the container

Walomart reported the UI buttons being "out of GUI". A screenshot confirmed that the pagination >-button on MegaChestPage extended roughly halfway past the right edge of the visible container.

Root cause. MegaChestPage.ui #HeaderBar uses LayoutMode: Left with a FlexWeight: 1 search container in the middle and three fixed-width nav elements after it (<, page label, >). Hytale's flex algorithm sizes the FlexWeight element from the remaining space without reserving a right-edge buffer for the trailing fixed widths, so the last element gets pushed past the container's inner edge.

Fix. #HeaderBar padding extended from (Bottom: 4) to (Bottom: 4, Right: 16). The 16-pixel right pad stops the Left-layout flow early enough that the trailing > stays inside the container.

MegaChestDepositPage.ui does not need the same treatment — it has three fixed-width buttons and no FlexWeight middle, so nothing was being pushed past the edge.

3. Network Chest recipe is finally satisfiable

BottenRastrd: "How am I supposed to get this? I make two small ones, place them next to each other to make a Large one, break the large one, and have two small chests again."

He was right. The v3 recipe required Furniture_Temple_Light_Chest_Large as an input, but that item does not exist as an inventory item. Its JSON lives under Server/Item/Items/Furniture/Temple_Light/Unique/ — a Hytale convention for connected-block states. It has no Recipe field, breaking it returns two small chests rather than itself, and "Variant": true marks it as a state variant of the small block under ConnectedBlockRuleSet. No player could ever satisfy the v3 recipe.

Fix. Recipe ingredient changed from Furniture_Temple_Light_Chest_Large × 1 to Furniture_Temple_Light_Chest_Small × 2. Bench requirement (Alchemybench / Alchemy_Potions) and the 3× Ingredient_Life_Essence_Concentrated co-input are unchanged. Costs roughly the same raw materials as the dead-end v3 recipe (2× small chests = 6× Marble + 2× Shale, plus the 3× concentrated Life Essence). Matches the player's intuitive "two small = one large" expectation and keeps the visual/thematic tie to the Temple Light family.

The recipe definition lives in assets/Server/Item/Items/Furniture/Glymera/GlymeraMegaChestNetwork_Block.json. No Java change beyond the version-bump header.

4. Workbenches reading from MegaChest is intentionally not added

BottenRastrd asked: "The workbenches don't 'see' what is in the network chest. Is this intentional?"

Yes, by design — and after looking into what it would take to change that, we are explicitly keeping it that way.

Native Hytale crafting benches pick up nearby item containers via CraftingManager.getContainersAroundBench, which queries a spatial index of blocks that declare BlockEntity.Components.ItemContainerBlock in their JSON. We could add that component to the MegaChest blocks and have the benches see something — but that "something" would be a parallel 36-slot native container sitting next to the plugin's own 1080-slot JSON-backed storage. Players would put iron into our UI, the workbench would not see it; players would put gold into the native container via some external means, our UI would not see it. The two storages would not be synchronisable without a fragile sync layer.

For the Network Chest the model breaks down completely: a single per-owner pool sits behind N block instances, and there is no sensible way to surface "what is in the owner's pool" through a per-block native container. Whose iron shows up in which workbench's range? Does removing iron via a bench drain the pool, and if so, which block "lost" it?

Given this, the MegaChest stays as a personal pool-storage tool that lives next to the vanilla crafting flow rather than inside it. Players who want a workbench-feeding chest should keep using the vanilla Temple Light or Royal Magic Chest for that role. The MegaChest is for hoarding, sorting, and (in the network variant) sharing a single inventory across a player's whole build.

Compatibility

• No data migration needed. v3 chest JSON files are read by v4 unchanged. v4 only changes how new saves are written.
• Any 0-byte JSON files left behind by a previous v3 crash are still unrecoverable (the data was never on disk in the first place) — but a .json.tmp sibling, if present, will be picked up automatically on the next start.
• All in-world placed chests, the per-owner network pool, and the save format are entirely untouched.

v3.0.0 (2026-05-02)

New Features

• Second chest variant: Network Chest — a Temple Light double-chest block with a soft lavender tint (item id GlymeraMegaChestNetwork_Block). Every Network Chest a player places shares a single per-owner item pool. Drop something into one Network Chest and it's instantly available in every other Network Chest the same player owns, anywhere in the world.
• Smart break rule for Network Chests. Unlike the standard Mega Chest, which refuses to break while non-empty, the Network Chest variant:
  • Allows breaking any chest freely as long as the owner still has at least one other Network Chest placed — the pool stays accessible.
  • Blocks breaking only when it's the last Network Chest in the network AND the pool is non-empty, with the message "This is your last network chest. Empty the storage first or place another network chest."
  • The pool itself is never destroyed by a break; items remain in the player's pool until they are taken out through any Network Chest, or until both the pool and the chest count reach zero.
• New OP command /megachest givenet [player] for handing out Network Chest items.
• Standard Mega Chest is unchanged. Same crafting, same model (Royal Magic Chest), same per-chest standalone behavior. Players who do not need a network can keep using it as before.

Why

Customer feedback (CurseForge): players building castles and village settlements wanted crafting benches in different themed buildings to draw from a single shared stockpile. The old workflow with the discontinued pipes mod required manual chest-shuffling. The Network Chest variant solves the storage half of that problem out of the box, while leaving the standalone Mega Chest variant intact for players who want a per-location chest.

Crafting