KubeUI

Nothing has actually shipped since v0.3.0 - everything below landed as one continuous, still-unreleased development cycle, so it's kept as a single 0.4.0 entry instead of a new version number for every batch of work.

Combat & status HUD: KubeUIActions.showBossBar(viewers, barId, name, health, maxHealth, phases) draws a fully custom boss bar, top-center - phases is a list of {threshold, color, text} objects, so a fight's bar can change color/subtitle as health crosses a threshold, something vanilla's own boss bar has no concept of. KubeUIActions.defineStatus(id, name, icon)/.applyStatus(...) add purely scriptable statuses on top of real vanilla MobEffects in one unified buff/debuff overlay - a status here has no built-in behavior of its own, its entire "tick logic" lives in a script's own KubeUICombatEvents.statusTick(event => {...}) handler. KubeUIActions.startCooldown(player, id, durationTicks) gives a script-defined cooldown (not tied to a real item, unlike vanilla's own Player#getCooldowns()) a real HUD bar above the hotbar. A combat-log HUD (toggleable per player, KubeUIActions.setCombatLogEnabled(...)) and an AOE/range indicator ring (KubeUIActions.showAoeIndicator(player, radius, color)) round out the overlays. Every real hit is tracked automatically off LivingDamageEvent.Post into a per-player "combat session" - once a player goes a few seconds without landing or taking a hit, KubeUICombatEvents.combatEnded fires with the session's damage dealt/taken and duration for a script's own post-fight recap, and KubeUIActions.combatHistory(player) reports every tracked session back.

Structures & dungeons: KubeUIActions.lootTableBrowser(player, lootTableId) previews a real vanilla LootTable's probable contents - genuinely rolled 200 times and tallied (a loot pool's internal weights aren't generically readable, and plenty of entries are conditional on context a preview doesn't have), always presented as "probable", never a guaranteed drop list. KubeUIActions.defineStructure(id, name, difficulty, ...) declares a scriptable info zone - opt-in per player, a toast on approach. KubeUIActions.defineDungeon(id, name, roomIds) tracks room/chest/ boss progress per player, with real progression locking (a room only unlocks once the previous one in the list has actually been visited) and an automatic completion-time leaderboard the moment every room's visited and the boss goes down. KubeUIActions.defineLootTable(id, entries)/.rollLoot(id, difficultyMultiplier) add a scriptable weighted-random loot table independent of vanilla's own (a higher multiplier skews the odds toward rare entries, without hand-authoring a second table per difficulty tier) - KubeUIActions.startLootVote(...)/.castLootVote(...) add real server-arbitrated need/greed group loot voting on top of it (need always beats greed, ties broken randomly within the winning group), the voting screen itself left to a script via the same generic server-push mechanism every other custom screen in this mod already uses.

