Shared Capability Services

Many plugins need chance: a rare item may drop, a grave marker may raise a zombie, or an event may choose one hidden location. ADK gives those decisions a stable identity so retries, reloads, and screen refreshes cannot quietly roll again.

The service handles the secure draw and keeps enough proof to explain a disputed result. The plugin still decides what the choices mean and how likely they are. For example, the loot system defines its loot table; this service only selects from the accepted version without exposing information that would make future results predictable.

This registry lets local systems request a capability without depending on one exact provider. If the preferred provider is missing, busy, disabled, or unavailable, Brain can choose a simpler permitted provider or report that the capability is unavailable. A fallback may offer less detail, speed, or scope, but it cannot bypass safety, privacy, permission, or ownership rules.

Example: If a detailed analysis provider is unavailable, Brain may select a basic provider that still follows the same permissions.

This service checks if a character can attempt an action. It looks at skill level, success chance, cost, and risk. It does not let characters choose tasks or share private details.

It is designed to enforce limits based on character capabilities and game rules, without allowing direct control over actions or access to internal state.

This service handles situations where a specific placed object is used up when an actor appears. Plugins pick which object and actor to use; the framework manages reservations, placement limits, and what happens next.

It ensures that only one actor can consume a given object at once, and tracks the outcome of the action.

A complicated operation may need several different things at once: people, equipment, money, a vehicle, a route, and a location. Those things would remain controlled by their proper systems, but ADK is designed to give their reservations one common shape so the overall plan can understand what is requested, safely held, used, returned, expired, or still uncertain.

For example, an evacuation can show that a truck and driver are reserved without pretending the same system owns both. The vehicle and personnel systems each confirm their own part. The shared envelope simply lets the larger plan coordinate their answers safely.

Many choices depend on smaller judgements that do not need to be recalculated every time. ADK can keep the latest acceptable result ready and automatically learn whether it is best refreshed when facts change, on a staggered schedule, or only when another decision asks for it.

For example, a trader's general view of local food scarcity may be refreshed when stock or deliveries change, while a price negotiated for one particular buyer is calculated only when that buyer asks. Urgent decisions retain strict freshness rules, so an NPC does not respond to incoming gunfire using an assessment that was allowed to nap for five minutes.

ADK uses one general system for describing where objects can be attached, what can fit there, and what happens when either object changes or disappears. Vehicles, workbenches, structures, containers, equipment, and future object types can all build on the same basic rules instead of every plugin inventing another kind of slot.

The general service handles identity, compatibility, reservation, occupancy, and the attachment lifecycle. More specialized systems still decide the details that belong to them. A vehicle system may reject a heavy turret because it would make a boat unstable; a workbench system may reject a tool because the station lacks power.

For example, a plugin can ask to attach a searchlight to a registered hardpoint. ADK checks the shared slot rules, then asks the relevant object adapter about its own restrictions. The attachment becomes active only when all responsible systems agree, which is less exciting than bolting it on and discovering the collision system has become a trebuchet.

This service lets code ask for a type of resource without needing to know where it is stored. It only picks from approved options and clearly says when an exact match isn't found.

It is designed to simplify asset access while maintaining control over what resources can be used.

This lets a plugin describe several checks and changes as one plan. The framework runs the checks, prepares the changes, and only applies them if everything goes as planned.

It is designed to allow developers to express conditional logic without writing complex coordination code, while ensuring all effects go through normal validation boundaries.