Crate yog_api

Expand description

Yog API — the single crate mod authors depend on.

A facade that re-exports every Yog domain plus the central Registry hub. Add a new domain crate, re-export it here, and mods pick it up via yog_api::*. Items are available both flat (yog_api::Registry) and namespaced by domain (yog_api::world::World).

Re-exports§

pub use java::mod_loaded;
pub use yog_data;
pub use rkyv;
pub use ctor;

Modules§

body: Bodies, camera and movement (yog-body, see its docs): pose and dress entities, disguise and morph them, move the camera, replace the local player’s travel step. Register handlers with Registry::on_body, Registry::on_camera and Registry::on_travel; say which entities to ask about with track and track_type.
book: Guide books: the .ybook format and its renderer.
client: Client-side helpers (ABI minor 1): opening a screen with flags, sounds only the local player hears, the local player’s held items and the keyboard state. All are no-ops (or None/false) on a dedicated server and before the mod registered.
command: Commands.
config: Mod configuration (typed key/value files).
content: Content registration (custom items / blocks / food).
core: Core types and handles.
dimension: Custom dimensions — dimension-type definitions and runtime chunk generation.
entity: Entity access (teleport, position, health, … by UUID).
event: Events and the subscription registry.
gfx_core: Core graphics constants and enumerations.
gfx_draw2d: 2D drawing helpers — thin wrappers over the draw2d_* ABI functions.
gfx_gl: Low-level GPU resource wrappers: Buffer, VertexArray, ShaderProgram, Texture.
gfx_image: Yog image sources — the names every Yog API that shows a picture takes instead of raw Minecraft resource paths, so mods don’t depend on the game version, the loader or where Mojang keeps a texture this release.
inventory: Inventory framework — real Container/Menu screens (BlockEntity-backed), as opposed to ui’s HUD-drawn overlays. See yog-inventory’s DESIGN.md.
java: Other mods — Yog’s and Java ones — from a Yog mod: whether one is loaded (crate::mod_loaded), and calls into a Java mod’s API by reflection (call).
network: Networking (raw-byte packets over channels).
player: Player access (give item, teleport).
storage: Persistent key-value storage for mod data.
ui: UI framework — flexbox layout + widgets on top of yog-gfx.
vanilla: The game’s ids as constants (yog_api::vanilla::items::REDSTONE), so mod code names them instead of spelling them. Generated by yog-cli/src/vanilla/gen_api.py from the supported versions (1.20.1, 1.21.1); one missing from a version says so. Don’t edit — rerun the script.
widget: Widget types and styling.
world: World access (block get/set, dimensions).

Macros§

content: Pulls the mod’s blocks and items — content/**/*.yblock and *.yitem, made in Yog-IDLE’s model editor — in as module content, and registers them (every file without "register": "manual") right after Mod::register:
error: Logging macros (yog_api::info!, warn!, error!). Log at ERROR level.
export_mod: Export a Mod as a dynamically loadable Yog mod.
import: Inter-mod communication proc-macros.
info: Logging macros (yog_api::info!, warn!, error!). Log at INFO level.
packet: Declare a typed packet struct whose fields are automatically encoded/decoded.
resources: Pulls the mod’s .yres resources in as module res — one type per resource set, with an accessor per entry:
tr: tr!("key") = tr("key"); tr!("key", a, b) fills the text’s %s specifiers with a and b (anything Display) — see format_translation.
ui_component: Registers .yui components (types implementing ui::component::Component) when the mod’s library loads, so screens can use <Name …/> and Yog-IDLE’s designer host can draw them. The code yog build generates from a <Component> .yui calls this — mods don’t write it themselves.
ui_components: Compiles in the mod’s component .yui files that have no code-behind .rs (those with one are pulled in by its ui_include!) — call it once, in src/lib.rs:
ui_include: Pulls a .yui screen’s generated code into the current module — the code-behind’s half of src/<name>.yui:
warn: Logging macros (yog_api::info!, warn!, error!). Log at WARN level.

Structs§