Economy: a scriptable, server-authoritative currency system independent of any physical item - KubeUIActions.registerCurrency(id), .pay(player, currency, amount)/.charge(...) for atomic credit/debit that never leaves a silent negative balance, .transferCurrency(from, to, currency, amount) with a configurable commission (.setCurrencyTransferTax(...)), and .exchangeItemForCurrency(...)/.exchangeCurrencyForItem(...) to bridge it with real inventory items. KubeUIActions.defineShop(shopId, name, stock) builds a full vendor - buy/sell, per-line stock limits, and optional price fluctuation (a bounded random walk on a configurable interval) - opened with KubeUI.shop(shopId). KubeUI.currencyHistory(currency) shows a player's own transaction log, KubeUI.leaderboard(currency) the richest players server-wide (built on the existing sortable table widget), and the new KubeUIEconomyEvents.transaction/.balanceChanged event group (KubeUI's first server_scripts event group) lets a script react to every balance change. Every shop in the project (including the "real"/emerald and "validated" reference demos) now runs on this same currency instead of ad-hoc raw-item or in-memory gold tracking, so balances actually persist across restarts everywhere. The real /money balance [currency]/pay/deposit/ withdraw command (deposit/withdraw need OP) gives players and admins chat access to the same system without needing a script, and ServerEvents.commandRegistry (KubeJS's own real command event - see kubeui_admin_commands_example.js) is the documented way to add further custom admin commands on top of KubeUIActions.pay/.charge without touching Java at all. Fixed a real bug where a singleplayer world's registered currencies could disappear (/money balance reporting "no currencies registered" even with a KubeUIActions.registerCurrency(...) script loaded): on an integrated server, server_scripts run before ServerAboutToStartEvent, and the currency ledger's own startup load was unconditionally clearing the in-memory registry that scripts had just populated.

Machines & automation: KubeUIActions.defineMachine(kind, name, inputItem, inputCount, outputItem, outputCount, processTicks, energyPerTick, redstoneMode) declares a recipe kind for the one real, placeable kubeui:machine block (NeoForge's registries are frozen long before any server_scripts reload runs, so a script can't register a genuinely separate block per kind the way it can define one server-side) - KubeUIActions.giveMachineItem(player, kind) hands out a copy already set to that kind, with the kind's own real display name stamped onto the item itself (DataComponents.CUSTOM_NAME) so a Crusher and a Smelter already read as two different things in the inventory/hotbar tooltip, not just after placing one and opening its screen - also now logs a clear warning if a script calls this before defineMachine ever registered that kind, the real cause behind a placed machine silently showing a generic name and a "No recipe" status. A machine has four real slots (input/output/upgrade/fuel), ticks its recipe while it has enough input and (if energyPerTick > 0) enough energy, and respects redstoneMode ("ignore"/"requireSignal"/"disableOnSignal"). Energy comes from a real fuel slot burning the same vanilla-furnace fuel table (level.fuelValues()) any real furnace does - coal, charcoal, a lava bucket, planks, and everything else vanilla or another mod registers as fuel all work, including the real "empty bucket left behind" behavior - or from KubeUIActions.chargeMachine(level, pos, amount), the real integration point for a future energy- mod bridge. KubeUIActions.registerMachineUpgrade(itemId, speedMultiplier, yieldBonus) lets an item dropped in the upgrade slot speed up processing and add bonus output. .linkMachineOutput(level, from, to) chains one machine's output straight into another's input, and .setMachineNetwork(...) groups machines for KubeUI.machineNetworkStatus(networkId)'s aggregated controller/stats view. The machine screen lays the four slots out the same recognizable input-above-fuel-with-a-flame-between- them, output-off-to-the-side-via-an-arrow shape a furnace-like screen always has, shows full slot names, a live crafted-count, a small hand-drawn flame that lights up while fuel is actually burning, a compact energy gauge, and the machine's real per-kind name in its title bar - all drawn as a themed custom panel (matching every other KubeUI screen's colors) instead of a reused, mismatched vanilla furnace sprite. A short status line ("No recipe" / "Blocked" / "No input" / "Needs fuel" / "Output full" / "Running...") next to the crafted-count now says outright why a machine isn't processing right now, instead of a player only ever finding out from a chat alert throttled to once per 30 seconds. A block placed with no kind (or an unregistered one) - the real cause of "No recipe" for anyone who only ever finds a generic, unconfigured kubeui:machine (creative inventory, /give, ...) rather than one already given via giveMachineItem - now shows a real in-GUI picker instead: every registered kind's real icon and name, synced the same way a trade screen's own offer list already is, click one to become that kind on the spot. Fixed two real reported bugs along the way: the screen's drawn slot frames and the menu's actual item slots had drifted to different coordinates (putting every item and label in the wrong spot), and the energy gauge was an oversized, disconnected bar with nothing tying it to the fuel slot feeding it.

