UiCore

Official compatibility

Element	Reference
TypeWriter	Required. Use the official TypeWriter release supported by the extension release.
CraftEngine	Required. It hosts the resource pack that carries the fonts and the shader.
Related extensions	GUIExtension is optional. When present, UiCore reads the menu states it publishes so one declaration serves both channels.

The UiCore Extension draws menus, HUD modules and dialogue in GUI space: on a 15 × 15 grid placed by a shader, from coordinates the shader computes itself.

That is the whole point. A chest menu is laid out by the client, so it moves with the player's GUI scale; text placed by hand moves with their field of view and their aspect ratio. A screen drawn in GUI space is identical for every player, whatever their settings — and it can sit anywhere, not only where an inventory happens to open.

UiCore replaces two extensions that are no longer maintained: AdvancedMenus and BetterHud.

What it renders

• Views — full screens with panels, buttons, lists, tabs and sub-screens. Opened by an item, a command or an action.
• HUD modules — permanent elements anchored to a corner of the screen, suspended automatically while the player is reading anything else.
• Dialogue — spoken lines and lines with choices, answered with the cursor, drawn in the same grid and styled by one shared style entry.
• Cinematic dialogue — the same spoken line, on a cinematic timeline.
• A minimap and a full-screen world map, with points of interest and waypoints.

How a screen is put together

A view is a stack of layers, and a layer holds components. A component says where it sits (a cell of the grid), what it is painted with (a flat tint from the palette, or a panel image), what it says, and what a click on it triggers.

view
└── layer
    └── component  ─ placement (column, row, width, height)
                   ─ palette / background
                   ─ text, icon, tooltip
                   ─ criteria, onLeftClick, onRightClick

Three things are worth knowing before authoring one:

A tint is an index, not a colour. A cell's glyph carries its column, its row and its tint in a single colour value, so the palette is a fixed list of named tints rather than a free hex value. See ui_view for the list.

A picture costs nothing extra. A component can be painted with a panel image instead of a flat tint. Any number of images share one font, so adding images never eats into the shader's budget — what is scarce is fonts, not textures.

Text cannot be recoloured freely. A text glyph's colour is already spent on its position and its width, so its tint comes from its font, and the pack ships sixteen text fonts. Asking for a seventeenth tint falls back to white rather than drawing in the wrong place.

The cursor

A view is aimed with the head. The player's yaw and pitch are projected onto the grid, snapped to a cell, and the cell under the cursor is highlighted; a left or right click takes it.

There is no client mod involved: rotation is the only input a vanilla client sends continuously, and it is what the cursor rides on. While a view is open the player is held in place and the chat is suppressed, so nothing writes over the screen.

States

A view can declare states: named conditions under which some of its components look different. A state can change a tint, a text, a tooltip, an icon or a panel, and it can hide a component entirely.

• Exactly one state is active — the highest-priority one whose conditions hold.
• A state may refine another and inherit, field by field, everything it does not restate.
• A component is addressed by its id, or by column:row to address the cell it sits on — which is how a state written for a chest menu applies here unchanged.

States are re-evaluated on every repaint, so a view reflects the world while it is open.

Arrival animations

A view can arrive rather than simply appear: a wipe from any edge, or an outward bloom from the middle. Cells can also fade up from transparent instead of appearing at once.

Two limits are worth stating, because they come from the encoding and not from the implementation:

• Nothing slides. A cell's address is a whole number of columns and rows, so an animation reveals cells in an order — it does not glide them.
• Text does not fade. Its tint comes from its font, and fading would multiply the fonts past the budget. A line of text arrives with its panel instead.

The animation plays only when entering the interface, never from one screen to the next: moving between tabs or opening a second menu from a button shows no animation.

Sharing declarations with the chest renderer

When GUIExtension is installed, UiCore reads the states it publishes for the same menu id, so an extension declares a state once and both renderers honour it. What cannot be translated — a texture override, a geometry change — is reported in the log rather than approximated.

Resource pack

Everything the renderer needs is generated: the shader, the fonts, the palette, the panel images and the item sprites. The pack fragment is produced by the extension's own tooling and merged into the CraftEngine pack; no manual editing of a resource pack is required.

[!NOTE] Resource paths are strict. A Minecraft resource identifier accepts only [a-z0-9._-/]. A font provider whose path contains anything else is rejected by the client, silently — the glyph falls back to the default font, loses the ascent that places it, and appears as a black rectangle at the top of the screen. The generator refuses to write a font containing such a path.