Official resource exports

Use official resource exports for shared services such as interfaces, lifecycle management and gameplay helpers. These exports are separate from runtime-native methods such as Open77.vehicles.get.

The package catalogue on this page lists client exports. Server resources can also publish and call their own exports using the same asynchronous surface; see Cross-resource server exports. The two registries are separate. Server-authoritative mutation remains in server scripts through the server Lua API, net events, or a package's documented server interface.

Calling an export#

There are two forms, and the difference is not style: one waits, the other does not.

Synchronous — exports.<resource>:<name>(...)#

The FiveM spelling works, on the client and on the server, and it returns the export's values directly:

local fuel = exports.open77_fuel:level(vehicleId)
local ok, reason = exports['open77-garage']:store(vehicleId)

A resource name containing a hyphen only works through the bracket form, exactly as in FiveM. exports.res.name(...) (a dot instead of a colon) works too; the proxy recognises the self the colon inserts and drops it.

The call runs inline, on this thread: every resource VM on the client runs on the game thread and every server VM runs on the host scheduler thread, so the callee's function body executes before the call expression returns. Nothing is queued, nothing yields, no tick boundary passes. That is what makes it usable from a getter — and what makes the following true:

• The callee must not yield. Wait, promise:await() and anything built on them fail the call with export_yielded. There is no scheduler underneath a synchronous callee to yield to. Use the asynchronous form for slow work.
• Failure raises. This is the one place Open77 does not return nil, reason. FiveM's exports raise, ported resources are written for that, and a raise is also the only way to keep "the export returned nil" distinguishable from "the call failed". Wrap it in pcall when you want to handle failure yourself.
• Recursion is capped at 8 frames. A → B → A is fine and works; the ninth nested frame fails with export_recursion_limit.
• A resource may call its own export. It is an ordinary nested call, with the same copy of arguments and results as any other, and it counts toward the cap.

Open77.exports.callSync(resource, name, ...) is the same path without the sugar, including the raise, and is what you want when the export name is in a variable.

Asynchronous — Open77.exports.call(...)#

Unchanged, and still the right tool whenever the callee may be slow, may wait on the network or a database, or may not exist yet:

local promise, reason = Open77.exports.call("open77_notifications", "show", {
  type = "success",
  title = "Garage",
  message = "Vehicle stored."
})
if not promise then error(reason) end

local result = promise:await()
if not result.ok then print(result.error) end

It returns nil, reason instead of raising, it runs the callee on the callee's own scheduler where it is free to Wait, and :await() needs a managed task (CreateThread, a handler, a command). Every export in the catalogue below is callable both ways.

What crosses, and what does not#

Both forms copy. Arguments and results are transferred by value through the same serialiser: nil, booleans, finite numbers, 64-bit integers, binary strings and nested plain tables with string or integer keys. A table you hand to another resource is not the table it receives, so a callee mutating it cannot touch yours, and metatables, functions, userdata and coroutines never travel. Nothing about running inline weakens that: the callee gets a fresh coroutine in its own Lua state, with its own globals, its own instruction budget and its own permissions. Synchronous and asynchronous calls differ only in when the callee runs, never in what it can reach.

GetInvokingResource() and GetInvokingResourceGeneration() name the immediate caller for the duration of the call and are restored afterwards, including when the callee raises.

Refusal reasons#

A callee that exhausts its budget fails that call, with its own counter reset for the next one; the caller is not killed for it, and on the client the wall time the callee spent is credited back to the caller's own deadline.

Handles returned by UI packages are resource-owned. Another resource cannot update or dismiss them, and they are cleaned automatically when the owning generation stops or reloads.

Export catalogue#

open77_contextmenu#

Generic ALT/click framework, no built-in gameplay actions. Client-only exports:

Actions belong to their invoking resource/generation; callbacks are provider export names, not closures. Self/sky filters are opt-in, and sky coordinates are a ray endpoint, not a physical impact. Provider stop cleans up actions/claims. See Context menu for contracts, installation and server security.

open77_animations#

The preferred client facade is Open77.animations.<method>(...):await() with the same arguments/results. Preserve the initial nil, error dispatch check before awaiting. See RP animations for examples, permissions, lifecycle and the precise native playback validation limits.

open77_appearance#

See the package README at resources/system/open77_appearance/README.md for the transaction lifecycle.