AdvancementEvent: Fired when a player earns an advancement (Post only).
ArmorDefense: Defense points per armor piece.
ArmorMaterial: What armor is made of. The game’s are built in (ArmorMaterial::built_ins); a mod declares its own in a .ydef (kind: "armor_material") or registers one.
ArmorPiece: An item as a piece of armor.
AttackEntityEvent: Fired when a player attacks (left-clicks) an entity (server side).
BlockBreakEvent: Fired when a player breaks a block (server side).
BlockDef: A custom block to register; it also gets a matching block-item.
BlockPos: A block position in the world.
BlockProperty: A property of a block’s own: its name and values (the first the default; false, true is a yes/no).
Book: A guide book: what a .ybook file holds.
BookCategory: A category of the book’s home page.
BookEntry: One entry: its pages, in a category.
BookRenderer
CServer: A handle to the runtime’s server actions, backed by YogServer fn pointers. Given to every handler as &dyn Server.
ChatEvent: Fired when a player sends a chat message.
ChunkWriter: Handle passed to a chunk-generator closure (see the crate-level docs), wrapping the runtime’s per-callback vtable — mirrors GfxContext in yog-gfx. Valid only for the duration of the generator callback.
ClientTickEvent: Fired every client tick on the render thread.
CommandContext: Details of a command invocation.
Config: A key/value configuration file backed by <game_dir>/yog-config/<mod_id>.cfg.
ContainerCloseEvent: Fired when a player closes a container screen (Post only).
ContainerOpenEvent: Fired when a player opens a container screen.
CraftEvent: Fired when a player takes a crafted item from a crafting output slot (Post only).
Entity: A handle to one entity by UUID, bound to a Server.
EntityDamageEvent: Fired after a living entity takes damage (server side).
EntityDeathEvent: Fired after a living entity dies (server side).
EntityInteractEvent: Fired when a player right-clicks (interacts with) an entity (server side).
EntitySpawnEvent: Fired when any entity is loaded into a world (server side).
ExplosionEvent: Fired when an explosion occurs in a world.
FoodDef: Nutritional properties for a food item.
GfxContext: Handle to the GPU and draw capabilities for a single render frame.
Interop: Safe wrapper around the runtime’s inter-mod symbol table.
InventoryDef: Describes one inventory-backed screen: how many slots a mod block has, where they sit, whether the player’s own inventory is appended below, and which background texture to draw (vanilla default, or a mod’s own).
ItemDef: A custom item to register, identified by namespace:path.
ItemInsertEvent: A hopper or dropper puts an item into a block that accepts items (block.accepts_items).
ItemPickupEvent: Fired when a player picks up an item entity.
KeyPressEvent: Fired on every key press, release, or repeat (client-side).
LayoutNode
MachineCraftEvent: A machine — an inventory whose .yui has a <RecipeArea kind="…"> — making a recipe of its kind, like a crafting table: the result shows as soon as its slots hold a recipe’s ingredients, and taking it takes them.
ModInfo: Metadata of an installed mod, as reported by the loader.
PacketEvent: A packet received on a channel.
PlaceBlockEvent: Fired when a player places a block (server side).
Player: A handle to one player, bound to a Server.
PlayerDeathEvent: Fired when a player dies.
PlayerJoinEvent: Fired when a player joins the server.
PlayerLeaveEvent: Fired when a player leaves the server.
PlayerMoveEvent: Fired every time a player sends a movement packet (very high frequency).
PlayerRespawnEvent: Fired when a player respawns after death (Post only).
ProjectileHitEvent: Fired when a persistent projectile (arrow, trident, etc.) hits a target.
Recipe: A recipe, in Yog’s own format — what a .yrecipe says. The host writes the recipe JSON of its Minecraft version from it.
Rect
Registry
ScreenEvent: Fired when a GUI screen opens or closes.
SlotLayout: Pixel position of a single slot in vanilla GUI coordinate space (the same space vanilla screens use: origin at the panel’s top-left corner, one vanilla slot = 18×18px).
SoundGroup: What a block sounds like: the sound events it plays when broken, stepped on, placed, hit while mining and fallen on. The game’s groups are built in (SoundGroup::built_in); a mod registers its own (Registry::register_sound_group, or a .ydef of kind sound_group) and names it in BlockDef::sound.
StartupGrant: Grant items/books to every player once when they first join. This is the Yog-side replacement for grant_patchi_book.json.
Storage: Typed, scoped persistent key-value store.
ToolItem: An item as a tool or weapon.
ToolMaterial: What tools are made of. The game’s are built in (ToolMaterial::built_ins); a mod declares its own in a .ydef (kind: "tool_material") or registers one (Registry::register_tool_material).
UiRoot: Top-level UI tree. Build it, call layout, then [render] each frame.
UseBlockEvent: Fired when a player right-clicks a block (server side).
UseItemEvent: Fired when a player right-clicks with an item (server side).
World: An ergonomic handle to one dimension’s blocks, bound to a Server.
YogApi: Stable C ABI — re-exported so mods don’t need a direct yog-abi dependency. Passed to yog_mod_register. Call the function pointers here to register handlers, commands, content, and schedulers.
YogDimensionDef: A dimension definition — what a mod registers to create a custom dimension, or to patch an existing (including vanilla) one. Serialized to JSON and sent across the ABI via Registry::register_dimension (in yog-api), which the Java host parses to register (or patch) a LevelStem/DimensionType entry at mod-init time.
YogDimensionTypeDef: Properties of a dimension type — mirrors Java’s YogDimensionType.

