SableCraft Standards

Added

• api/panels — who draws on the inventory screen. Four things wanted that left margin — vanilla's recipe book, LegendQuest's two panes and Factions' panel — and none of them could see each other. There is no free space to guess at: vanilla's potion effects render at leftPos + imageWidth + 2, and JEI's tooltips fire underneath anything drawn there. So a mod says what it wants to draw and Standards says where, one pane at a time, sliding the inventory across the way the recipe book already does.

  The occlusion check is one comparison and no reflection: an inventory that is off centre means somebody else took the left, which catches LegendQuest whether or not it has heard of the seam.

  Held for LegendQuest to adopt before release, because a pane written by whoever designed the API demonstrates it rather than proves it. That review returned four gaps, two questions and a correction — themeable frames, content-driven height, a release that a pane can claim, and a warning that a consumer's own click hook can silently disable the host's.

• The build stamp. Every jar records the commit, branch, time and Minecraft line it was built from, and the server logs it on start. Version equality is not build equality: between two bumps a version number names many different builds, and a stale jar reporting the right version is indistinguishable from a fresh one without this.

• Right-click a button for a row of children, and categories — a button that holds others and does nothing itself.

  /home left-clicks home and right-clicks to a button per home. Warps are a category: there is no sensible default warp, so the whole button is the list. An action declares its children as a server-side function, so the client draws what it is told rather than deriving commands — the same rule the action list itself follows.

  Right rather than left for the expansion, because left must keep running the command: a /home button that stopped going home the day it gained a list of homes would be a regression dressed as a feature. A button with children wears a corner mark and says so in its tooltip, since nobody guesses at right-click on a button that already does something.

  One expansion open at a time — several would be a tree drawn sideways, and the bar's value is being readable at a glance.

• A bare /home with exactly one home goes there, whatever it is called, and when it cannot guess it offers the list as clickable buttons. Found by a player who owned homes named one, two and three, watched /home refuse all of them, and set a fourth called "home" to work around it. Server-side, so it helps people typing rather than only people clicking.

• The drawn bar, keybinds, and ClientActions.run. A column of buttons down the left of the inventory — left because the right belongs to JEI in nearly every modpack — drawn from whatever the server said this player may do, lit when a switch is on, with a hint under the icon.

  Keybinds for the same actions, unbound by default, because a mod claiming keys on install is how conflicts start. Each mod registers its own the ordinary way — a KeyMapping must exist at client startup, before anything knows which server it is talking to, so the seam cannot conjure one — and calls ClientActions.run(id), which is where the availability check lives so a key and a button cannot disagree about whether an action is on offer.

  All of it behind a Dist.CLIENT entrypoint, so a dedicated server never loads a rendering class. With the whole client half absent, every command still works.

• api/actions — the seam other mods put buttons on, and /actions, which is that bar for a client that has no bar.

  An action, not a button, because a button and a keybind are two triggers for one thing. Registered once in common setup: the server reads the availability predicate, the client reads the icon. Additive like the chat decorators — several mods contribute without contradicting — and ordered by the same rule, priority as closeness to the anchor.

  An action runs a command. There is deliberately no serverbound payload anywhere in the seam, so permissions, cooldowns, warmups, config switches and logging all already work with no second code path to drift. It follows that an action must be something a vanilla player could type.

  /actions makes it work on a vanilla client. Chat click events are plain vanilla components, so a row of [Fly] [God] [Home] in chat is a working set of buttons with no mod at all — lit when a switch is on, dim when off. Asked for by a gamemaster mod whose rule is that only the server and the operator need anything installed, and the honest answer turned out to be yes.

  Actions carry state, not just availability: the bar says what you are, not only what you may do. That is worth more than another button in a tool where half the bugs are the game and the operator disagreeing about whether you are hidden.

• The optional client channel carries its first payload — a clientbound what may I do set, so a modded client can draw buttons for the commands a player actually has. Server-side only so far; the buttons themselves come next. A vanilla client never receives it and loses nothing.

  Guarded twice, because this is the failure that kicks vanilla players at login and it has bitten two sibling mods already: every send goes through Net.sendIfAble, and the registration is a single chained expression because optional() returns a clone — assigning the registrar and calling optional() on it separately silently registers a required channel.

  It says what to draw, never what is allowed. The server re-checks on the command, so a stale set gets you a button that fails, which is what typing the command would have got you.

Fixed

• A pane could not claim a mouse release, so a drop target lost the item. mouseReleased returned void; vanilla reads a release outside the inventory's own bounds with an item on the cursor as throw it on the floor, and a pane is outside those bounds by construction. Carrying an item to LegendQuest's spellbook slot dropped it on the ground. The signature is boolean now.

  ⚠ A consumer compiled against the old signature does not fail loudly — it silently stops overriding, and the default runs instead.

• /rank reported the default group as granted when it was merely the default, and a long name sprawled over its icon on the action bar.

• A group provider handed a null player logged an ERROR on every self-test run. Behaviour was always right — the seam treats a throwing provider as ungrouped — but a healthy run that shouts is a log people learn to ignore. Two providers needed the guard, and the second was only found by reading the log after fixing the first.

• gradlew was committed non-executable, so a fresh clone on Linux could not build. /mnt/d is drvfs and cannot represent the mode, which is why nothing noticed for months.

Changed

• {term.prefix} now means "the prefix of whichever mod owns this line". Factions contributes eighty-odd messages through Lang.contribute and every one of them opened with it, so a faction claiming a chunk announced itself as [Standards]. A mod gets its own identity by declaring term.<modid>.prefix and nothing else. Resolved at render time rather than by rewriting the defaults, because messages.yml is merged rather than overwritten — editing the defaults would have fixed a fresh install and left every existing one unchanged.

• iconFile and bannerFile for 26.2's reshaped mod list, alongside logoFile for older loaders. Without them the row has no icon at all.