GlymeraMegaChest - Changelog

v7.0.0 (2026-06-04)

Single-issue release fixing an impossible-to-craft recipe on the standard Mega Chest, reported by nennt_mich_ela on 2026-06-04.

The Mega Chest is now actually craftable in survival

nennt_mich_ela reported that the Mega Chest could not be crafted in survival:

"You can't craft the Mega Chest because it needs Royal Chests, and the Royal Chest needs 2 dark hides (dark hide), which you can only get through extra mods or the creative menu. So it isn't craftable for us because we can't get hold of that dark hide."

She is exactly right.

Root cause. The Mega Chest recipe (Alchemybench) required 1x Furniture_Royal_Magic_Chest_Small + 2x Ingredient_Life_Essence_Concentrated. The Royal Magic Chest is a native Hytale item, and its own recipe requires 2x Ingredient_Leather_Dark. Dark leather is tanned from Ingredient_Hide_Dark ("dark hide") — and dark hide has no recipe and does not appear in a single DropList or LootTable anywhere in the Hytale asset set. It is obtainable only through the creative menu. So the dependency chain dead-ended one ingredient deep and the Mega Chest was uncraftable on any survival server. Furniture_Royal_Magic_Chest_Small is, in fact, the only chest in the game gated behind this unobtainable material.

This is the same class of bug as the v4.0.0 Network Chest fix, where the recipe depended on a block that has no obtainable item form.

Fix. The recipe now uses the Royal Magic Chest's own obtainable materials, with only the unobtainable dark hide removed, plus the Mega Chest's existing concentrated life essence:

All three ingredients are obtainable in normal survival play (smelt gold, mine ruby, brew/condense life essence — the same essence the Network Chest already uses). The premium "royal" feel and the purple Royal Magic block model are unchanged; only the dead-end ingredient was swapped out. Crafting remains at the Alchemybench and is still togglable via config.craftingEnabled (whose in-config description was updated to match the new recipe).

The Network Chest recipe was never affected and is unchanged (3x Ingredient_Life_Essence_Concentrated).

Compatibility

• Recipe/asset-only change. No save-format change; all placed chests and their contents are untouched.
• The plugin's 21 compiled classes are unchanged apart from the one updated config-comment string; no behaviour changes beyond the recipe.

v5.0.0 (2026-05-23)

Single-issue release fixing a Windows-specific Network Chest persistence bug reported by BottenRastrd on 2026-05-23.

Network Chests are now persisted on Windows hosts

BottenRastrd reported that under v4 on his (Windows) installation:

"I place a network chest (or multiple chests) and they work as intended. If I save the game, return to the main menu, and reload the game the chest cannot be opened. Additionally, if you break the chest (which shouldn't be possible if it has items inside), it disappears and doesn't go into your inventory. There are no JSON files being written at all in the 'network' folder. I also tried using the regular mega chest and everything seems to be working as intended."

Three symptoms, one root cause.

Root cause. Network pools were keyed by id "net:" + ownerUuid and that id was used directly as the on-disk filename (plugins/GlymeraMegaChest/network/net:<owner-uuid>.json). The colon is legal on Linux/ext4 — so every internal test passed against the Linux dev server — but on NTFS the colon is reserved for alternate data streams. FileOutputStream of net:<uuid>.json.tmp raises IOException on Windows, which saveChest catches and silently returns from. Nothing ever made it to disk. Because the in-memory chests map still held the pool until restart, the chest looked fine until the player quit; on the next load, no JSON to read → no entry in posToChest → MegaChestUseBlockSystem returned without opening the plugin UI, and MegaChestBreakBlockSystem + MegaChestDamageBlockSystem no longer matched the block, so vanilla Hytale break handling kicked in with "DropList": "Empty" — block and contents vanished without a trace. Standard Mega Chests were unaffected because their id is a plain UUID.randomUUID().toString() with no colon.

Fix. Pool id prefix changed from "net:" to "net_" (single character, single source-of-truth constant NETWORK_ID_PREFIX). The underscore is legal on every filesystem the plugin can plausibly run on. saveChest, deleteChestFile, and loadChests all derive the filename from c.id so no other code-paths needed changes.

Migration. Linux servers that ran v3 or v4 already have net:<uuid>.json files on disk. loadChests now detects the legacy prefix at startup, rewrites c.id in memory, and atomically renames the file to net_<uuid>.json (via Files.move). The rename is one-shot and idempotent; once renamed, subsequent loads see only the new prefix and no work is done. If the rename fails (e.g. permission denied), the in-memory id is still corrected and the next saveChest writes a fresh file under the new name. Customers on Windows had no v4 network files at all (the bug we are fixing), so there is nothing to migrate there.

Verified on the Linux dev server: the two pre-existing net:<uuid>.json files were renamed cleanly to net_<uuid>.json on first start, all in-world Network Chests remain openable, and the bug-trigger sequence (place → quit → reload) is exercisable by anyone wanting to repro on Windows.

Compatibility

• v4 data on Linux migrates automatically on first start. No manual file rename required.
• v4 data on Windows is empty by definition — nothing to migrate.
• No save-format change beyond the id-prefix swap. The chest contents (items, positions, etc.) are byte-identical.
• All in-world placed chests and the per-owner network pool are entirely preserved.

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).