Enums§

Align
BookPage: One page of an entry: {"type": "spotlight", "item": "@item:minecraft:stick", …}.
Cooking: How a cooking recipe cooks.
Dock: WinForms-style dock — which edge(s) the widget attaches to inside its parent.
EventPhase: Whether a handler is running before or after the action.
FlexDir
FocusStyle: How a focused widget shows its focus indicator.
RecipeKind: What a recipe is made of besides its result.
StorageScope: Determines which backing file a Storage uses.
Stretch: How an image fills the box it’s given — WPF’s Stretch.
Units: A size value — either a fixed pixel amount, a CSS-style percentage of the parent’s own resolved content size (0.0–100.0), or Auto (size to content/available space, this crate’s original behaviour).
Value: A typed storage value.

Constants§

ABI_VERSION: Stable C ABI — re-exported so mods don’t need a direct yog-abi dependency. ABI_MAJOR * 10_000 + ABI_MINOR. Checked at mod load time.

Traits§

Mod: Implemented by every Yog mod. Called once at startup to register handlers.
Packet: A typed packet that can be encoded to / decoded from a raw byte buffer.
PacketField: Encode/decode a single field to/from a byte buffer.
Server: Low-level capabilities the Yog runtime exposes to mods (the engine contract).
UiHandled: What a Registry::register_ui handler returns: () (never marks events as used) or bool (true = the handler used this key:/char: event — the host then doesn’t, e.g. Esc doesn’t close the screen).

Functions§

close_ui: Close the Yog UI screen showing ui_id — e.g. from that screen’s own “Done” button. Does nothing when another screen is open. Deferred onto the render thread, so the handler that calls it finishes first. Client side; a no-op on dedicated servers.
format_translation: Fills Minecraft-style format specifiers in pattern (what lang files use): %s/%d take the next argument, %1$s/%2$d a numbered one (from 1), %% is a literal %. A specifier without an argument stays as written.
installed_mods: All installed mods known to the loader: .yog mods plus, where the host exposes them, platform (Java) mods. Callable at any time after this mod’s register() ran — including client-side UI handlers. Note that during register() mods that load after this one are not in the list yet; query lazily (e.g. on first render) for a complete view.
open_ui: Open the Yog UI registered as ui_id (client side; no-op on dedicated servers). modal blocks game input, pause pauses singleplayer. Callable from any handler after registration — e.g. an on_client_packet handler.
server: Handle to the runtime’s server-action table, usable from any handler after registration — including client-side ones that don’t receive &dyn Server (UI event handlers, client tick). Server-world actions are no-ops client side, but networking (send_to_server) and similar client-safe calls work.
split_state: A block state ("ns:id[k=v,...]") as its id and its properties.
tr: The text of translation key in the current language, or key itself when it has none — what Minecraft shows for an unknown key, so a missing translation is easy to spot. Call it each time the text is shown (e.g. while building a UI tree): the player can switch language at any time.
tr_args: tr with arguments for the text’s format specifiers — see format_translation. The tr! macro is shorter.
translation: The text of translation key in the current language, unformatted — None when no lang file defines it (or before the mod registered).

Attribute Macros§

bench: Inter-mod communication proc-macros. Marks a function in a mod’s benches/*.rs as a benchmark yog bench runs: fn name(b: &mut criterion::Bencher) for one benchmark, or fn name(c: &mut criterion::Criterion) to set up groups. yog generates the file’s main; this only makes the function reachable from it.
yog_export: Inter-mod communication proc-macros. Marks a function for inter-mod export. Generates a C-ABI wrapper plus a ctor constructor that self-registers into yog_api’s auto-export registry — export_mod! picks it up automatically, no manual registry.interop().export(...) call needed.

Crate yog_api

Crate yog_api Copy item path

Re-exports§

Modules§

Macros§

Structs§

Enums§

Constants§

Traits§

Functions§

Attribute Macros§

Crate yog_api