0-Engine

Over time, while working on various CET mods, I kept running into the same pattern: writing small pieces of infrastructure over and over again.

Lifecycle handling, blackboard polling, vehicle state tracking, distance checks, storage helpers, logging wrappers… each mod needed some version of it, and each version ended up slightly different. None of it was particularly heavy on its own, but duplicated across projects it starts to feel messy.

0-Engine is me finally deciding to stop rewriting those systems and instead build them properly once.

It centralizes state caching, event dispatching, proximity checks, logging and storage into a shared runtime layer for CET mods. If you're just playing the game, you won’t notice anything unless you use a ton of mods and they start requiring this one, but if you're writing mods then you probably will.

For more in-depth examples for modding please see the Readme. MD file I've uploaded under optional files.

0-Engine runs a single managed update loop and builds a central state snapshot from there. Mods can subscribe to events and read cached values without each one doing its own polling.

The state snapshot includes:

• Player entity (safe lifecycle handling)

• Position + orientation + yaw

• Menu state

• Combat state

• Vehicle state

• A derived state cache (weapon type, time of day, camera pitch, district, etc.)

• Full PlayerStateMachine blackboard (raw enums + convenience flags)

Accessed via:

local Engine = GetMod("0-Engine")

local state = Engine. GetState()

The returned state is deep read-only. If something tries to mutate it, it throws immediately.

Blackboard values are read every frame, but enum resolution and event emission only happen when values change. Raw values live under state.blackboard.psm.*, and convenience flags under locomotion/combat/body/vision/vehicle/scene.

Derived state includes things that require engine calls: weapon type (with record ID caching), time of day, player death state, camera pitch (asin of forward vector, clamped), hasWeapon (TransactionSystem slot check with cached TweakDBID), workspot detection, and district (resolved via PreventionSystem and throttled ~every 30 frames with change detection).

Player lifecycle is handled defensively. The engine tracks the player entity hash and distinguishes between first acquisition, invalidation, and recreation (reload/respawn). It emits PlayerReady, PlayerInvalidated and PlayerRecreated accordingly and updates its internal reference atomically.

If you just want safe initialization:

In your onInit function:

local Engine = GetMod("0-Engine")