Latent events: TriggerLatentServerEvent & TriggerLatentClientEvent

Big data should trickle, not slam. A regular TriggerServerEvent hands the whole payload (the data you are sending) to the network in one shot. For small messages that is fine. For big tables, image buffers, or character export blobs, that single burst can clog a player's connection long enough to time them out. A latent event sends the exact same data, but metered at a speed you set, in bytes per second, so the connection keeps breathing while the data flows across.

You'll learn: When to swap TriggerServerEvent for TriggerLatentServerEvent, what the bps parameter actually does, how to size it, and why broadcasting latent events to all players is a trap
Time: ~14 minutes
Prereqs: TriggerServerEvent / TriggerClientEvent
Outcome: You know the rule of thumb (small = regular, big = latent), you can size bps for any payload, and you can send latent events in both directions safely

BEFORE YOU START

Build it

Make the resource folder

The server has one folder for this lesson.

Inside your server's resources folder, create this folder:

code

resources/qu_latent_events

Create the files

Every file named in the manifest exists.

Create this exact file layout:

code

resources/qu_latent_events/
fxmanifest.lua
server.lua
client.lua

Write fxmanifest.lua

FiveM knows which files to load.

Open fxmanifest.lua and paste this:

code

fx_version 'cerulean'
game 'gta5'

client_script 'client.lua'
server_script 'server.lua'

Older tutorials add a lua54 'yes' line here. As of June 2025 that setting is deprecated and ignored: Lua 5.4 is now the only Lua runtime, so you leave it out.

Write the lesson code

Both latent natives now run, one per direction.

Open server.lua and paste this:

code

RegisterNetEvent('qu_latent_events:upload', function(payload)
-- `source` is the server id of the player who triggered this event.
-- It is only valid right here, so copy it into a local before anything else.
local src = source

-- SECURITY: any connected client can fire this event with any data,
-- not just the /latenttest command. Validate before you trust it.
if type(payload) ~= 'string' then return end          -- reject non-string input
local size = #payload
if size > 6 * 1024 * 1024 then return end              -- cap the size you accept

print('[qu_latent_events] server received ' .. size .. ' bytes from player ' .. src)

-- Acknowledge back down to the client, also as a latent stream.
TriggerLatentClientEvent('qu_latent_events:ack', src, 25000, size)
end)

Open client.lua and paste this:

code

RegisterCommand('latenttest', function()
local payload = string.rep('A', 20000) -- 20,000 bytes of filler

-- 25000 = stream this payload at 25,000 bytes per second.
TriggerLatentServerEvent('qu_latent_events:upload', 25000, payload)
print('[qu_latent_events] upload started (' .. #payload .. ' bytes at 25000 bps)')
end, false)

RegisterNetEvent('qu_latent_events:ack', function(size)
print('[qu_latent_events] client got ack: server saw ' .. size .. ' bytes')
end)

Start and test it

The expected proof appears in the correct consoles.

Open server.cfg and add this line:

code

ensure qu_latent_events

The ensure line makes the server start this resource every time it boots, but it only takes effect on the next boot. To load it now without rebooting, run this in your server console (the txAdmin Live Console, or the FXServer console window if you start the server directly):

code

restart qu_latent_events

Join the server, then open the chat box with T and run:

code

/latenttest

The client line prints first. About one second later (20,000 bytes at 25,000 bps), the server line lands in txAdmin Live Console. The ack then streams back down and the second F8 line appears. Three lines, two consoles, one full round trip.

Keep reading the full lesson

Still ahead in this lesson

How it works
If something went wrong
What you can do now
Try it yourself