Hello guys, I I had a question while studying
this video : FiveM Scripting 7 - Server Events and Chat Arguments - YouTube
what does mean 6:23 function(source)
i does not understand source param
but if this param deleted not working
source is the invoking element, which usually is the client that invokes the function. When it comes to the example in the video, a chat command is being registered so you need to pass the client that triggers the command.
Thank you for answer. But I donât understand, sorry may be is it a parameter used to call AddEventHandler?
Not really. source in this case is a function parameter, but an event handler needs a function in itself.
I think I understand So for example RegisterCommand(âannounceâ,function
TriggerServerEvent(âannounceâ, table.concat(args," "))
end)
, is it correct to put soruce as a parameter to pass the TrrigerServerEvent to Server.lua?
You donât seem to understand what that is. Iâll try my best to explain it to you.
So those are called callbacks (javascript example), so you pass that function as a callback of RegisterCommand.
RegisterCommand(
commandName --[[ string ]],
handler --[[ func ]], -- This is our callback
restricted --[[ boolean ]]
)
Those are the params that RegisterCommand takes following the docs @ RegisterCommand - Natives @ Cfx.re Docs.
What happens here is, we register a command and then we pass the function (callback) that we want to execute upon command execution. Imagine a bookshelf, you want to add a new book, so you write your story and store it in the bookshelf, itâs something alike that happens when you register a command/event with a callback. In a simple drawing it would look like
So after it is stored in an array, we execute the command, itâll loop the table until we find our commandâs place (where it is stored) and execute the callback associated with that command. When it executes the associated callback it passes a few arguments (this example only works on RegisterCommand native, arguments may differ on other natives), which in our case are source â Who invoked the command, args â Arguments passed when executing the command (Ex. /kick 1 "Our reason" â {[1] = "1", [2] = "\"Our Reason\""}) & raw â /kick 1 "Our reason" (contains the whole command). These are passed as arguments to your callback so when youâre writing your callback function you can use who invoked the command, the arguments that were passed and the full command in case you want to store it in a file or something.
Hereâs an example of what a callback register and executor would look like.
local Books = { }
RegisterBook = function(name, content)
if Books[name] == nil then
Books[name] = content
end
end
ShowBook = function(name)
-- I'm not too sure where source would come from so let's assume it's a global variable set to a server ID when someone executes this function.
if Books[name] ~= nil then
Books[name](source, name)
end
end
-- Later on:
RegisterBook("Programming Made Simple", function(source, bookName) --[[ Source and book name were passed on the function above this one, so we can use them! :) ]]
print(("Player %s registered a new book named %s"):format(source, bookName))
end)
Well Iâm sure Iâve covered the very basics of it, Iâve also linked you a tutorial in case youâre still confused. Any question? Go ahead post it! 
2 Likes
In AddEventHandler (or RegisterNetEvent), source is treated differently than in RegisterCommand. In the latter one, source is passed as the first parameter of the handler function you chose.
Now, in AddEventHandler (or RegisterNetEvent), source is passed as a âsecret variableâ (technically, it is a global variable that the Event Loop automatically changes at each event it process - you should consider this in some situations, e. g. async access to source without copying to a local var). It is not passed as a parameter of the handler function, it just exist (globally). You can simply use it, as it works like any other variable. The system takes care of defining, initializing/asigning its value.
In this case, source represents the ID of the player (or the server) who triggered the event.
The source is a value that will always be passed as the first parameter to the function you inform to RegisterCommand as a handle.
You can name it whatever you want for using inside the function - it doesnât need to be source, but it is common pratice to do so.
This first parameter, that we usually call source, if you read the documentation, is the net ID of player who triggered the command. Therefore, it makes sense naming it source. (Tip: if the command is triggered by the server, the returned net ID will be 0 - the server ID. You can use this for restriction purposes).
Youâre not obligated to use it; you can just pass a âfunction()â to RegisterCommand (or the name of another function), but, no matter what, the first three parameters (Iâll explain the other two down below) of that function will always be passed by the system. If you write âfunction(randomName, âŚ)â, the randomName variable inside your function will inevitably represent the ID of the player (or server) who triggered the command.
The same goes for the following two parameters (in the video you mentioned, the guy used just the first and second ones, but there are three of them), which will be:
-
The second one, commonly named as âargsâ, is a table of strings representing arguments passed when the command was triggered. For example, if someone triggers a command â/spawnvehicle akuma x y zâ, args[1] will be âakumaâ, args[2] will be âxâ and so onâŚ
-
The third one, usually named ârawCommandâ, is a string representation of the full command writen by the player (or server) who called it. In the previous example, the rawCommand would be exactly: â/spawnvehicle akuma x y zâ.
All those three parameters may be useful in special cases, and thatâs why they exist. And, for security reasons, they are not optional and nobody can change them before the system pass 'em to your chosen function.
If youâre not planning on using those parameters and want to use (somehow) one of your own, youâll still need to reserve the first three params spaces for the system to use. Example: function(source, args, rawCommand, myPersonalParam1, myPersonalParam2, âŚ) OR function(_, _, _, myPersonalParam1, myPersonalParam2, âŚ). I think this will only be useful when youâre not passing a lambda function, when the function you passed still need to be called from another place and receive other values used differently then the first three. But, hey, full teaching leads to good practices. Right?
PS: in Lua, when youâre not pretending on using some variable, you can name it with a underscore, which is generally used as a throwaway variable name. It has no ârealâ special meaning, but is used to signify that the indicated value is not important.
If youâre trying to call TriggerServerEvent, you wonât need to pass the source, as the system will take care of assigning it as it processes respective event.
TriggerServerEvent, when called from a client-side script, will always set this âsecret variableâ (technically, global variable) called source, which represents the ID of the player (or the server) who called it.
Nonetheless, you can pass the source you got from the RegisterCommandâs first parameter to the TriggerServerEvent function (even though you have no reason why). Just pass it with your TriggerServerEvent and use it as a function parameter in the respective server-side AddEventHandler. I donât recommend you doing this though, for security and computational-power saving reasons.
thanks i understood,
To recap, I can call Source from anywhere and Source points to the player, right?
You can call source anywhere (as it is a global variable). But I would recommend only doing it in the scope of a AddEventHandlerâs or RegisterNetEventâs handler function (unless you had a good reason for doing it in other places).
And, in the RegisterCommandâs handler function, source is passed as the first parameter.
In both cases, source is the ID of the element (server or player) that triggered the event/command.
Thatâs it.
I recommend you read the Network and local IDs documentation page, for better understanding of the ID system. That way you wonât get confused if you come across two different IDs from the same invoking element.
Donât forget to consult the documentation and the forum in case of new doubts. If you donât find anything that answers your question, then you can create a new thread in the forum.
1 Like