GlymeraHUD — Changelog

v5.0.0 (2026-09-01) — Fixed positions: corners and edge centers

Why this version exists

Until now GlymeraHUD could only shift a HUD by a number of pixels from wherever its author anchored it. That shift is measured in absolute pixels, so the result depends on each player's screen resolution and UI scale: a window pushed 1,600 px to the right sits perfectly on a 2560-wide screen, is cut off on a 1920-wide one, and is off-screen entirely on a laptop. One operator, three players, three different layouts.

What changed

• New: 8 fixed positions per HUD — the four corners (Top Left, Top Right, Bottom Left, Bottom Right) and the four edge centers (Top Center, Bottom Center, Middle Left, Middle Right). Pick one in /ghud and the HUD is re-anchored to that edge, so it lands in the same spot on every screen size and UI scale.
• Sliders become a gap. With a fixed position selected, the two sliders set the distance from the chosen edge(s) instead of a raw pixel shift. On a centered axis the slider is ignored (the page shows (centered)).
• "Original" keeps the old behaviour. The middle button of the grid leaves the HUD on its own anchor and applies the sliders as a pixel shift, exactly as in 3.x/4.x.
• Switching between Original and a fixed position resets the sliders (to 20/20 or 0/0), so an old large shift does not turn into an equally large gap.
• File-based HUDs (loaded from a .ui asset) now also accept stretched anchors (Horizontal/Vertical) when a fixed position is chosen; a plain shift on such an anchor is still left untouched, as before.

Compatibility / upgrade

• Drop-in replacement. Swap the jar and keep the plugin's data folder. Existing offsets.txt entries load unchanged and behave exactly as before (they are treated as Original + shift); the file is only extended with a position column once you pick a fixed position for a HUD. Verified against a real customer configuration.
• All positions persist across server restarts, as before.
• Built and verified against Hytale 0.6.x; server-side only, no client changes. Verified in-game for all eight positions.
• Recommendation: HUDs you previously pushed a long way with the sliders — open /ghud, pick the corner you actually wanted, and set a small gap. That fixes the "looks different for every player" problem.

v4.0.0 (2026-08-28) — Hytale 0.6.0 (Update 6)

• Rebuilt for Hytale 0.6.0 (Update 6). Requires server 0.6.0 or newer; this version does not run on 0.5.x, and older versions of this plugin do not run on 0.6.0.
• Known 0.6.0 limitation: the client hides all custom HUDs while a custom page (such as the settings GUI) is open, so the live preview of the sliders is not visible while adjusting them. The settings are applied normally once the page is closed.
• Migrated to the 0.6.0 APIs (network protocol hytale/3, new command-permission API, block/chunk/entity API changes). Everything that was open to players before is open to players again.
• Upgrade: delete the old jar from mods/, drop in the new one and keep the plugin's data folder — configs and saved data carry over unchanged. Restart the server.

3.0.0

Complete rewrite. GlymeraHUD is now a HUD positioning tool.

Why this version exists

Earlier versions of GlymeraHUD existed to solve one problem: older Hytale only showed a single custom HUD at a time, so two HUD plugins would overwrite each other. v1/v2 worked around this by intercepting every outgoing HUD packet, guessing which plugin sent it, rewriting its UI commands into a private master container, and blocking the originals.

Two things changed:

1. Hytale now multiplexes HUDs natively. The engine keeps all custom HUDs side by side (keyed per HUD), so the merging workaround became unnecessary.
2. The workaround caused disconnects. Because it rewrote each HUD's UI selectors into a container it managed itself, the client could receive commands pointing at an element that didn't exist, producing a failed to apply customhud ui commands error and kicking the player. This was reported by a customer running the latest game version with multiple HUD mods.

What changed

• Removed all packet merging, stack-trace source-guessing, the private master container, and reflection-based command injection — i.e. everything that caused the kick. The kick is structurally impossible in this version.
• Kept and rebuilt the positioning feature as the plugin's sole purpose.
• HUDs are now identified by their own packet key, not by guessing the source plugin from the call stack.

How positioning works now

GlymeraHUD observes outgoing HUD packets and, if an offset is configured for that HUD, adjusts only the numeric anchor values of the HUD's own root element. It never adds selectors or containers of its own, so it cannot create an unresolvable reference.

Two HUD construction styles are supported:

• Inline HUDs (the HUD layout is in the packet): the anchor values are shifted directly in place.
• File-based HUDs (the HUD is loaded from a .ui asset, e.g. WiFlowScoreboard): GlymeraHUD reads the referenced asset from the mods/ jars, learns the root element id and its original anchor (cached), and appends a single Set <root>.Anchor command to the same packet — targeting an element that packet itself just created, so it always resolves.

If a HUD's asset can't be found, its root can't be determined unambiguously, or it uses anchor properties that can't be safely rebuilt, GlymeraHUD leaves the packet untouched rather than risk breaking it.

Live preview

Changing a slider in /ghud now re-triggers the selected HUD via the engine's public show() method, so it re-sends and repositions immediately while you drag. This matters for HUDs that are sent once and then only text-updated (such as a money/balance display), which previously only moved after a reconnect. The re-trigger is best-effort and fault-isolated: if it ever fails, the offset is still saved and applies on the next refresh — it can never cause a kick or crash.

Compatibility

• Built and verified against the current Hytale stable release.
• Server-side only; no client changes.