World map: KubeUI.worldMap() opens a full-screen, pannable (drag or arrow keys)/zoomable (scroll wheel) map built on the same real per-block color sampling as the existing HUD minimap widget (.map(id, radius)), backed by a persisted, progressively-revealed explored-cell cache - areas you haven't actually visited stay blank rather than faked. KubeUIMapIcons.registerIconProvider(...) lets other systems plot colored live-entity markers on it (KubeUI.registerMapIcon(entityTypeId, color) covers the common case). Waypoints (/kubeui map waypoints, or "Add Waypoint Here" on the map itself) persist across sessions and can be shared to another player over the network. The screen is now styled like a familiar minimap-mod layout: a docked top toolbar, a docked waypoint sidebar (jump-to and remove per entry, no command needed), a bordered viewport with a compass tick and a scale bar, and a live coordinate/biome/zoom readout under the cursor. Each sidebar entry also has a "Trk" toggle - like Journeymap's own per-waypoint "show on HUD" option, it keeps that waypoint's direction/distance visible top-center of the screen even with the map closed (fixed a real gap where the HUD indicator itself already existed but nothing ever let a player actually enable it for a waypoint).

Dialogue: KubeUIActions.defineDialogue(id, rootNodeId, nodes) declares a branching NPC conversation - portrait (auto-detected as an entity type or an item), typewriter-revealed text, an optional per-node timer that falls through to a default choice, and per-choice requires gates checked against real player state (quest progress, currency balance, inventory) - a choice that fails its gate is simply never sent to the client, never shown disabled. Opened with KubeUI.dialogue(dialogueId, npcUuid), or automatically by right-clicking an entity tagged via KubeUIActions.tagDialogueNpc(entity, dialogueId)//kubeui tag-dialogue-npc. KubeUIActions.dialogueHistory(player, dialogueId) reports every node a player has actually reached, persisted across restarts, so an NPC can remember a past conversation.

Storage: kubeui:storage_crate - KubeUI's first real, placeable block, backed by a genuine server-side container (not a client-side simulation). Right-clicking one opens a real chest-style screen with a sort button (name/count/category), a live search field that dims non-matching slots, and a settings panel for item whitelist/blacklist filters, owner-managed player authorization (lock the crate to specific players), and linking it into a named network - KubeUI.storageNetworkView(networkId) shows the combined contents of every currently-loaded crate on that network from anywhere, without opening any of them physically. Every deposit/withdrawal is logged (KubeUI.storageHistory()). kubeui:backpack is a wearable-inventory item with its own 18-slot container that survives death and changing hands correctly, since it's backed by the same real item-container data a shulker box uses.

