Native crafting UI: Difference between revisions
Complete upcoming 0.1.9 documentation: weather, crafting UI, world removal, doors and ladders; preserve release status |
Release 0.1.9 / BUILD264 / Protocol42: availability and download setup; preserve experimental limits |
||
| Line 1: | Line 1: | ||
= Native crafting UI = | = Native crafting UI = | ||
'''Available from 0.1.9 | '''Available from 0.1.9.''' This extends the client-side [[Native HUD and menus]] API introduced in 0.1.7. | ||
== Hide crafting windows, keep station interaction == | == Hide crafting windows, keep station interaction == | ||
Latest revision as of 13:28, 20 October 2026
Native crafting UI
Available from 0.1.9. This extends the client-side Native HUD and menus API introduced in 0.1.7.
Hide crafting windows, keep station interaction
The new HUD component key crafting hides the native recipe/main window and crafting-progress presentation. Covered shared station types include alchemy, cauldron cooking, pan cooking, forge, inscription, whetstone, workbench and orc forge.
-- client.lua; install your onClientNativeUiResult handler first.
local requestId = setNativeHudComponentVisible("crafting", false)
if requestId == false then
outputDebugString("Crafting UI policy was not queued")
end
-- Later, release only this resource's restriction:
-- setNativeHudComponentVisible("crafting", true)
From 0.1.9, showNativeHud with false and setNativeHudComponentVisible("all", false) include crafting as well as the six older HUD groups. setNativeMenuEnabled("crafting", ...) is not supported; crafting is a HUD presentation component, not a fifth disabled management menu.
What remains active
- Approaching and entering a station, its native interaction, idle/exit animation and normal Back/ESC route remain available.
- Hidden recipe controls cannot start a new invisible recipe. Already-running crafting is not intentionally cancelled or restarted by this visibility policy; it can finish/cancel through the normal native lifecycle.
- Native input mode and cursor can remain active while at the station. Hiding the window does not grant free movement/camera, bypass locks, teach recipes, unlock skills or grant materials/products.
- This does not implement custom crafting, a server recipe API or an authorization boundary. Validate crafting gameplay separately on the server. Unrelated trading/books/lockpicking interfaces and custom RmlUi are not hidden by this component.
Results and ownership
The call returns a request ID or false, with the same asynchronous onClientNativeUiResult delivery as other HUD restrictions. Wait for the latest request's acknowledged policy; queued is not applied. getNativeUiState adds:
| Field | Meaning |
|---|---|
components.crafting |
Effective permission, not whether a window is currently visible. |
craftingReady, craftingGuardReady |
Native presentation/guard readiness diagnostics; they can be absent before observation. |
craftingWidgets, craftingObserved |
Observed native-widget diagnostics, not proof of successful crafting or a complete list of stations. |
The crafting HUD mask bit is 64; the older component/menu bits are unchanged. Use named functions rather than manually setting masks.
Multiple resources combine restrictions. Passing true, resetNativeUi or resource stop releases only that resource's request. Restoration respects the game's existing visibility state; it does not forcibly open a crafting window. Connection reset and the existing six-second policy expiry release transient restrictions.
Qualification
Implementation and automated safety checks are present; a complete in-game matrix of all station types, toggling during crafting, exit, reconnect and multiple resources is still required. Test the actual recipe/progress windows and input lifecycle, not just the request acknowledgement.