open77_equipment#

There is no open77_clothing package. Client-side clothing lives in resources/open77_equipment, and the wardrobe it can hide lives in resources/open77_wardrobe; Open77.clothing is a server namespace whose requests this package answers.

The two preview exports are not general-purpose: they refuse any caller other than open77_wardrobe_ui, checked with GetInvokingResource(). The fitting room owns temporary native mutations; it never owns server intent.

The dedicated runtime separately exposes asynchronous server methods under Open77.clothing; they are not client package exports. They target a player and complete through open77:clothing:completed, which this package answers. See Complete server Lua API.

open77_wardrobe#

Same ownership rule as open77_equipment: both exports refuse a caller other than open77_wardrobe_ui. Everything else this package does — projecting other players' outfits onto their puppets through Open77.puppets.setWardrobe — happens on events, not on exports.

open77_weapons#

The package also owns the authenticated target-client relay used by server Open77.weapons.* calls. Completion, slot-state fields, permissions, errors, and authority rules are documented in Weapon Lua API.

open77_perspective#

See Perspective.

open77_vehiclepicker#

open77_chat#

Message and suggestion schemas are documented in Chat.

open77_death#

open77_effects#

See Visual and audio effects and Game data reference.

open77_props#

Read-only by design. Creating or mutating a replicated prop exists only on the dedicated-server Open77.props API — a client cannot mint a prop anybody else can see. There is deliberately no handle export: the projection layer is keyed by the server's own ID, so a second identity could only ever get out of step with it.

See Server-owned world props.

open77_devices#

Server exports only. The client half owns the device-interaction claim for the whole server-declared policy and exposes nothing a caller would reach; the client API it uses is Open77.world.setDeviceInteractionEnabled, documented in vanilla device prompts.

Late joins and routing-bucket changes are answered; a declaring resource that stops takes its policies with it. The package also re-publishes every vanilla device use host-wide as open77_devices:used(playerId, engineEntity, className, choice, allowed) -- a rate-limited claim by that client, never authority.

open77_elevators#

See Elevators. Elevator IDs are opaque even though this compatibility package currently normalizes them before calling the native API.

open77_fuel#

The canonical state-bag sample: fuel is a server-owned fuel key on every vehicle's bag, burned from the replicated speed and engine state, with the engine cut at zero.

The client also re-emits every bag change as open77:fuel:changed(vehicleId, litres, previous). There is no client set: the client never writes a bag.

Server exports, on the same package, for scripts porting GetVehicleFuelLevel / SetVehicleFuelLevel: level(vehicleId), set(vehicleId, litres), refuel(vehicleId, litres?) (to the brim when the amount is omitted), capacity() and configure({ capacity, litresPerHundredKm, idleLitresPerMinute, multiplier }). Every write is clamped into the tank and answers litres | nil, reason; the host-wide open77:fuel:empty(vehicleId) fires once per empty.

open77_groundcircle#

A screen overlay rather than a world entity: the circle is sampled in world space, projected point by point with Open77.camera.project and stroked as an SVG polyline on a transparent HUD surface, so it depends on no depot asset and cannot report itself as rendered while drawing nothing. The trade-offs are that it is not occluded by geometry, receives no light, exists only for the local player, and is sampled on the Lua tick rather than per frame, so it trails a fast camera whip.

create deliberately reads the same field names open77_worldui reads --- id, position, radius, maxDistance, style, groundOffset, color --- and ignores the prompt half of that definition rather than rejecting it, so one definition table can be handed to either resource. It also accepts width (0.5--8.0), opacity (0.05--1.0), fill (0.0--0.6) and visible. radius is clamped to 0.1--50.0 and maxDistance to 1.0--500.0, matching Open77.markers. The limit is 32 circles across every resource combined (circle_limit).

It is a diagnostic and a fallback for a native marker that is not producing pixels, not a replacement for one. For a ground ring that must be frame-tight, use Open77.anchors with render = "ring", which is projected natively on the frame that draws it.

open77_interactions#

Targeting — standing rules that materialise interactions on whatever the world currently holds, rather than one prompt bolted to one place:

Server exports (a declaration made once, applied by every client — see Cross-resource server exports):

Definitions, marker types, choices, distances, entity attachment, target kinds, canInteract, group gates, and responses are documented in Contextual interactions.

