Backends and versions
How one API runs on Minecraft 1.7.10 to 26.3 - per-version backends, how the library picks one at startup, and what that means for your mod.
Your mod compiles against one API. The library's jars contain a backend per GUI era of Minecraft, and at startup the library picks the one for the running game. You never call a backend.
How it works#
-
One jar per loader family. Each release jar bundles the runtime, the API and every backend for its loader and version range.
-
Detection. When the game starts, the library detects the loader and the Minecraft version.
-
Selection. Exactly one backend covers each supported version, and the library logs which one it picked:
[Xi's Multiversion UI Lib] UI backend <backend> for <loader> <version> -
Drawing. When a player opens a menu, the backend maps each widget to that version's own vanilla widget: a
Togglebecomes the version's option button, aSliderits slider, and so on. That's why menus look native on every version, and why the API describes widgets rather than drawing.
Where a version has no vanilla equivalent, the backend draws one that looks like it: Checkbox uses vanilla's
check box from 1.16 and an equivalent drawing before that, and MultiLineInput uses vanilla's multi-line edit
box from 1.19.3 and an equivalent box before that.
No popups#
Every backend can draw a list of entries, so composite widgets are built from entries. A Dropdown opens a
picker screen, and a ColorPicker opens an editor screen. There are no floating popups on any version.
When there is no backend#
The library never makes the game fail to start. With no backend for the running game, register still works,
the menus are recorded, and nothing is shown. That happens:
| Situation | Log |
|---|---|
| a loader and version combination outside the supported range | No UI backend for … |
| a Minecraft version newer than the library knows | Minecraft version unknown: … |
| a dedicated server | nothing: servers never select a backend |
-Dxis_mvui.disable=true |
Disabled by -Dxis_mvui.disable=true: … |
| unit tests with only the API jar | nothing: there is no runtime at all |
What this means for your mod#
- Compile once. Your menu code is the same source and the same bytecode for every version.
- New Minecraft versions are the library's job: a new version needs a library release, not changes to your menu.
- Backend classes in the API (
UiBackend,BackendRegistry,BackendDescriptor,UiPlatform,EntryVisitor,MenuWorkers,TextAreaModel,ForcedFailure) are the contract between the API and the library's own backends. Mods don't need them. - Public methods on widgets such as
Toggle.setorSlider.setPositionexist so backends and tests can drive widgets. Your mod normally only uses the builders.
Next steps#
- Build one mod for every loader: the same idea applied to your own mod.
- Failure isolation: what happens when a backend fails.