Progression: KubeUIActions.defineSkillTree(id, nodes, options) builds a real talent tree - node prerequisites, a point cost per node, and real vanilla AttributeModifier effects (not just a visual unlock) applied the moment a node is bought. Points come from leveling up (pointsPerLevel), or from anywhere a script wants via KubeUIActions.grantSkillPoints(...) (a quest reward, for instance). classGroup on a node lets a tree define mutually-exclusive specializations - unlocking the first node of a group commits the player to it until they respec (KubeUI.skillTree(id)'s Respec button, KubeUIActions.respecSkillTree(...), optionally priced in any currency from the new economy system). A permanent level/XP bar now sits at the bottom of the HUD, the skill tree screen shows a title badge for how many nodes a player has unlocked, and KubeUI.skillLeaderboard(id) ranks currently-online players by total points earned.

Guilds & factions: KubeUIActions.createGuild(founder, guildId, name) builds a real, disk-persisted guild - a fixed owner/officer/member role hierarchy checked server-side on every management action (.inviteToGuild/.kickFromGuild/.setGuildRole), a dedicated guild chat channel (.sendGuildChat), collective XP/leveling with a leaderboard (.addGuildXp/.guildLevel/.guildLeaderboard), a scriptable relationship between two guilds (.setGuildRelation, "ally"/"rival"/"neutral"), a scriptable claimed territory with an entry toast for non-members (.claimGuildTerritory), and a badge (color + icon, resolved the same way a skill node's own icon is) a script can show wherever it wants. .authorizeGuildOnStorage(...) bulk-authorizes every current guild member on an existing storage crate, reusing its real per-player authorization list rather than a second access-control system. KubeUIGuildScriptEvents.scheduledEventTriggered(event => {...}) fires once a KubeUIActions.scheduleGuildEvent(...) timer elapses, for a script to distribute rewards through the existing quest-reward system.

Social: a persistent per-player friends list (KubeUIActions.friendsList/.addFriend), stored directly on the player's own real persistent data rather than a second registry. A temporary, session-only party system (.createParty/.inviteToParty) with optional XP/loot-sharing flags a script consults at the real moment it would grant either. A /kubeui tpa-style teleport request that actually needs the target to accept (.requestTeleport/.acceptTeleport, a real pending request that expires after a minute) instead of moving a player with no warning. Live presence (.presenceOf, "online"/"in_combat" computed for real off the existing combat-session tracker/a script-set custom status). Party and real proximity ("local") chat (.sendPartyChat/.sendLocalChat) alongside guild and vanilla global chat, with a tabbed channel switcher in the reference demo. A purely client-side, never-shared block/mute list (KubeUI.blockPlayer/.isPlayerBlocked) and private contact notes (.setContactNote/ .contactNote), both using the same local, compressed-NBT persistence waypoints already established. Opt-in friend-login toasts (KubeUIActions.setFriendActivityNotifications), and an emote wheel built from a real circular button layout (.absolute(x, y)`, already delivered) broadcasting through the same real proximity chat rather than a dedicated new widget.

Housing & claims: KubeUIActions.claimLand(owner, claimId, x1,y1,z1,x2,y2,z2, dimension) claims a real, disk-persisted bounding box for one player - the same real shape guild territory already has, plus real per-claim members and arbitrary scriptable action permissions (.addClaimMember/.setClaimPermission/.claimPermissionAllowed), temporary revocable visitor access (.inviteClaimVisit/.revokeClaimVisit), and paid rentals through the existing currency system with automatic real-time expiration (.rentClaim). .mergeClaims/.splitClaim combine or divide claims (a real, deliberately simple bounding-box merge and an axis/coordinate split, not a strict-adjacency system). An unauthorized entrant triggers a real toast to the owner (.setClaimLimits caps how many/how large a player's claims can be). KubeUIActions.setHome(...)/ .teleportHome(...) add named personal spawn points beyond vanilla's single bed, stored directly on the player's own persistent data. A real /claims command lists a player's own claims, and /home set/.remove/.list/.tp (the last with a real cooldown) give chat access to homes alongside the existing GUI - see "Real slash commands, JS-only" below.

Settings hub: KubeUISettingsHub (a new client-only global, same real "public standalone class" shape KubeUISidebar already established) lets any mod - including third-party ones with no hard dependency on KubeUI - register a settings section (.register(modId, name, section => {...}, declaredDefaults)). .matching(query) backs a searchable hub screen; .conflicts() flags two sections that declared different default values for the same settings key. Named profiles (.setActiveProfile/.setValue/.getValue) store real profile -> scope -> key -> value data - a scope the caller chooses itself ("global" or a server address it picked), so per-server-vs- global behavior is possible without KubeUI needing to infer "which server" on its own - .exportProfile/.importProfile share one as portable JSON, the same real mechanism /kubeui export/import already established. .showOnboardingOnce(id, () => {...}) shows a wizard exactly once per install. KubeUIActions.serverDashboard(player) gives operators a real snapshot of every major KubeUI system active on the server (currencies, guilds, claims, dungeons, quests, online players) - empty for anyone without real operator permissions.

Machine screen fixes & redesign: fixed a real bug where an already-kinded machine (e.g. "Crusher") could show the kind picker again instead of its normal panel - the picker's status code used to double as "kind not chosen yet" and "kind chosen but its recipe items don't currently resolve", so the second case silently reopened the picker on an already-configured machine. The two are now distinct statuses; an invalid kind shows a plain error instead of quietly asking to pick again. The whole screen (and the kind picker) got a real visual pass - gradient panel/bars, bevelled inset slots, and full-width chamfered picker cards with hover highlighting, all still drawn from GuiGraphicsExtractor primitives, no texture asset. The boss bar HUD is noticeably shorter (thinner bar, tighter spacing).

Real slash commands, JS-only: guild naming (/guild create/.rename/.invite/.kick/ .info), party management (/party create/.invite/.leave/.list), and the housing commands above - all built entirely with KubeJS's own ServerEvents.commandRegistry in testkubejs/server_scripts/kubeui_guild_party_housing_commands.js, not new Java command classes, on top of a handful of small additive KubeUIActions methods (.renameGuild, .guildNameOf, .claimsOf). A guild member's tag now also shows automatically in regular chat (not just the dedicated guild channel), via a real chat-decoration hook (KubeUIChatEvents).

Tabbed social screen: /social opens a Général/Teams/Party screen built from KubeUISocialHub (a new client-only global, same "public standalone class" shape KubeUISidebar/ KubeUISettingsHub already established) - .registerTab(id, label, order, tab => {...}) lets any script add its own tab alongside the three defaults, with no Java change needed either way.

Custom leaderboards: KubeUIActions.setLeaderboardScore(boardId, player, score) / .leaderboardTop(boardId, limit) / .leaderboardScoreOf / .removeLeaderboardScore / .clearLeaderboard / .leaderboardIds - a general-purpose, disk-persisted score store a script can build any leaderboard on top of (a minigame, a farm total, anything), alongside the already-specific .guildLeaderboard/.dungeonLeaderboard.

Guild/party/housing GUIs: bare /guild, /party, /home and /claims (no subcommand) now open a real screen instead of chat-only output - create/rename a guild and invite/kick members, manage a party, set/remove/teleport-to homes (and see the claims list), all from testkubejs/client_scripts/kubeui_default_screens.js. Any of the four (kubeui:guild_hub/kubeui:party_hub/kubeui:home_hub/kubeui:claims_hub) can be replaced by a pack's own screen with nothing more than KubeUIRemoteScreens.register(sameId, yourOwnHandler) in a script that loads afterward - registering the same id again is a real, already-established override (KubeUIRemoteScreens replaces, not appends), not a new mechanism built just for this.

Guild/party rules are now scriptable, not fixed: the guild tag shown in regular chat used to be hardcoded in Java - it's now a real server_scripts event (KubeUIChatScriptEvents.decorate(event => {...}), event.getMessage()/.setMessage(...)/ .cancel()) that Java only posts; the tag itself is applied by a script listening to it (kubeui_guild_party_housing_commands.js), so changing the format, adding more decorations, or dropping it entirely needs zero Java. The guild role hierarchy (KubeUIActions.setGuildRoles([...]), default ["member", "officer", "owner"]) and which role each action needs (.setGuildActionRequirement("invite"/"kick"/"setRole", role)) are both script-settable now, as is the leveling curve (.setGuildLevelCurve(maxLevel, xpPerLevel)). Party invites are leader-only by default but .setPartyAnyoneCanInvite(true) opens that up, and .setPartyMaxSize(n) caps party size (both unset/unlimited by default, matching the old fixed behavior exactly until a script says otherwise) - "vraiment tout en JS, sans toucher au Java" (real, explicit ask).

KubeUIHud - build your own HUD overlay, not just modal screens: every HUD element in this mod (boss bar, combat log, waypoint tracker, ...) used to be hardcoded Java with zero script control over how it looks - "on peut créer nos propres GUI et UI en JS" for those too (real ask). KubeUIHud.setBar(id, {anchor, x, y, width, height, value, max, barColor, bgColor, borderColor, label, labelColor}) and .setLabel(id, {anchor, x, y, text, color, centered, shadow}) register (or update - call again with the same id) a fully custom bar/label rendered every frame by a new, general KubeUIHudRenderer - .removeBar/.removeLabel/.clear() take them back off. anchor ("topLeft" (default)/ "topCenter"/"topRight"/"bottomLeft"/"bottomCenter"/"bottomRight") resolves fresh every frame against the real current screen size, so a script never has to compute absolute coordinates itself. See kubeui_hud_demo.js for a real, live example (a custom health bar tracking the local player, positioned like a boss bar) - entirely client-side, no server round trip needed.

Full documentation: github.com/Zynora-fr/KubeUI.

Requires KubeJS on NeoForge - see the README's Versions table for the exact Minecraft/NeoForge/KubeJS versions this build targets.