Host calls
Settings and disabled systems
The plugin's own settings, as the web portal edits them, and which vanilla systems it switched off.
Generated by tools/gen_api_docs.py; do not edit by hand. See host calls
for how a call is made and how values are encoded. Each example shows the shape of a Wasm
request with its required fields; the values in it are illustrative.
| Call | What it does |
|---|---|
disabled_systems | The vanilla systems switched off at plugin's request: its manifest's disables narrowed to the names the server checks, hunger, mob_spawning and natural_regen (VANILLA_SYSTEMS). |
settings | plugin's settings, every declared one, as a JSON object of key to value: what the server keeps, or the default where nobody has changed it. |
setting_set | Changes one of plugin's own settings, as the web portal does: checked against what it declared, kept in plugins/<plugin>/settings.json, and settings_changed told to every other plugin that hears it (the one that changed it knows). |
disabled_systems
fn disabled_systems(plugin: &str) -> Vec<String>
The vanilla systems switched off at plugin's request: its manifest's disables
narrowed to the names the server checks, hunger, mob_spawning and natural_regen
(VANILLA_SYSTEMS).
What was honoured, not what was asked: a gamemode asks this at start to learn whether it must run its own replacement. The plugin is the caller, so a guest cannot read another plugin's requests.
Wasm request
No fields besides call.
Router notes: The plugin is the caller, from the manifest -- never a field a guest could fill in to read another plugin's requests. plugin is never sent by a Wasm guest: the server fills it in from the manifest name.
Reply: {"ok": ...} holding the Rust return value Vec<String>, encoded as in conventions.
{"call": "disabled_systems"}
settings
fn settings(plugin: &str) -> String
plugin's settings, every declared one, as a JSON object of key to value: what the server
keeps, or the default where nobody has changed it.
Wasm request
No fields besides call.
Router notes: The plugin's own settings only: its name is the manifest's, never the request's. plugin is never sent by a Wasm guest: the server fills it in from the manifest name.
Reply: {"ok": ...} holding the Rust return value String, encoded as in conventions.
{"call": "settings"}
setting_set
fn setting_set(plugin: &str, key: &str, value: &str) -> Result<String, String>
Changes one of plugin's own settings, as the web portal does: checked against what it
declared, kept in plugins/<plugin>/settings.json, and settings_changed told to every
other plugin that hears it (the one that changed it knows). value is JSON; answers the
value as kept, as JSON. For an in-game settings editor, so it and the portal agree.
Wasm request
| Field | Type | Required |
|---|---|---|
key | string | yes |
value | JSON value, read into the Rust parameter value: &str; see the doc comment | yes |
Shape and limits, as the router words its errors: "value should be the setting's new value".
Router notes: The plugin is the manifest's name: a plugin changes only its own settings. plugin is never sent by a Wasm guest: the server fills it in from the manifest name.
Reply: {"ok": ...} holding the Rust return value Result<String, String>, encoded as in conventions. An Err arrives as {"error": "..."}.
{"call": "setting_set", "key": "home", "value": "{\"x\":1}"}
From docs/api/reference/host-calls/settings.md in the RustMC repository at bbd81209ad.