promotional bannermobile promotional banner

GlymeraSlothGuard

Place a Magic Sloth Guard cauldron - three Slothian warriors spawn, patrol the area and attack hostile mobs in a configurable radius. Owner-only block, auto-respawn after restarts, no commands needed.

File Details

GlymeraSlothGuard-5.0.0.jar

  • R
  • Jun 11, 2026
  • 32.00 KB
  • 81
  • 0.5

File Name

GlymeraSlothGuard-5.0.0.jar

Supported Versions

  • 0.5

GlymeraSlothGuard - Changelog

v5.0.0 (2026-06-11)

Fixes the two open CurseForge reports in one release.

Fixed: guards wander off through teleport gates and multiply (reported by Maklin_Deckard 2026-06-10)

"These guys seem drawn to teleport gates. [...] I go through it and find 10-20 of them milling about the gate terminus. [...] I go back to the farm, remove the spawner, it stops spawning... BUT the 10-20 guys milling about my terminus build are still there."

  • Guards are now leashed to their cauldron. A warrior that ends up farther than actionRadius + 5 blocks from its cauldron - for example because it walked through a teleporter gate - is teleported back to the cauldron within a second. Guards can no longer leave their post, no matter what moves them.
  • Guards are no longer persisted by the engine. They are spawned as non-serialized entities: a guard whose chunk unloads simply despawns (and is respawned at the cauldron when needed) instead of piling up as a permanent stray. This removes the root cause of the endless reinforcements: previously, every runaway guard survived forever while the plugin lost track of it and spawned replacements.
  • The stray sweep is now global. Any Slothian-warrior NPC anywhere in any world that is not tracked by an active cauldron is removed (previously only within 30 blocks of a cauldron). Existing worlds are cleaned up automatically after updating - the 10-20 guards at the gate terminus disappear as soon as the area is visited, no manual work needed.
  • Breaking the cauldron now reliably removes all of its guards, including ones that were displaced far away.

Fixed: guards never attack (reported by mindfruit_02247 2026-05-16)

"Do the guards only work in zone 1? I'm in the Savannah and they do not attack any of the 'bad guys' or animals (such as the saber-toothed tiger). [...] another player on our server has them in Zone 1 and they are not fighting any of the hostile mobs there either."

  • Cauldrons are now world-bound. blocks.json stores the world of every cauldron. Previously, after a server restart every cauldron was re-attached to "the world of the first online player" - on servers with more than one world the tracking then pointed at the wrong world, the visible guards became orphans and never received a combat target again. Legacy entries without a world are adopted automatically by the world that actually contains the cauldron.
  • Combat targets are re-asserted every second instead of being set once and assumed to stick. The engine can drop a marked target on chunk or state changes; guards no longer idle next to enemies when that happens.
  • Smarter target selection. A mob is attacked when its attitude toward players is HOSTILE and its role can actually fight. This covers all predators (including the saber-toothed tiger), undead, trorks, goblins, outlanders, scaraks and void creatures - while ignoring birds and fish, which technically report "Hostile" only because that is the engine default for roles without an explicit attitude.
  • attackNeutral=true now targets fight-capable NEUTRAL mobs. Note that in Hytale this bucket includes livestock (cow, horse, goat, ram) and Klops NPCs - that is why it remains false by default.
  • Hard safety exclusions (always active, regardless of config): Tamed_* creatures (player property), ridden mounts, and Glymera plugin NPCs (pets, shop NPCs, ...) are never attacked.

New configuration

  • alwaysAttackRoles / neverAttackRoles: per-role overrides of the default target selection. Exact role names or a trailing * wildcard (e.g. "Scarak_*").
  • debugLogging (default false): prints targeting decisions, leash snaps, spawns and sweep removals to the console for troubleshooting.

Compatibility

  • Existing config.json and blocks.json files are upgraded automatically; no manual steps.
  • Detection ranges ("radius") are now measured as a square (Chebyshev distance), matching how block ranges feel in-game. The effective area grows slightly at the diagonals.

v4.0.0 (2026-05-29)

  • Fix: Eliminated the SEVERE Duplicate asset pack '...' error that appeared on every server boot after the first. The plugin generates its asset pack into mods/ and Hytale's auto-scan already loads it at startup; the plugin then re-registered the same pack via registerPack(), which the engine flagged as a duplicate. The plugin now registers the pack only if it is not already loaded (AssetModule.getAssetPack(name) == null), mirroring the engine's own check. No functional change — assets load exactly as before, just without the log error.
  • Fix: The generated pack manifest now declares "ServerVersion":"*" and is (re)written on every boot, clearing Hytale's "does not specify a target server version" warning (which Hytale states will become a hard error in a future version). Existing installs are upgraded automatically on the next start.

v2.0.0 (2026-05-16)

Bug Fixes

  • Recipe is now actually visible in the Alchemy bench. Reported by mindfruit_02247 2026-05-16 ("I ensured the config is set so that the magic cauldron is craftable but it is not showing in the Alchemy workbench. When I use Better Item Viewer I can see the item but it does not show it as craftable in any workbench even though config is set to true").

Root Cause

  • v1.0.0's runtime-generated recipe JSON used the bench id "Alchemy_Bench" and the category "Alchemy". Vanilla Hytale uses Alchemybench (one word, no underscore) as the actual bench id and Alchemy_Bombs / Alchemy_Potions / Alchemy_Potions_Misc / Alchemy_Seeds as the valid category set. With those wrong ids the recipe JSON was still written into the side asset pack (GlymeraSlothGuardCrafting/) and config.craftingEnabled=true did exactly what it promised — but Hytale silently could not register the recipe against any bench at load time, so it never appeared in any crafting UI. Better Item Viewer correctly reflected that state (item exists, not craftable anywhere).

Changes

  • Recipe BenchRequirement corrected:
    • Bench id Alchemy_BenchAlchemybench
    • Category AlchemyAlchemy_Potions (chosen because it is the largest alchemy category and thematically fits a magical cauldron block; _Bombs / _Seeds did not fit)
  • Recipe now also sets KnowledgeRequired: false, matching how GlymeraMegaChest already shipped it. This means Adventure-mode players can craft the Magic Sloth Guard without first finding a memory crystal to "learn" the recipe.
  • The side asset pack (mods/GlymeraSlothGuardCrafting/) is regenerated on plugin start, so a pre-existing v1 pack with the wrong ids is overwritten automatically. The release deploy also removed the old pack folder for a clean state.

Compatibility

  • No data migration is needed. config.craftingEnabled, recipeEssenceQuantity, the block itself, the warrior NPC role, the 3-layer block protection and all save data are unchanged.

v1.0.0 (2026-04-30)

  • Initial release.
  • Magic Sloth Guard cauldron block (Magic_Sloth_Guard, item id), Cauldron_Big model.
  • Owner-only 3-layer protection (DamageBlock / BreakBlock / UseBlock cancel).
  • On place: 3 Slothian warrior NPCs spawn at the block and attack hostile mobs inside actionRadius=20.
  • Configurable: craftingEnabled, recipeEssenceQuantity, actionRadius, warrior count.
  • Recipe (v1, broken — see v2.0.0): meant to register at the Alchemy bench but wrote Alchemy_Bench / Alchemy instead of Alchemybench / Alchemy_Potions, so it never appeared.