Skip to main content
HumaLike works standalone and keeps server-specific behavior behind providers. A provider is a Lua descriptor registered by a separate resource through a public export.

​
Domains

Domains are deliberately independent. A player adapter must not also choose an inventory, dispatch, action, or interaction implementation.

​
Selection

Providers declare a name, API version, priority, and optional availability callback. auto selects the single available provider with the highest priority. A tie is ambiguous; HumaLike does not guess. Provider callbacks run in the resource that registered them, so they can use that resource’s local framework object and exports.

​
Ownership and lifecycle

  • Provider names are owned by the registering resource.
  • A different resource cannot replace that provider name.
  • Re-registering the same name from the same resource is idempotent.
  • Stopping the owner automatically removes its providers.
  • Starting or stopping a watched dependency reevaluates availability.
  • Restarting HumaLike creates a new runtime epoch and emits humalike:integration:ready on both server and client.
Listen for the ready event and register again. This supports either resource starting first and makes individual restarts safe.

​
What belongs in a bridge

  • Framework-specific player lookups and job rules.
  • Inventory calls and item allowlists.
  • Dispatch event translation.
  • Custom action validation and execution.
  • Target-system or UI integration.
  • Translation of server roleplay events to HumaLike’s neutral events.
Do not copy HumaLike internals or modify the released directory. Start with the custom bridge guide.

​
Next