Events: how your code talks

What an event is

An event is a named message your code can send and listen for. That is the whole idea. One piece of code announces "this thing happened" by sending the message, and any other piece of code that cares has said "tell me when that message arrives" and reacts to it.

Two words do all the work. You trigger an event to send it, and you write a handler to listen for it. The handler is just a block of code that runs whenever the matching message arrives, the same way the body of a command runs when you type the command.

Events have names, and the names are plain strings you choose, like qu_hello:greet. The colon in the middle is not special to FiveM. It is a naming habit: resourceName:action. Putting your resource name in front stops a clash the day another resource also wants an event called greet. Two sides simply have to agree on the exact same name, character for character, or the message goes nowhere.

Why events exist

Remember the mental model from the client versus server lesson: the player's game (the client) and the server are two separate programs running on two different machines. They do not share variables. The client cannot reach into the server and read a value, and the server cannot reach into the client. On top of that, even on one machine, every resource is its own walled-off sandbox and cannot read another resource's variables either.

So if these separate parts cannot share variables, how do they cooperate at all? They send events. An event is the seam between two parts that otherwise cannot touch. One side announces a fact, the other side reacts, and neither has to reach inside the other. That is why nearly everything in FiveM, buying an item, healing a player, opening a menu, runs on events. It is the only clean way for separate parts to talk.

The three you will use

There are three trigger functions you will reach for constantly. They differ in one thing only: which direction the message travels.

TriggerEvent: same side

TriggerEvent fires an event on the same side you are already on. Client code triggers it, only client handlers hear it. Server code triggers it, only server handlers hear it. It never crosses the network. You listen for it with AddEventHandler.

AddEventHandler('qu_hello:greet', function(name)
    print('[qu_hello] greet handler heard ' .. name)
end)
 
TriggerEvent('qu_hello:greet', 'world')

Read it top to bottom. AddEventHandler says "when an event named qu_hello:greet fires, run this function". The function takes one value, name. Then TriggerEvent fires that exact name and hands it the value 'world', which arrives as name. The handler runs and prints [qu_hello] greet handler heard world. Same side, no network involved.

TriggerServerEvent: client to server

TriggerServerEvent is the client saying "fire this event over there on the server". The message leaves the player's machine and crosses the network to the server. This is how a player's click reaches your server logic.

The picture above is the shape to memorize. The client triggers, the value crosses the wall, and the server is where you check it. On the server side you must listen with RegisterNetEvent, not AddEventHandler, because the event arrives from across the network:

RegisterNetEvent('qu_bank:deposit', function(amount)
    local src = source
    print('[qu_bank] player ' .. src .. ' wants to deposit ' .. tostring(amount))
end)

RegisterNetEvent marks the name as allowed to arrive from the other side and attaches the handler in one call. The first line, local src = source, grabs the id of the player who sent the event. The server reads who the player is from source. It never asks the player to say who they are.

TriggerClientEvent: server to client

TriggerClientEvent is the reverse trip: the server sending an event back to a client. It mirrors TriggerServerEvent with one extra piece in second place, the target, which says who should receive it.

TriggerClientEvent('qu_bank:balance', src, 1500)

Here the server sends qu_bank:balance to one specific player, the one whose id is in src, and hands them the value 1500. To send to every connected player at once, you pass -1 as the target instead of one id. On the client side you again listen with RegisterNetEvent, because the message arrives from across the network.

Build a tiny event

Time to send a real one. You will register a net event on the server that prints a message, then trigger it from a command on the client. This proves a value crossing from the client to the server, which is the move underneath almost every feature you will ever build.

RegisterNetEvent('qu_hello:ping', function()
    local src = source
    print('[qu_hello] ping from player ' .. src)
end)

RegisterCommand('ping', function()
    TriggerServerEvent('qu_hello:ping')
end, false)

restart qu_hello

The number is your own server id, so it may not be exactly 1, but a player id will appear. You just sent a message from your game, across the network, to the server, and the server told you who it came from. That round trip is the backbone of FiveM.

The safety rule

Here is the rule that protects your server, and it is the most important sentence in this lesson: never trust event data from a client. The server must check it before acting on it.

The reason is simple and a little scary. A normal player triggers your event with sensible values. But a player running a cheat menu can open their console and fire any event you registered with RegisterNetEvent, with any values they invent. Your RegisterNetEvent is effectively a public button anyone on your server can press, with any payload they like.

You will learn the full validation checklist in the paid Tracks. For now, lock in the instinct: data from a client is a request, not a fact. The server is the judge.

Common beginner mistakes

Try it yourself

What you can do now

• Explain that an event is a named message you trigger to send and write a handler to listen for.
• Say why events exist: the client and server cannot share variables, so they send messages instead.
• Pick the right trigger for the direction: TriggerEvent for the same side, TriggerServerEvent for client to server, TriggerClientEvent for server to client.
• Use RegisterNetEvent (not AddEventHandler) on the receiving side of any event that crosses the network.
• State the safety rule: never trust client data; the server must validate it and read identity from source.

You can now make separate parts of a server talk to each other, which is most of what real features are made of. The remaining piece is the simplest way to set an event off on purpose: a command you type. Next up: "Commands: trigger code on demand".

REFERENCES

FiveM docs: events ↗