Sockets
Sockets define the attachment capacity of pickaxes in PVERSE. They determine how many runes a tool can host, begin with a randomized value when the pickaxe is created, and may later be modified through controlled socket-related items.
Overview
Sockets are the capacity layer that connects pickaxes to the rune system. They determine how many rune slots a given tool can actively support and therefore define the upper limit of rune-based customization available to that pickaxe.
This page defines the meaning of sockets, how socket count is first established, how socket-related support items interact with a pickaxe, and how the system preserves state integrity over time. Exact probability weights, item drop rates, upgrade chances, and detailed balance values remain SSOT-owned and enforced server-side.
Scope
Sockets define the rune-hosting capacity layer inside the Game Systems section.
- random socket count resolution at pickaxe creation time
- attachment capacity for rune-bearing pickaxes
- single-use socket expansion item behavior
- rune removal item behavior and forward-only socket-state handling
Core Model
The core model is that sockets are part of the tool state of a pickaxe. They are neither decorative UI placeholders nor freely editable numbers. A socket count is an authoritative property of the pickaxe, initially resolved at creation and later changed only by valid system actions.
- socket count belongs to the pickaxe as real gameplay state
- initial socket count is resolved randomly within the allowed range of the pickaxe line
- rune capacity is bounded by current valid socket state
- future socket changes apply forward-only and do not silently rewrite prior tool history
Socket Count at Pickaxe Creation
When a pickaxe is created, its initial socket count is resolved randomly under the allowed socket range for that pickaxe line. This means two pickaxes of the same family are not guaranteed to begin with identical rune-hosting capacity.
The initial resolution is part of the creation event itself. It is not an optional cosmetic roll after the fact, and it should be treated as authoritative server-side tool state from the moment the pickaxe enters durable history.
Socket Expansion Item
PVERSE includes a dedicated item that can add one additional socket to a pickaxe. This item does not represent open-ended free editing of the tool state. It is a controlled system action that increases socket capacity by one only when the current runtime conditions allow it.
Single-socket expansion rule
The socket expansion item adds one additional socket in a valid use path. It should be interpreted as a bounded enhancement action rather than a generic socket editor.
Whether the item can be used depends on current pickaxe state, current socket limit policy, and any active runtime restrictions. The client may present the action, but authoritative acceptance belongs to the server.
Rune Removal Item
PVERSE also includes a dedicated item that can remove runes from a pickaxe that already has runes inserted. This exists to support rearrangement, recovery, or strategic rebuilding of a rune-bearing pickaxe without treating socket state as disposable.
Attached rune extraction boundary
Rune removal is not assumed to be free or always available by default. It is mediated through an explicit item-based system action so that attached rune state retains real gameplay meaning.
The existence of a rune removal item means the game recognizes socket arrangements as meaningful enough to require controlled reversal tools. This preserves commitment value while still allowing later strategic change.
Operational Behavior
In operational terms, the socket system moves through four major phases: initial randomization at pickaxe creation, rune attachment within current socket limits, optional socket expansion through a dedicated item, and optional rune extraction through a dedicated removal item.
Every phase is bounded by authoritative tool-state validation. The system must confirm the current socket state, attached rune state, and eligibility of the requested item action before any permanent update is written. Socket operations therefore behave as real state transitions, not lightweight client-side customization.
Constraints
- this page does not publish exact socket probabilities, expansion item sources, or detailed upgrade rates
- socket count cannot be treated as freely editable outside valid system actions
- attached runes do not override the current authoritative socket state of the host pickaxe
- future socket policy changes apply forward-only and do not silently rewrite historical socket records
Integrity Considerations
Socket integrity depends on separating presentation, configuration, and authoritative state. Documentation defines what sockets mean and how socket-related items behave. SSOT controls mutable values such as ranges, item availability, and runtime rules. Code enforces randomized creation, valid attachment, approved expansion, and approved rune removal.
- socket count should always resolve from authoritative server-side pickaxe state
- socket expansion and rune removal must be explicit state transitions rather than hidden UI edits
- historical socket outcomes remain auditable even after future balance or item-policy updates
Future Expansion
As PVERSE expands, sockets may connect to stronger specialization paths, advanced tool identity, rarer expansion mechanisms, protected socket states, or deeper synergy with runes and special effects. The conceptual model should remain stable: sockets are a real randomized and upgradable capacity layer of the pickaxe, not a temporary cosmetic abstraction.
Summary
- Sockets define how many runes a pickaxe can host in PVERSE.
- Initial socket count is randomized when the pickaxe is created.
- A dedicated item can add one socket through a valid system action.
- A separate item can remove already attached runes under controlled runtime rules.