Events

Item hook events

nx_computer exposes two client events as ox_inventory item hooks. They are triggered by the item definition when a player uses the item, not by external code. Set them as the client.event on the matching item in ox_inventory data/items.lua.

The laptop item opens the in-world laptop:

['laptop'] = {
    label = 'Laptop',
    weight = 1000,
    stack = false,
    close = true,
    client = { event = 'nx_computer:client:useLaptop' },
},

The projector item opens the projector:

['projector'] = {
    label = 'Projector',
    weight = 2000,
    stack = true,
    close = true,
    client = { event = 'nx_computer:client:useProjector' },
},

Neither event takes a payload.

nx_computer:client:useLaptop depends on where the player is:

• On foot, it starts a placement. The player aims and confirms, and the item is consumed on confirmation. The laptop sets down on any valid surface, including a vehicle panel such as a bonnet, roof, or boot unless Config.VehiclePlacement.Enabled is false.
• Seated in a vehicle, it opens the laptop on the player's lap with no placing step. Using the item again closes it. This lap mode is off when Config.Vehicle.Enabled is false, and the item then falls back to placement.

nx_computer:client:useProjector starts a ceiling placement the same way. It does nothing when Config.Projector.Enabled is false.

For back-compat, the legacy alias nx_laptop:client:useLaptop is also accepted in place of nx_computer:client:useLaptop. It is registered only when the legacy resource is not running at the time nx_computer starts, so the two cannot both open a laptop.

The camera and polaroid items use client.export instead of client.event. Their entry points are documented on the exports page: useCamera for the camera, usePolaroid and placePolaroid for the polaroid. The darknet access item needs no hook at all, since it is a presence check.

Server-side event mirrors

Two server exports have a matching server event, for resources that prefer events over exports. Both do exactly what the export does. Both refuse any caller other than the server itself and print the rejection to the server console, so a client cannot forge system mail or push a notification to an arbitrary account.

nx_computer:email:sendSystem takes the same payload as sendSystemEmail:

TriggerEvent('nx_computer:email:sendSystem', {
    to = '@jdoe',
    subject = 'Your order shipped',
    body = 'Your package is on the way.',
    sourceApp = 'store',
})

nx_computer:notifications:push takes the same payload as PushNotification:

TriggerEvent('nx_computer:notifications:push', {
    handle = '@jdoe',
    appId = 'store',
    title = 'Order ready',
    message = 'Your pizza is waiting at the counter.',
    severity = 'success',
})

A notification pushed with an appId of email, mail, or messages is also forwarded to the player's phone when the phone bridge is active (Config.PhoneBridge).

nx_computer:transactions:record is a server-local event that takes the same payload as RecordTransaction. It is not a network event, so only server code can fire it:

TriggerEvent('nx_computer:transactions:record', {
    computerId = computerId,
    accountId = accountId,
    entryType = 'job_payout',
    assetSymbol = 'USD',
    assetAmount = 1,
    fiatTotal = 850,
})

The exports return a result and these events do not. Prefer the export when you need to know whether the write succeeded.

Newsroom stories

Whenever a Newsroom story changes, nx_computer fires a server-local event. It is not a network event, so a client can never raise it. Listen to it from your own server script to post new stories to Discord or ring phones:

AddEventHandler('nx_computer:server:newsEvent', function(kind, story)
    if kind == 'published' and story.breaking then
        print(('Breaking: %s by %s'):format(story.title, story.author.name))
    end
end)

• kind: one of saved, published, unpublished, deleted or imported.
• story: a table of id, title, standfirst, category, status (published or draft), breaking, author (name and job), and photoIds (the phone photo ids the story shows).

MDT jail hand-off

When an MDT sentence starts serving, nx_computer can hand it to your jail script. The event names are yours: set them in Config.MDT.JailAdapter. The default mode is 'none', which only records the sentence.

The arguments are:

• src: the server id of the sentenced player, resolved on the server.
• minutes: the remaining minutes (term minus credit minus time served).
• data: a table with minutes, sentenceId, citizenIdentifier (the framework identifier), and reason when one was given.

The hand-off fires only while the citizen is online. An offline citizen is recorded as deferred, and the hand-off retries the next time the sentence enters serving. Most jail scripts expect their own argument shape and units, so point the adapter at a small shim event in your own resource and convert there:

-- Config.MDT.JailAdapter = { Mode = 'server_event', ServerEvent = 'myshim:mdtJail' }
AddEventHandler('myshim:mdtJail', function(src, minutes, data)
    -- Call your jail script here. Check its docs for the expected units.
end)

No other public events

Every other nx_computer:* network event is internal. Auth, sessions and multiple accounts, laptop, monitor and projector placement (including vehicle placement and lap mode), app and directory-site sync, notification and message delivery, email and email forwarding, media upload, the camera, polaroid placement, Meetings (signalling, voice channel, and participant control), the MDT, bodycam and live view, the file system, the store, darknet orders and hand-overs, casino, vehicle offers, and market order traffic are all events nx_computer fires for itself. What nearby players see of a laptop screen is mirrored through nx-3d, not through nx_computer events. None of these are a supported integration point. Triggering or listening to them from another resource is unsupported and may break between versions.

Apart from the Newsroom event above, the phone integrations do not use events of their own. The phone bridge calls lb-phone's SendNotification export directly, and other resources can reach it through the PhoneNotify server export. Phone photo sync listens to lb-phone's own server event lb-phone:deletedFromGallery to remove mirrored photos.

The supported integration surface is the exports and the SDK.