Skip to content

Crafting — Authority

Folder Overview

This folder provides authority hooks and helpers for the Crafting system.

It defines a small, netcode-agnostic contract (ICraftingAuthority) that callers or services can consult to decide whether a crafting mutation should be allowed.

This is not a networking system. Replication, prediction, reconciliation, and job state synchronization are the responsibility of your chosen netcode.

What Lives Here

  • ICraftingAuthority — mutation gating contract
  • CraftingAuthorityBinder — default local implementation

Purpose

Authority provides a consistent way to:

  • gate crafting mutations (create, cancel, pause, resume)
  • integrate with external authority or permission systems
  • keep Crafting independent from networking or ownership models

Usage Guidance

ICraftingAuthority

Minimal interface used to allow or deny a crafting mutation.

public interface ICraftingAuthority
{
    bool CanMutate(GameObject owner, out CraftFailReason denyReason);
}

Contract notes:

  • owner may be null
  • implementations must tolerate owner == null
  • the interface does not define when it is called or how results are interpreted

Discovery: there isn't any

Crafting does not find an authority for you

CraftingService uses the authority you give it — the Authority slot in its Inspector, the authority argument to Configure, or SetAuthority at runtime. Nothing scans the scene.

Dropping a CraftingAuthorityBinder into the scene therefore gates nothing on its own. Assign it to the service. If you set a binder to deny and never assigned it, crafting is not gated.

This section used to publish a four-stage resolution order — local, parents, scene roots, global scan — for a CraftingAuthorityResolver type that had no callers anywhere in the framework. It described what that type would have done if anything had invoked it, which read as a description of what the service does. The type has been removed rather than wired: Health and Status Effects both resolve automatically because both have an explicit requireAuthority opt-in, and Crafting has none — so scene-wide discovery would silently start gating any project that happened to have a binder somewhere in the level.

CraftingAuthorityBinder

Default permissive implementation for local or single-player setups.

[SerializeField] private bool alwaysTrue = true;

Behaviour:

  • true → allows mutations
  • false → denies mutations with Unauthorized

This binder does not perform networking checks.

Assign it to the service. Drag the binder into CraftingService's Authority field, or pass it to Configure/SetAuthority. A binder sitting unassigned in the scene does nothing.

How Authority Is Intended to Be Used

Authority provides the decision hook, not the policy.

The caller or service determines:

  • which operations are gated
  • when authority is consulted
  • how denial reasons are handled

Typical pattern:

// Wire it once, explicitly.
craftingService.SetAuthority(myAuthority);

// The service then consults it on every gated mutation.
craftingService.CanMutate(owner, out var reason);

If denied, return or emit a failure result.

Important Notes

  • Authority behaviour depends on the implementation provided by the project
  • Crafting does not enforce a specific authority model
  • Missing or permissive implementations may allow all mutations

Not for Production Use

The default binder is for local testing, not multiplayer

  • The default binder is intended for local testing and simple setups
  • Multiplayer projects should provide their own authority implementation
  • Crafting Core (mutation flow and service behaviour)
  • Integrations (authority adapters and examples)