Trait LoopContext 

pub trait LoopContext {
    // Required methods
    fn mod_recipe_property_contains(&self, set: &str, item: ItemKey) -> bool;
    fn side(&self) -> LoopSide;
    fn registry(&self, name: &str) -> Option<Arc<[String]>>;
    fn setting(&self, mod_id: &str, key: &str) -> Option<String>;
    fn mods(&self) -> LoadedMods;
}

The view of a hook fired inside a menu, recipe or player-list loop, where no game is at hand: the side, the registries, the settings and the mod list. The side that owns the loop builds it once per resource generation; a hook never builds one, and its answers never change while it is held.

use mod_api::{Host, LoopContext};
fn game(_: &dyn Host) {}
fn each(context: &dyn LoopContext) { game(context); }

use mod_api::{HostTransaction, LoopContext};
fn each(context: &mut dyn LoopContext) {
    let _: Result<(), ()> = context.transaction(|_, _| Ok(()));
}

Required Methods

fn mod_recipe_property_contains(&self, set: &str, item: ItemKey) -> bool

Whether a mod-created recipe property set accepts an item ID. Unknown sets/items and vanilla set keys return false. Use this in menu_slot_rules for the same filter on server and client prediction. Answers come from the owning load, replaced by the server’s synced generation on clients; no allocation or file IO occurs during a read.

fn side(&self) -> LoopSide

The side whose loop fires the hook.

fn registry(&self, name: &str) -> Option<Arc<[String]>>

Registry names in ID order, from the resource generation’s snapshot.

fn setting(&self, mod_id: &str, key: &str) -> Option<String>

A loaded mod’s setting captured when this context was built, without file I/O.

fn mods(&self) -> LoadedMods

The same loaded-mod view available during registration.

Dyn Compatibility

This trait is dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors