v0 and modular v1 comparison :: Unofficial EVE Frontier Development Notes

Architecture and lifecycle

Mon, 01 Jan 0001 00:00:00 +0000

v0’s world package models concrete shared assemblies. An assembly owns fixed fields such as its deterministic tenant/item key, owner-cap ID, status, location, energy, and metadata; anchoring and sharing are direct lifecycle operations. v1’s active packages include core, character, inventory, metadata, and currency; the former world package is archived. An Entity is deterministically derived from a tenant-scoped key and holds dynamically installed typed Component values. A numeric component ID is the storage key; an optional name is only a display label.

Domain coverage

Mon, 01 Jan 0001 00:00:00 +0000

The table classifies source at the reviewed commits. Archived legacy is not active v1 functionality; generic Entity primitives do not prove that a gameplay domain has been ported. v0 domain or v1 module v1 state Evidence and consequence Entity, Component, Action, Request, Requirement Active v1 implementation core supplies the modular foundation, now keyed by numeric component IDs rather than names. Opaque fittings Active generic storage, not gameplay logic GenericModule stores type IDs and bytes without implementing a fitting’s behavior. Character identity Redesigned equivalent Identity is an installed component emitting CharacterCreated, not v0’s Character layout. Item and storage inventory Active v1 implementation Active inventory uses one inventory per component; ephemeral per-caller inventories were removed. Display metadata Redesigned equivalent Active metadata installs a component and routes edits through a typed requirement; it is not v0’s metadata layout. EVE currency Active separate package currency::EVE defines a capped-supply coin and admin treasury, separate from archived v0 assets. Assemblies: gate, turret, storage unit Archived legacy only v0 modules remain under contracts/archive/world. Network nodes, killmails, rifts No active v1 equivalent / not yet ported Present on v0/main; v0 Rift mining announcements do not establish an active dev port. Fuel, energy, status Archived legacy only v0 primitives are retained in archive, not active modules. Access, location, registry Partially represented Active core has services and registry concepts, with materially different interfaces and checks. Extension examples Archived legacy only Examples were moved below archive. v1 deployment Separately evidenced / runtime unverified dev/world.json names five packages; live/test/UAT manifests hold different environment-specific facts. None independently verifies on-chain state. A domain can be partially represented by generic platform features without possessing its v0 lifecycle, type, API, or authorization checks.

Identity, access, and location

Mon, 01 Jan 0001 00:00:00 +0000

v0 Character is a dedicated deterministic shared object carrying tenant identity, tribe, wallet, metadata, and owner-cap identity. v1 uses a generic Entity with an installable Identity component. Installing identity emits CharacterCreated with character ID, key, tribe ID, and address; the layout and event schema differ from v0. v0 combines GovernorCap, sponsor-aware AdminACL, and typed OwnerCap; see access_control. v1 represents authorization as requirements consumed while completing an Entity request and uses AccessCap. An Entity stores the ID of its minted cap; a caller cap records the authorized entity for downstream routing, not ownership of an action target.

Inventory, bridges, and events

Mon, 01 Jan 0001 00:00:00 +0000

v0 inventory dynamically attaches inventory to an assembly and moves transit items with parent, tenant, and location metadata. Its bridge flow relies on game-server/location-proof handling and emits domain events carrying assembly and character identity. v1’s active Inventory is one balance area per installed Entity component, keyed by numeric component ID. The former StorageInventory main/ephemeral-per-caller routing is gone. Item type and quantity requirements constrain deposit, withdrawal, and bridge operations; bridge-in and bridge-out handlers additionally push an admin sponsor requirement. The source says the owner can sign and the gas sponsor must be on AdminACL; this is not a v0-equivalent signed location-proof bridge.

Developer experience and operations

Mon, 01 Jan 0001 00:00:00 +0000

v0 exposes direct, domain-specific TypeScript scripts around the world package. v1 adds world-sdk, whose PTB builders resolve MVR package names or local overrides and compose Entity creation, cap verification, actions, requests, identity, inventory, metadata, generic components, and currency. Components use numeric IDs; names are optional display labels. Applications build modular request flows rather than calling a fixed assembly API. package.json excludes archive packages from active Move build/lint/test and adds SDK checks. Its pnpm version, Biome/Husky choices, workflow triggers, and cache mechanics are branch-maintenance divergence unless a consumer relies on them.

Migration guidance

Mon, 01 Jan 0001 00:00:00 +0000

Do not reuse v0 package/type identities, object layouts, OwnerCap assumptions, fixed-assembly calls, or v0 event schemas with v1. Start by mapping the integration’s concrete v0 domain to the coverage state, then decide whether it has an active component, a redesigned equivalent, only partial platform support, or no active port. For active components, create or locate the deterministic Entity, install/configure the component by numeric ID through its typed request, supply and consume requirements in order, and complete the request. Update PTB code to the SDK builders, rework indexers from active event sources, and make authorization/location/bridge checks explicit in tests. Remove installed components before requesting Entity deletion to avoid the documented orphaned-field risk; do not assume deletion cleans them up.

Evidence, contradictions, and limits

Mon, 01 Jan 0001 00:00:00 +0000

Evidence has an order of authority: pinned Move source and tests establish implemented behavior; manifests and deployment artifacts establish only their explicit environment facts; upstream prose is contextual and can be stale. All factual upstream references in this chapter are immutable commit URLs from the canonical cursor. The reviewed dev tree retains v0 source below contracts/archive, while active packages are elsewhere. The decoder README’s contracts/world wording conflicts with that active layout. The earlier claim that the dev deployment manifest omits inventory is no longer true: the reviewed manifest names core, character, currency, inventory, and metadata. The live manifest names MVR app capabilities but does not list published packages. No manifest establishes which code is active in-game.