open77_loot#

See Loot. Clients cannot create or award authoritative loot.

open77_markers#

The lower-level method schema is in the generated Open77.markers.* reference.

open77_nameplates#

Invisible players never get a plate, whatever the override says. When the server hides a player with Open77.players.setVisible(id, false), his nameplate is withheld along with his body, on every surface that reads the roster -- the native overlay, a streamed page, and Open77.nameplates snapshots alike. This is not a style choice a resource can override: the plate is projected from the body's world position, so leaving it up would draw the exact location that hiding the body exists to conceal. options.visible still governs everything else.

The plate returns on its own when the player is made visible again, or when any of the automatic releases fires (death, respawn, bucket change, disconnect, reconnect, or the hiding resource stopping). Client code never has to reconcile it: the roster is filtered from the replicated life flag, which is the single source of truth -- 2.31 exposes no readable hidden flag on the engine side, so no client can be asked whether a body is really hidden right now.

open77_notifications#

See Notifications for types, positions, duration, progress, actions, replacement, and the server-to-client envelope.

open77_uikit#

Every dialog here waits for a human, so it must be called through Open77.exports.call(...); the synchronous exports.open77_uikit:alert(...) spelling fails a waiting callee with export_yielded. A dispatch failure is nil, reason; a widget that actually ran resolves with { ok, outcome, value }, where outcome is "ok", "cancelled" or "timeout". A cancel is an outcome, never a rejection.

One focus-taking dialog exists across the whole session: a second request is refused with dialog_active rather than queued. The kit spends exactly one WebUI surface for all of it.

The server twins -- progress, alert, input, context, menu, radial, textUI, hideTextUI, drawText3D, updateText3D, clearText3D, showCinematicBars / setCinematic and close, each taking a playerId first -- are server exports, not client ones, and live on the same resource. See The UI kit for definitions, the focus release matrix, the styling tokens a resource may override, failure reasons and a worked job step.

open77_rp_basics#

Server exports only. The role-play kit publishes no client exports: its client half owns a control-block claim and nothing a caller would want to reach.

Authority is the ACL (rp.cuff, rp.escort, rp.search, rp.admin), not the caller: an export carries no player identity. See the role-play kit for the gate, the leash, and the twelve ways a hold ends.

open77_sound#

file must be declared in the calling resource's files manifest entry — a resource can only play audio it ships itself, and that is enforced by the host, not by convention. options: position, entity, volume, loop, pitch, offset, maxDistance, refDistance.

See Sound for the spatial model, the caps, the server twins (Open77.sound.*), and the plain list of what this system is not — it is not Wwise, and Open77.sfx.* remains the way to play the game's own audio events.

open77_vehicles#

See Vehicles for server mutation and native presentation methods.

open-voice#

See Integrated voice chat. Mode changes remain authoritative on the server; these client exports cannot submit arbitrary reach.

open77_voice#

Server scripts in the same package additionally publish helpers for radio/phone channel creation, membership, authoritative mute/deaf, and proximity. Those helpers execute only in the dedicated runtime; use Integrated voice chat for both surfaces and the server-authority rules.

open77_weather#

See Weather. This package intentionally exposes no client mutation command.

open77_worldui#

Mode-agnostic; both official consumers (resources/gamemodes/pursuit, resources/gamemodes/race) call it unmodified. See World-anchored POIs.

open77_zones#

Client-only, local presentation signal -- never proof of position. See Proximity zones for the polling model and the server-side re-validation every caller must apply.

open77_example#

This export is instructional and should not be used as a production dependency.

open77_equipment#

These client exports forward to the local Open77.equipment adapter. They do not submit a durable server clothing transaction; authoritative presentation can subsequently replace a local edit. See docs/equipment.md.

Preview ownership is checked with GetInvokingResource(). Other callers receive preview_owner_denied; unavailable initial presentation returns presentation_not_ready. Owner resource stop also ends its preview. Preview acceptance does not prove that native clothing has finished rendering.

open77_wardrobe#

The same preview_owner_denied and presentation_not_ready guards apply. Stopping the preview owner also restores authoritative state. These coordination exports do not create a persistent outfit or expose arbitrary preview ownership.

Reference coverage#

This catalogue covers official client-resource exports. Additional system-resource exports are documented in their feature guides. Use explicit export names so resource tooling can discover them.