Extension Examples :: Unofficial EVE Frontier Development Notes

config.move

Sat, 21 Feb 2026 12:23:00 +0000

The config.move module provides a shared configuration object for builder extensions. It publishes a single ExtensionConfig shared object at package publish time, allowing other extension modules to attach typed rule/config structs as dynamic fields. 1. Core Component Architecture classDiagram class ExtensionConfig { +UID id } class AdminCap { +UID id } class XAuth { <> } class DynamicField_K_V { +K key +V value } AdminCap ..> ExtensionConfig : guards mutations ExtensionConfig *-- DynamicField_K_V : stores rules as dynamic fields XAuth ..> Assemblies : authenticates extension calls Key Components ExtensionConfig — A shared object acting as a key-value store for extension rules. Other modules attach their own typed config structs as Sui dynamic fields under this object. AdminCap — An owned capability object transferred to the deployer at init. Required for all mutation operations on the config. XAuth — A witness type (has drop) used to authenticate extension calls to world assemblies. Any extension module in this package can create XAuth instances via config::x_auth(). 2. Dynamic Field Pattern The module provides CRUD helpers for managing typed rules as dynamic fields:

tribe_permit.move

Sat, 21 Feb 2026 12:23:00 +0000

The tribe_permit.move module is a config-based builder extension for world::gate. Like gate.move, it enforces tribe-based jump rules, but instead of managing its own shared objects, it stores configuration as dynamic fields under the shared ExtensionConfig object. 1. Core Component Architecture classDiagram class ExtensionConfig { +UID id } class TribeConfig { +u32 tribe } class TribeConfigKey { <> } ExtensionConfig *-- TribeConfig : dynamic field via TribeConfigKey TribeConfig ..> Gate : enforces tribe check Key Components TribeConfig — A store + drop struct holding the required tribe ID. Stored as a dynamic field value under ExtensionConfig. TribeConfigKey — A copy + drop + store struct used as the dynamic field key to locate TribeConfig. Note This module does not define its own AdminCap or XAuth. It reuses both from config.move, demonstrating how multiple extensions can share a common configuration infrastructure and authentication witness.

corpse_gate_bounty.move

Sun, 08 Mar 2026 00:00:00 +0000

The corpse_gate_bounty.move module is a combined Storage Unit + Gate extension that demonstrates cross-assembly interaction. Players submit a corpse item to a storage unit and receive a gate jump permit in return — a “bounty collection” mechanic. 1. Core Component Architecture classDiagram class ExtensionConfig { +UID id } class BountyConfig { +u64 bounty_type_id } class BountyConfigKey { <> } ExtensionConfig *-- BountyConfig : dynamic field via BountyConfigKey Key Components BountyConfig — Stores the bounty_type_id that identifies which item type qualifies as a valid bounty. Stored as a dynamic field under ExtensionConfig. BountyConfigKey — Dynamic field key used to locate BountyConfig on the shared ExtensionConfig. 2. Bounty Collection Flow sequenceDiagram participant Player participant Ext as corpse_gate_bounty participant Config as ExtensionConfig participant SU as StorageUnit participant Gate as world::gate Player->>Ext: collect_corpse_bounty(...) Ext->>Config: borrow_rule → BountyConfig Ext->>SU: withdraw_by_owner(corpse_item_id) Note over Ext: assert corpse.type_id() == bounty_type_id Ext->>SU: deposit_item of XAuth (corpse into owner inventory) Ext->>Gate: issue_jump_permit of XAuth (5-day expiry) Gate-->>Player: JumpPermit transferred How It Works The admin configures which item type qualifies as a bounty via set_bounty_type_id(). A player calls collect_corpse_bounty() with: Their storage unit (containing the corpse) Source and destination gates Their character and OwnerCap The corpse item ID The extension: Withdraws the corpse from the player’s inventory (owner-authorized) Validates the corpse’s type_id matches the configured bounty type Deposits the corpse into the storage unit’s owner inventory Issues a 5-day JumpPermit for the specified gate route 3. Cross-Assembly Interaction This is the most complex extension example because it interacts with two different assembly types in a single transaction:

turret.move (extension)

Sun, 08 Mar 2026 00:00:00 +0000

The turret.move extension is a builder extension example for world::turret. It demonstrates how builders can implement custom targeting behavior by overriding the default priority-list logic using the typed witness pattern. How It Works When a turret has an authorized extension, the game resolves the extension’s package ID from the configured TypeName and calls the extension’s get_target_priority_list function instead of the built-in default. The extension receives: The Turret object (read-only) The owner Character (read-only) The target candidate list as BCS-encoded vector — each candidate already contains a behaviour_change: BehaviourChangeReason field describing what changed (entered range, started attack, stopped attack) An OnlineReceipt hot potato proving the turret is online The extension must: