OPEN//77 documentation

CyberM turns Cyberpunk 2077 into a server-driven multiplayer platform. Gameplay and UI features are packaged as resources: self-contained directories with a manifest, Lua scripts, declared permissions, dependencies, and optional web interfaces.

Developers familiar with FiveM will recognize the client/server split, events, exports, commands, and manifest-driven lifecycle. CyberM APIs remain independent and reflect REDengine constraints.

Session model#

The server selects the resource set for a session. A connecting client downloads that set, verifies its signature and content hashes, and activates it before entering the world. Only CyberM's trusted bootstrap resources load outside the server-provided generation.

The server is authoritative. Clients render approved state and submit bounded observations or requests; they do not choose canonical loot, life, vehicle, time, weather, or routing state.

Create a resource#

A resource lives below the server's configured resource root and contains a cyberm.lua manifest:

resource "hello"
version "1.0.0"
auto_start true

client_script "client/main.lua"
server_script "server/main.lua"

Client entry point:

AddEventHandler("onClientResourceStart", function(name)
    if name ~= GetCurrentResourceName() then return end

    local state = CyberM.character.state()
    print(("spawned at %.1f, %.1f"):format(state.position.x, state.position.y))
end)

Server entry point:

RegisterCommand("hello", function(source, args)
    print(("player %d said hello"):format(source))
end, false)

Start the server, connect a client, and invoke hello from the CyberM developer console or chat.

Guides#

API reference coverage#

CyberM has three deliberately separate Lua surfaces. The wiki covers all three without implying that a server method exists in a client VM or that a package export is a native:

Generated cards are separated by runtime, so identical names such as CyberM.vehicles.get cannot confuse a client projection with server authority. They state whether a call is shared, needs a live game instance, or uses the network backend, and document permissions, ownership, generation lifetime, and failure values.

Run both documentation checks after changing a binding or export:

python wiki/tools/extract-api.py --json
python wiki/tools/audit-api.py

The generator fails when a registered client function has no verifiable handler body or detailed description. It also compares the 43 server vehicle cards with the real embedded Lua bootstrap, so adding or removing a method cannot silently leave the searchable reference incomplete.

API conventions#

Engine IDs are opaque#

REDengine identifiers are 64-bit values and may not be exactly representable as Lua numbers. Store, compare, and return them unchanged. Do not pass them through tonumber.

Failures are values#

Most APIs return value on success or nil, reason on failure. Callers can distinguish an invalid request from a temporarily unavailable subsystem without wrapping every call in pcall.

Permissions are explicit#

Guarded APIs require manifest permissions:

permissions { "network.events", "world.loot" }

Request only the capabilities the resource needs.

Client and server runtimes are separate#

server_script files never reach a player's machine. client_script files are distributed in the signed resource set, and shared_script files execute in both runtimes. Secrets and authoritative decisions belong exclusively in server code.

License#

CyberM-owned documentation and code follow the repository LICENSE. Third-party names, game data, and dependencies remain subject to their respective terms.